تونل کامل نشست SSH شما را کشت: مسیر بازگشت را پین کنید

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

redirect-gateway در واقع چه چیزی نصب می‌کند

در شکل def1 redirect-gateway به جای بازنویسی مسیر پیش‌فرض، 0.0.0.0/1 و 128.0.0.0/1 را اضافه می‌کند. این دو نیمه کل فضای نشانی را پوشش می‌دهند و هر دو پیشوندهای بلندتری از 0.0.0.0/0 باقی می‌مانند، بنابراین هر مقصدی بدون تطابق مشخص‌تر اکنون به تونل می‌رود. این همان سازوکاری است که باید نگه داشت، چون هر اصلاحی در ادامه با نصب تطابق مشخص‌تر کار می‌کند.

نشانی مدیریت شما یکی از همان مقصدهاست.

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

ip route show table main | head -n 20
ip route get 198.51.100.23

نشانی مبدأ و مسیر پیش از تونل را پیدا کنید

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

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

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

یک مسیر میزبان پین کنید که از نیمه‌مسیرهای پیش‌فرض پیشی می‌گیرد

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

ip route add 198.51.100.23/32 via 203.0.113.1 dev eth0

با یک جست‌وجو بررسی کنید نه با نگاه کردن به جدول: پاسخ باید eth0 و دروازه را نام ببرد، هرگز tun0.

OpenVPN از پیش یک مسیر میزبان به نشانی خود سرور VPN را به همین دلیل اضافه می‌کند، پس الگو آشناست و نشانی مدیریت صرفاً یک استثنای دیگر است. برای رفع این مشکل به route-nopull دست نزنید، چون مسیرهای هل‌داده‌شده‌ای را که تونل لازم دارد دور می‌ریزد، از جمله شبکه دور و گزینه‌های DNS.

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

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

هم route-up اسکریپت و هم قلاب pre-up مدیر شبکه کار می‌کنند، و بررسی قابل اعتماد یک اتصال دوباره و سپس همان جست‌وجوست.

در Windows معادل آن یک مسیر پایدار است که با -p اضافه می‌شود، که از راه‌اندازی دوباره جان سالم به در می‌برد اما پس از تغییر شبکه هنوز باید به دروازه درست اشاره کند. پلتفرم هر چه باشد، دلیل را کنار مسیر بنویسید: مدیر بعدی باید بداند که این مسیر برای محافظت از یک نشست مدیریت وجود دارد، نه به این دلیل که طراحی شبکه آن را الزام کرده بود.

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

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

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

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