چرا دسترسی مدیریت روتر پس از تغییر VPN پاسخ نمی‌دهد

مسیری یا قاعدهٔ دیوار آتش را برای آزمایش یک تونل روی روتر تغییر داده‌اید و اکنون صفحهٔ مدیریت از لپ‌تاپی پاسخ نمی‌دهد که ده دقیقه پیش درست کار می‌کرد. واکنش اولیه سرزنش VPN است. بیشتر وقت‌ها تونل سالم است و یکی از سه چیز دیگر خراب شده: مسیری به آدرس خود روتر برنمی‌گردد، سیاست ورودی درخواست را می‌اندازد، یا سرویس وبی روی آدرسی که صدا می‌زنید گوش نمی‌دهد. هر سه در مرورگر یکسان به نظر می‌رسند، از این رو مردم یک ساعت تونل را دوباره راه‌اندازی می‌کنند و چیزی یاد نمی‌گیرند.

این افسانه‌ای است که ارزش دارد اول کشته شود: تونل کارکننده راهی برای بازگشت به داخل نیست. پیوند شبکه‌ای تازه با پرسش‌های اعتماد خودش است و می‌تواند بی‌سروصدا مسیر مدیریت قدیمی شما را بردارد و مسیر تازه‌ای باز کند که کسی بازبینی نکرده است.

تونل هرگز مسیر مدیریت نبود

فرستادن و ورودی دو کار جداگانه‌اند. «آیا یک کارخواه می‌تواند از طریق تونل به NAS برسد؟» پرسشی از جنس فرستادن درباره بسته‌هایی است که از روتر می‌گذرند. «آیا می‌توانم درگاه SSH روتر را باز کنم؟» پرسشی از جنس ورودی درباره بسته‌هایی است که به خود روتر نشانه رفته‌اند. قاعده‌ای که برای ترافیک فرستاده‌شده نوشته شده برای پرسش دوم هیچ نمی‌کند، و این رایج‌ترین دلیل آن است که تونلی که ترافیک را بی‌عیب حمل می‌کند همچنان نشست مدیریت شما را رد می‌کند.

اشتباه معکوس اعتماد به نام واسط است. تونل با همتا رمزگذاری می‌شود، نه با هر سرویسی پشت آن، و واژهٔ VPN در برچسب واسط چیزی دربارهٔ اینکه کدام مبدأها باید اجازهٔ ورود داشته باشند نمی‌گوید.

لایهٔ یک: آیا مسیری به آدرس خود روتر هست؟

از کارخواه شروع کنید و از هسته بپرسید بسته کجا می‌رود. در لینوکس ip route get 10.6.0.1 مسیر انتخاب‌شده، واسط خروجی و آدرس مبدأ را چاپ می‌کند. اگر مسیر پیش‌فرض به سوی ارائه‌دهندهٔ شما را گزارش کند، بسته هرگز به تونل وارد نمی‌شود و هیچ قاعده‌ای روی روتر نجاتش نمی‌دهد.

سمت تونل نسخهٔ خودش از این پرسش را دارد. WireGuard فهرست AllowedIPs را جدول مسیریابی کلید رمزنگاری می‌داند: در هر سو اعلام می‌کند همتا کدام آدرس‌های مبدأ را می‌تواند به کار ببرد و کدام مقصدها به آن همتا فرستاده می‌شوند. اگر ورودی کارخواه آدرس تونل روتر را در بر نگیرد، کارخواه مسیری به آن ندارد. اگر ورودی سرور برای آن کارخواه آدرس تونل کارخواه را پوشش ندهد، سرور بسته را پیش از مراجعه به هر قاعدهٔ دیوار آتش می‌اندازد.

پیش از اشکال‌زدایی سیاست، آدرس دقیقی را که انتظار دارید به آن برسید تأیید کنید. یک رکورد کهنهٔ DNS یا ورودی همسایهٔ ذخیره‌شده از پیش از تغییر شما را به آدرسی می‌فرستد که هرگز در اختیار روتر نبوده است.

لایهٔ دو: سیاست ورودی، نه سیاست فرستادن

دیوارهای آتش قاعده‌ها را روی واسطی می‌سنجند که بسته در آن می‌رسد. در pfSense و OPNsense زبانهٔ واسط و ترتیب قاعده‌ها تعیین می‌کند ترافیک به سرویس‌های خود دیوار آتش مجاز است یا نه؛ قاعده‌ای که کارخواهان LAN را به اینترنت بیرون می‌فرستد قاعده‌ای نیست که به همتای تونل اجازهٔ باز کردن رابط وب بدهد. در OpenWrt با firewall4 هر ناحیه یک سیاست ورودی دارد، option input 'ACCEPT' یا 'REJECT'، و واسط تونل در ناحیه‌ای با ورودی REJECT اتصال‌های مدیریت را رد می‌کند و در همان حال اگر فرستادن مجاز باشد ترافیک را می‌فرستد.

قاعدهٔ ضدففل را برای کارکردن مسیر تازه غیرفعال نکنید. آن قاعده نمی‌گذارد قاعدهٔ بدی آدرس مدیریت LAN را قفل کند؛ از زیرشبکهٔ LAN محافظت می‌کند، نه از زیرشبکهٔ تونلی که همین حالا ساخته‌اید. یک قاعدهٔ باریک برای مبدأ مدیر اضافه کنید و تور ایمنی را به حال خود بگذارید. مستندات pfSense دربارهٔ دسترسی مدیریت توضیح می‌دهد این کنترل‌ها کجا هستند.

# on the router: bind addresses and the loaded ruleset
ss -ltnp | grep -E ':(22|80|443)\b'         # Linux / OpenWrt
sockstat -4 -l | grep -E ':(22|80|443)\b'   # FreeBSD / pfSense
nft list ruleset | grep -A6 'chain input'    # firewall4
pfctl -sr | head -40                         # pf / pfSense

لایهٔ سه: آیا چیزی روی آن آدرس گوش می‌دهد؟

سرویسی می‌تواند در حال اجرا باشد و باز هم دست‌نیافتنی باشد چون به یک آدرس بسته شده است. uhttpd در OpenWrt ورودی‌های شنوندهٔ صریح را در /etc/config/uhttpd نگه می‌دارد، برای نمونه list listen_http '0.0.0.0:80'؛ ساخت‌های که فقط به آدرس LAN بسته می‌شود روی آدرس تونل چیزی نمی‌پذیرد، و محصولاتی که تنظیم واسط شنونده را نشان می‌دهند همان‌گونه رفتار می‌کنند. فرمان‌های شنونده در بالا مستقیم به این پاسخ می‌دهند.

سپس رد کردن را از سکوت جدا کنید. nc -vz 10.6.0.1 443 که اتصال رده‌شده برمی‌گرداند یعنی بسته به روتر رسیده و چیزی ردش کرده، یا درگاه بسته یا قاعدهٔ رد صریح. معلق ماندن تا پایان زمان یعنی بسته انداخته شده یا هرگز مسیریابی نشده است. این تفاوت می‌گوید بعد کدام لایه را بررسی کنید، و پنج ثانیه هزینه دارد.

واسط VPN یک مرز است، نه مسیر بازیابی

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

نقش روتر پاسخ را تغییر می‌دهد. روتری که تونل را پایان می‌دهد می‌تواند به‌طور مشروع مدیران را از آن بپذیرد، در حالی که روتری که تونل را فقط به‌عنوان خروجی اینترنت به کار می‌برد معمولاً نباید چنین کند. در هر دو حالت مجوز زیرشبکه همان ورود نیست، پس احراز هویت حساب و امنیت انتقال را روشن نگه دارید.

حرکت جبرانی که مردم پس از قفل شدن انجام می‌دهند بدتر است: روشن کردن مدیریت WAN یا فرستادن یک درگاه به رابط وب. این یک قطعی کوتاه را به افشای دائمی تبدیل می‌کند و صفحهٔ ورود آنگاه برای هر پویشگر اینترنت در دسترس است. سمت ردشده را هم مانند سمت مجاز آزمایش کنید تا همتایی که نباید دسترسی مدیریت داشته باشد به جای دیدن درخواست ورود، به پایان زمان یا رد شدن برسد.

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

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

پیش از نخستین تغییر چهار چیز را بنویسید: چگونه اگر تونل بمیرد به دستگاه می‌رسید، مانند کنسول سریال، کنسول ارائه‌دهنده یا ماشینی در LAN؛ پیکربندی کنونی کجا برون‌ریزی می‌شود؛ کدام قاعده یا مسیر تکی را می‌خواهید تغییر دهید؛ و چگونه دقیقاً همان مورد را برمی‌گردانید. در OpenWrt فرمان sysupgrade -b /tmp/backup.tar.gz پیکربندی را می‌گیرد و ویرایش‌ها تا uci commit در انتظار می‌مانند، که اگر به‌موقع متوجه شوید به شما بازگردانی ارزانی می‌دهد. pfSense تاریخچهٔ پیکربندی نگه می‌دارد و AutoConfigBackup تنها وقتی کمک می‌کند که از پیش روشن بوده باشد. اگر روتر مجموعه‌ای از قاعده‌های fail-closed دارد، تأیید کنید مسیر نگهداری که برنامه‌ریزی کرده‌اید درون ترافیکی نیست که آن قاعده می‌بندد، و یادتان باشد راه‌اندازی دوباره قاعده‌های پایدار را دوباره اعمال می‌کند نه پاک.

در هر تلاش یک مرز را تغییر دهید، سپس از اتصال تازه آزمایش کنید نه از پوستهٔ بازمانده. اگر آزمایش شکست خورد، همان یک تغییر را پیش از دست زدن به لایهٔ بعد برگردانید. تونل می‌تواند تمام وقت بالا بماند، اما نماد وضعیت سبز آن گواهی نیست که هنوز می‌توانید وارد شوید.

بررسی سریع پیش از رفتن:

• آیا از مبدأیی به روتر می‌رسید که به قاعدهٔ همین حالا ویرایش‌شده وابسته نیست؟
• آیا سیاست ورودی روی واسط تونل تنها مبدأ مدیر را مجاز می‌کند؟
• آیا سرویس مدیریت به آدرسی بسته شده که روی تونل وجود دارد؟
• آیا یک همتای ردشده و یک نشست تازه را آزمایش کرده‌اید؟
• آیا سطح مدیریت WAN هنوز بسته است؟