مسیر پیش‌فرض قدیمی شما عمداً بعد از OpenVPN باقی می‌ماند

تونل را متصل می‌کنید، ip route را اجرا می‌کنید و دروازه پیش‌فرض اصلی هنوز همان‌جاست. فکر بعدی این است که کلاینت مسیر را به دست نگرفته، پس مسیر پیش‌فرض را دستی حذف می‌کنید و اتصال را کاملاً از دست می‌دهید. آن ورودی باید بماند. با redirect-gateway def1، OpenVPN دو مسیر خاص‌تر نصب می‌کند که به‌جای جایگزینی، از مسیر پیش‌فرض معمولی بالاتر می‌روند. دروازه قدیمی می‌ماند و دیگر ترافیکی را که آزمایش می‌کردید حمل نمی‌کند.

def1 در واقع چه می‌کند

این پرچم 0.0.0.0/1 و 128.0.0.0/1 را اضافه می‌کند، هر دو به سمت تونل. 0.0.0.0/1 هر نشانی را می‌گیرد که اکتت اولش از 0 تا 127 است، و 128.0.0.0/1 از 128 تا 255 را می‌گیرد، بنابراین هر مقصد IPv4 تطبیقی خاص‌تر از مسیر پیش‌فرض قدیمی دارد. طول پیشوند، نه متریک، تعیین می‌کند کدام مسیر برنده می‌شود.

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

چرا /1 و نه /0

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

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

یک جدول مسیریابی واقعی بخوانید

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

default via 192.168.50.1 dev wlan0
0.0.0.0/1 via 10.8.0.1 dev tun0
128.0.0.0/1 via 10.8.0.1 dev tun0

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

بررسی کنید بسته واقعاً از کدام مسیر می‌رود

مسیرهای خاص‌تر هنوز می‌توانند برنده شوند: مسیری برای یک محدوده خصوصی، یک زیرشبکه محلی یا نشانی خود سرور VPN از /1 بلندتر است. تونل به یک مسیر بیرونی به سرور خودش نیاز دارد و فرستادن آن اتصال به تونل فوراً آن را می‌شکند. در Linux به جای خواندن جدول با چشم، از هسته بپرسید: ip route get با مقصدی که برایتان مهم است، مسیر انتخاب‌شده، رابط و مبدأ را چاپ می‌کند. اگر مسیریابی سیاستی پیکربندی شده باشد، قواعد را هم بررسی کنید، چون یک قاعده می‌تواند پیش از مراجعه به جدول اصلی، جدول دیگری را انتخاب کند.

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

def1 چه چیزی را پوشش نمی‌دهد

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

یک کلید قطع به پرسش دیگری پاسخ می‌دهد: دستگاه وقتی تونل می‌افتد چه می‌کند. اولویت مسیرها تعیین می‌کند تا وقتی تونل بالاست ترافیک کجا برود؛ تعیین نمی‌کند دیوار آتش بعداً چه می‌کند. ترتیب کار: جدول را بخوانید، تأیید کنید هر دو نیمه وجود دارند، ip route get را برای مقصد ناموفق اجرا کنید، قواعد سیاستی را بررسی کنید و بعد جداگانه به IPv6 نگاه کنید. مسیر پیش‌فرض قدیمی را همان‌جا که هست بگذارید.