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

پاسخ مسیریابی می‌شود، نه به یاد سپرده

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

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

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

ip route show default
sysctl net.ipv4.conf.all.rp_filter net.ipv4.conf.eth0.rp_filter
nft list ruleset | grep -A3 'hook forward'

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

سه راه برای حفظ مسیر بازگشت

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

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

ip rule add from 203.0.113.25/32 table 100 priority 100
ip route add default via 192.0.2.1 dev eth0 table 100
ip route get 198.51.100.7 from 203.0.113.25

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

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

وقتی جعبه برای یک LAN هم مسیریابی می‌کند

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

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

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

سه آزمون که علت‌ها را جدا می‌کند

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

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

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

مقالات مرتبط