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

VPN را به تونل کامل تغییر می‌دهید، بیشتر ترافیک اطاعت می‌کند، و بعد یک نشانی مستقیماً پاسخ می‌دهد — یک چاپگر، یک NAS، یک میزبان پرش روی 10.x. خوانش بدیهی این است که تونل نشت می‌کند، پس متریک مسیر پیش‌فرض را پایین می‌آورید و هیچ چیز تغییر نمی‌کند. همان تلاش ناموفق سرنخ است: مسیر پیش‌فرض یک جایگزین است، نه حکم. جست‌وجوی مسیر پیش از آنکه هرگز متریک‌ها را مقایسه کند، بلندترین پیشوند منطبق را برمی‌دارد، پس یک /24 بدون توجه به عددی که به هر یک از آن‌ها می‌چسبانید، همچنان بر /0 پیروز می‌شود. وقتی این ترتیب روشن شد، نشت معمولاً مسیری است که کسی عمداً نصب کرده، یا پیشوندی که کارخواه هرگز قصد پوشش آن را نداشت.

مسیر پیش‌فرض واقعاً چه چیزی وعده می‌دهد

0.0.0.0/0 با هر مقصد IPv4 با صفر بیت مشخصه مطابقت دارد. وجود دارد تا میزبان به هر چیزی که جدولش بهتر توصیفش نمی‌کند برسد. مسیر به 192.168.1.0/24 دقیقاً 24 بیت منطبق حمل می‌کند، پس برای 192.168.1.40 پیش از آنکه کسی متریک‌ها، فاصله مدیریتی یا هر نامی که کارخواه برای میدان اولویتش می‌گذارد را مقایسه کند، برنده می‌شود. همین قاعده در FIB لینوکس، جدول مسیریابی ویندوز و پشته BSD پشت macOS برقرار است.

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

نیمه‌مسیرهای پیش‌فرض، یا چرا ورودی پیش‌فرض می‌تواند دست‌نخورده به نظر برسد

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

wg-quick از WireGuard از طریق مسیریابی سیاستی به همان نتیجه می‌رسد. وقتی AllowedIPs کل 0.0.0.0/0 را می‌پوشاند، جدول خودش را می‌سازد، بسته‌های علامت‌خورده را به آنجا می‌فرستد، و قاعده‌ای اضافه می‌کند که پیشوند با طول صفر جدول اصلی را نادیده می‌گیرد. جدول اصلی ورودی پیش‌فرض خود را نگه می‌دارد، و قواعد تعیین می‌کنند که برای ترافیکی که رابط مالک آن است، اول جدول تونل مشورت شود.

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

متریک‌ها تساوی را تعیین می‌کنند، پیشوندها برنده را

متریک‌ها فقط میان نامزدهایی مقایسه می‌شوند که به یک اندازه با مقصد مطابقت دارند. در لینوکس، ip route get 10.20.5.9 برنده را همراه با جدولش چاپ می‌کند، و ip route show table all نامزدها را فهرست می‌کند، از جمله هر نیمه‌مسیر پیش‌فرض و هر جدولی که قاعده‌ای به آن اشاره می‌کند. در ویندوز، Find-NetRoute -RemoteIPAddress 10.20.5.9 مسیر انتخاب‌شده و نشانی مبدأ را برمی‌گرداند، در حالی که Get-NetRoute جدول خام را نشان می‌دهد — اما هزینه مؤثر متریک مسیر به‌علاوه متریک رابط است، پس یک مبدل کند می‌تواند تساوی‌ای را که ظاهراً می‌برد، ببازد.

سه حالت بیشتر آنچه خواهید دید را پوشش می‌دهد:

• همان مقصد، /24 در برابر /0: /24 بر طول پیشوند پیروز می‌شود، هرچه متریک‌ها بگویند.
• همان مقصد، دو /24 با متریک‌های متفاوت: متریک مؤثر کمتر برنده می‌شود.
• همان مقصد، دو جدول، یکی انتخاب‌شده با قاعده سیاست: قاعده اول جدول را انتخاب می‌کند، و مقایسه پیشوند درون آن رخ می‌دهد.

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

معمولاً چه کسی مالک این دور زدن است

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

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

سپس IPv6 را جداگانه بررسی کنید. ip -6 route و Get-NetRoute -AddressFamily IPv6 وضعیت جدا، مسیرهای پیش‌فرض جدا و رفتار کارخواه جدا دارند. حسابرسی فقط IPv4 هیچ چیزی درباره میزبان دوپشته‌ای نمی‌گوید که بی‌صدا مسیر بومی IPv6 را ترجیح می‌دهد، و همین به‌تنهایی می‌تواند کارخواه را شبیه split-tunnel نشان دهد.

با جریان خود برنامه تأیید کنید

مقصدی را که برنامه واقعاً استفاده می‌کند ثبت کنید، سپس از سیستم مسیری را بپرسید که از نشانی مبدأیی که آن برنامه به آن مقید می‌شود طی می‌کند. ip route get 10.20.5.9 from 192.168.1.40 در لینوکس به این پاسخ می‌دهد؛ Find-NetRoute -RemoteIPAddress 10.20.5.9 به‌علاوه نشانی محلی در ویندوز این کار را می‌کند. نتیجه را با آنچه پروفایل ادعا می‌کند مقایسه کنید. صفحه IP عمومی مرورگر یک مقصد را روی یک پروتکل آزمایش می‌کند و درباره نشانی خصوصی‌ای که شکایت را شروع کرده چیزی نمی‌گوید.

تنگ‌ترین شیئی را که تفاوت را توضیح می‌دهد درست کنید. اگر استثنا تأیید شده است، پیشوند را بنویسید و رهایش کنید؛ اگر نه، مسیر را بردارید یا به جای پایین آوردن متریک پیش‌فرض، مسیر باریک‌تر صریحی از تونل اضافه کنید. پایین آوردن متریک نمی‌تواند از پیشوند بلندتر جلو بزند، و ویرایش پیش‌فرض در حالی که دو مسیر /1 مالک مسیر اینترنت‌اند هم چیزی را تغییر نمی‌دهد.

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

• مقصد و نشانی مبدأیی را که برنامه واقعاً استفاده می‌کند نام ببرید.
• مسیر برنده را با ip route get یا Find-NetRoute چاپ کنید.
• بررسی کنید که یک جفت /1 یا یک جدول سیاست مالک مسیر اینترنت است.
• هر پیشوند بلندتر از /0 را که با مقصد مطابقت دارد فهرست کنید.
• بررسی IPv6 را جداگانه تکرار کنید.
• مسیر بازمانده را تا فایل، پروفایل یا فیلتری که آن را نصب می‌کند دنبال کنید.
• پیش از آنکه آن را درست‌شده بنامید، دوباره وصل شوید و پرس‌وجو را دوباره اجرا کنید.

اگر هر هفت با پروفایل موافق باشند، تونل دقیقاً همان کاری را می‌کند که برای آن پیکربندی شده بود، و اصلاح به پروفایل تعلق دارد نه به متریک.