← شروع آموزش

WIUNIX ACADEMY

احراز هویت OpenVPN با گواهی و Google Authenticator

صفحهٔ 4 از 5؛ مراحل قبلی و پیش‌نیازها را پیش از ادامه مرور کن.

آموزش متناسب با محیط تو

کجا اجرا می‌کنی؟

سیستم‌عامل و نسخه را انتخاب کن تا مراحل، دستورها و راه‌حل‌ها برای همان محیط نمایش داده شوند.

Ubuntu 26.04 LTSبررسی‌شده با مستندات رسمی ·

آموزش متناسب با مقادیر تو

تنظیمات این آموزش

مقادیر نمونه را برای محیط خودت تنظیم کن؛ متن و دستورهای مرتبط با هم تغییر می‌کنند. رمز، کلید خصوصی و توکن وارد نکن. مقادیر فقط در همین زبانه نگهداری می‌شوند و به سرور یا لینک اشتراک‌گذاری فرستاده نمی‌شوند. پیش از اجرا، DNS، گواهی‌ها و سیاست شبکهٔ واقعی را بررسی کن.

آی‌پی، دامنه یا پورت مثال‌ها با محیط تو فرق دارد؟ دکمهٔ زیر را باز کن، مقادیر را تغییر بده و «اعمال در آموزش» را بزن؛ سپس دستورهای به‌روز‌شده را کپی کن.

تنظیم مقادیر برای محیط من7 مقدار قابل‌تغییر
17

قدم بعدی

اتصال و تونل محدود را کنترل کنید

از پوشهٔ خصوصی پروفایل اجرا کنید. Username دقیقاً academyvpn و Password فقط کد تازه است؛ ورود کد خصوصی بماند. فرایند پایلوت foreground باشد و پس از آزمون با Ctrl+C متوقف شود. پیام Initialization Sequence Completed و آدرس رنج لازم‌اند؛ سرویس مجاز روی سرور را نیز بررسی کنید. موفقیت TLS به‌تنهایی دسترسی اپلیکیشن نیست.

در ترمینال دوم کلاینت مسیرها را ببینید و اگر فایروال تونل اجازه می‌دهد سرور VPN را ping کنید. مسدودبودن ping شکست احراز هویت را ثابت نمی‌کند؛ لاگ کلاینت و سرویس مجاز را کنار هم بسنجید. مسیر پیش‌فرض full-tunnel و DNS در این نمونه تغییر نمی‌کنند.

bash

کلاینت لینوکس آزمایشی

sudo openvpn --config ./pilot.ovpn
از کجا بدانم درست انجام شد؟

گواهی و نام منطبق همراه TOTP تازه و معتبر، تونل پایلوت را برقرار می‌کنند؛ دسترسی شبکهٔ دیگر نتیجه‌گیری نمی‌شود.

18

قدم بعدی

آدرس کلاینت و مقصد مجاز را بررسی کنید

در ترمینال دوم کلاینت متصل اجرا کنید. رابط اعلام‌شده در لاگ همین پایلوت را تشخیص دهید؛ رابط VPN قبلی را با آن اشتباه نگیرید. آزمون ICMP مشروط به سیاست مصوب است و مجوز بازکردن تمام ترافیک تونل نیست.

bash

کلاینت لینوکس آزمایشی

ip -br address
ip route get 10.93.0.1
ping -c 3 -W 2 10.93.0.1
از کجا بدانم درست انجام شد؟

مسیر از همین تونل می‌گذرد و probe مجاز موفق است؛ یا محدودیت مستند فایروال علت رد آن را روشن می‌کند.

پیش از گسترش پایلوت، مسیرهای رد را ثابت کنید

بین هر مورد قطع اتصال کنید. فقط با هویت آزمایشی این حالت‌ها را بررسی کنید: گواهی صحیح با کد غلط یا خالی؛ کد معتبر کاربر دیگر همراه گواهی اول؛ استفادهٔ دوباره از کد پذیرفته‌شده در اتصال دوم؛ seed غایب؛ حساب منقضی و گواهی باطل‌شده با CRL جاری. هیچ‌کدام نباید تونل مجاز بسازند. seed کاربر فعال یا ساعت تولید را برای تست خراب نکنید. ممکن است کد معتبر نام نامنطبق پیش از رد هوک مصرف شود؛ برای تلاش بعدی کد تازه بگیرید.

خطاهای تکراری محدودیت seed هر کاربر را فعال می‌کنند. تا پایان بازه صبر کنید؛ وضعیت را پاک یا پنجرهٔ زمانی را بزرگ نکنید. فقط نتیجه، نسخه و علت پاک‌سازی‌شده را ثبت کنید، نه کد و seed. محدودیت هر seed محلی است و کنترل توزیع‌شدهٔ brute-force یا تضمین lockout نیست؛ کنترل ورودی و مانیتورینگ همچنان مسئولیت عملیات است.

19

قدم بعدی

بدون افشای اطلاعات ورود عیب‌یابی کنید

برای خطای همهٔ کاربران، مسیر واقعی افزونه، نام سرویس PAM، زمان، فضای دیسک، TUN و امتیاز helper را ببینید. خطای یک کاربر بیشتر به بزرگی حروف CN و نام، مالک و مجوز seed، انقضای حساب یا ساعت گوشی مربوط است. محتوای seed را cat نکنید و صرفاً برای شواهد debug پرجزئیات PAM را فعال نکنید. فرمان‌های زیر فقط metadata را نشان می‌دهند.

خطای گواهی پیش از OTP رخ می‌دهد. موفقیت PAM و سپس AUTH_FAILED می‌تواند از هوک تطبیق CN باشد. تونل متصل بدون دسترسی سرویس، مسئلهٔ مسیر، فایروال یا مجوز اپلیکیشن است. برای عیب‌یابی هیچ verifier را حذف نکنید.

bash

VM مستقل پایلوت؛ ترمینال خصوصی برای ثبت دستگاه

sudo journalctl -u 'academy-mfa.service' -n 60 --no-pager
timedatectl show -p NTPSynchronized --value
df -h '/srv/academy-openvpn-mfa'
readlink -f '/srv/academy-openvpn-mfa/auth-pam.so'
sudo stat -c '%U %a %n' '/srv/academy-openvpn-mfa/users/academyvpn' '/srv/academy-openvpn-mfa/users/academyvpn/.google_authenticator'
sudo chage -l 'academyvpn'
sudo openssl crl -in '/srv/academy-openvpn-mfa/pki/crl.pem' -noout -lastupdate -nextupdate
از کجا بدانم درست انجام شد؟

علت مشخص از metadata و لاگ خصوصی تشخیص داده می‌شود؛ اطلاعات محرمانه محفوظ و MFA الزامی می‌ماند.

گم‌شدن دستگاه را با احراز هویت مسئولانه بازیابی کنید

اگر کد اضطراری از قبل امن نگهداری شده، در همان فیلد password وارد می‌شود؛ گواهی منطبق همچنان لازم است. کد یک بار مصرف می‌شود و معافیت MFA نیست. بازیابی گوشی گم‌شده به احراز هویت مستقل، تعویض آگاهانهٔ seed در فرایند خصوصی ثبت دستگاه و کنارگذاشتن تمام کدهای قدیمی نیاز دارد. seed و کد را در تیکت نفرستید.

اگر کلید یا seed احتمالاً افشا شده، گواهی را باطل کنید، CRL جاری با امضای CA را اتمیک و با مسیر قابل‌خواندن برای daemon جای‌گذاری کنید و نشست‌های موجود را از فرایند عملیاتی مصوب خاتمه دهید. به‌روزرسانی CRL لزوماً نشست فعال را بیرون نمی‌اندازد. انقضای حساب هم پذیرش بعدی PAM را قطع می‌کند، نه تونل موجود را. بازیابی backup وضعیت seed ممکن است کد مصرف‌شده را زنده کند؛ backup محرمانه است و به تطبیق وضعیت یا ثبت دوباره نیاز دارد.

20

قدم بعدی

پایلوت را بدون حذف پنهانی MFA متوقف کنید

در شکست فقط listener تازهٔ پایلوت را متوقف کنید؛ VPN تولیدی و کنسول مدیریت مستقل دست‌نخورده بمانند. بازگشت خودکار به ورود فقط با گواهی روی همان ورودی عمومی، افزودن nullok، حذف هوک یا کاهش کنترل گواهی، rollback قابل‌قبول نیست. مهاجرت بعدی تصمیم صریح دسترسی و طرح بازگشت کنترل‌شده می‌خواهد؛ قطع سرویس از دورزدن پنهانی احراز هویت بهتر است.

این کار فقط پایلوت را متوقف می‌کند و تنظیمات و شواهد محافظت‌شده را برای بررسی نگه می‌دارد. حساب و seed حذف نمی‌شوند و پاک‌سازی امن ادعا نمی‌شود. شروع هنگام بوت پس از آزمون کلاینت واقعی و موارد رد عملیاتی بررسی شود.

bash

VM مستقل پایلوت؛ ترمینال خصوصی برای ثبت دستگاه

sudo systemctl disable --now 'academy-mfa.service'
sudo systemctl is-active 'academy-mfa.service' || true
sudo ss -lunp
از کجا بدانم درست انجام شد؟

پایلوت غیرفعال و listener آن بسته است؛ ورودی ضعیف‌تری جای آن شروع نشده است.

همهٔ آموزش‌های آکادمی ↗