وقتی کلاینت VPN وصل می‌شود وب‌سرور ناپدید می‌شود

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

نشانه: درخواست‌ها به داخل، پاسخ‌ها از درِ اشتباه به بیرون

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

با نگاه کردن به مقصد پاسخ آن را تأیید کنید، نه با نگاه کردن به رسیدن درخواست.

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

دو مسیر پیش‌فرض و یک تصمیم مسیریابی

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

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

تونل در تمام مسیر درست رفتار می‌کند. به آن گفته شده بود مسیر پیش‌فرض را حمل کند و دقیقاً همان را انجام می‌دهد.

مسیر برگشت را بدون شکستن تونل درست کنید

سه شکل پایدار تعمیر وجود دارد و انتخاب به این بستگی دارد که چه مقدار از ترافیک خود میزبان باید داخل تونل بماند. مستثنا کردن مقصد یا پورت سرویس کوچک‌ترین تغییر است. مسیریابی سیاستی بر اساس مبدأ یا نشانه دقیق‌ترین است. ترجمه مبدأ خام‌ترین و دو سال بعد آسان‌ترین برای توضیح است.

بر اساس کاری که میزبان باید بکند انتخاب کنید، نه بر اساس اینکه کدام قطعه را اول پیدا کردید.

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

ip rule show
ip route get 203.0.113.9 from 192.0.2.44

وقتی میزبان برای LAN پشت خود هم مسیریابی می‌کند

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

دو تغییر آن را درست می‌کند: ترجمه مقصد تا اتصال ورودی به دستگاه داخلی برسد، و ترجمه مبدأ تا پاسخ آن دستگاه به نظر برسد که از خود روتر می‌آید.

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