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

نخست جهت اتصال را رسم کنید

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

curl -s https://ifconfig.me
ip -brief address
traceroute -n 1.1.1.1

NAT دوگانه به معنای VPN دوگانه نیست. ترجمه نشانی‌ها و درگاه‌ها را بازنویسی می‌کند؛ تونل رمزنگاری‌شدهٔ دومی اضافه نمی‌کند و هیچ چیز را رمزنگاری نمی‌کند. جدا نگه داشتن این دو ایده مهم است، چون راه‌حل‌ها کاملاً متفاوت‌اند و یکی از آن‌ها به گفت‌وگو با ارائه‌دهندهٔ شما نیاز دارد، نه به صفحهٔ تنظیمات.

خروجی: کلاینت می‌پرسد، مترجم‌ها نگاشت می‌کنند

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

شکست‌هایی که واقعاً رخ می‌دهند معمولاً به مهلت‌های زمانی و پشتیبانی پروتکل مربوط‌اند، نه به تعداد روترها. تونلی که پس از چند دقیقه سکوت می‌افتد، نگاشتی است که منقضی می‌شود و keepalive پاسخ استاندارد است. IPsec افزونه‌های استاندارد NAT-traversal دارد، پس این ادعا که نمی‌تواند از ترجمه عبور کند صرفاً نادرست است. اگر تونل اصلاً برقرار نمی‌شود، پیش از سرزنش توپولوژی به نقطهٔ پایانی و اعتبارنامه‌ها نگاه کنید.

wg show
ping -c3 10.8.0.1

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

ورودی: هدایت درگاه فقط تجهیزاتی را پوشش می‌دهد که مالک آن هستید

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

nc -vz 203.0.113.10 51820
ss -lunp 'sport = :51820'

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

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

هر بار یک متغیر را بیازمایید

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

journalctl -u wg-quick@wg0 -n 30 --no-pager
ip route get 10.20.30.40

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

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

مقالات مرتبط