چگونه یک مقصد IPv4 را بیرون از تونل OpenVPN بفرستیم

بیشتر پیکربندی‌های تونل کامل هر بسته را از VPN می‌فرستند و دستور redirect-gateway همین کار را ممکن می‌کند. با این حال یک مقصد تنها را می‌توان استثنا کرد. افزودن یک مسیر میزبان برای آن نشانی با جای‌نگهدار net_gateway به سرویس‌گیرنده می‌گوید که از دروازه اصلی دستگاه به آن برسد، در حالی که بقیه چیزها همچنان از تونل استفاده می‌کنند.

خط ظاهراً بی‌خطر است و اغلب هم هست، اما تنها یک پرسش را روشن می‌کند: بسته‌های مربوط به همان نشانی دقیق IPv4 کجا می‌روند. این خط DNS، IPv6، سیاست دیوار آتش یا اینکه کدام فرایند اتصال را باز کرده تغییر نمی‌دهد، و هر یک از این‌ها می‌تواند استثنا را بی‌صدا از کار بیندازد.

net_gateway در واقع چه چیزی را نام می‌برد

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

جای‌نگهدار سوم، remote_host، به نشانی سرور VPN اشاره دارد و وجودش برای این است که تونل بتواند از مسیر فیزیکی به سرور برسد. اشتباه گرفتن این سه، رایج‌ترین دلیل رفتن یک استثنا به جای اشتباه یا نصب نشدن آن است.

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

چرا مسیر میزبان بر مسیر پیش‌فرض تونل پیروز می‌شود

مسیریابی با دقیق‌ترین پیشوند منطبق تعیین می‌شود. redirect-gateway def1 معمولاً مسیر پیش‌فرض را جایگزین نمی‌کند؛ دو نیمه اضافه می‌کند، یک مسیر برای نیمه پایین فضای نشانی و یکی برای نیمه بالا، بنابراین مسیر پیش‌فرض اصلی برای کاربردهای دیگر حفظ می‌شود. این نیمه‌ها از یک نشانی گسترده‌ترند.

مسیر یک نشانی با ماسک 255.255.255.255 یک /32 است، که دقیق‌ترین حدی است که IPv4 می‌تواند داشته باشد. وقتی بسته‌ای برای آن نشانی ارزیابی می‌شود، /32 منطبق می‌شود و صرف‌نظر از اینکه کدام مسیر اول نصب شده پیروز می‌شود. این سازوکار پشت استثناست و تا زمانی که مسیر واقعاً وجود داشته باشد، روی Linux، macOS و Windows یکسان کار می‌کند.

Windows بُعد دومی اضافه می‌کند. وقتی دو مسیر به یک اندازه دقیق باشند، مسیر با متریک کمتر پیروز می‌شود و کارت شبکه VPN می‌تواند متریک رابطی داشته باشد که نتیجه را تغییر دهد. /32 هنوز از نیمه‌ها دقیق‌تر است، بنابراین استثنا معمولاً برقرار می‌ماند، اما یک مسیر کهنه از نشست قبلی اگر به همان اندازه دقیق باشد می‌تواند نتیجه گیج‌کننده‌ای بدهد.

استثنا چه چیزی را پوشش نمی‌دهد

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

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

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

بررسی استثنا بدون فریب دادن خود

با مسیر نصب‌شده شروع کنید، نه با مرورگر. در Linux از هسته بپرسید برای آن نشانی مشخص کدام مسیر و پرش بعدی را استفاده می‌کند؛ در Windows جدول مسیرهای آن /32 را بخوانید. تأیید کنید که دروازه همان دروازه فیزیکی است و نه تونل. اگر ورودی نیست، پروفایل اعمال نشده یا سرویس‌گیرنده مجوز تغییر مسیرها را نداشته است.

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

در پایان، کنترل‌هایی را بررسی کنید که می‌توانند بر مسیر غلبه کنند. کلید کشتار سمت سرویس‌گیرنده یا تنظیم block-outside-dns در Windows می‌تواند ترافیک مستقیم را ممنوع کند، که به صورت اتصالی که با وجود درست بودن مسیر شکست می‌خورد دیده می‌شود. آن کنترل‌ها را غیرفعال نکنید تا استثنا کار کند به نظر برسد؛ اگر سیاست مسیر مستقیم را ممنوع می‌کند، استثنا مشکلی طراحی برای صاحب سرویس VPN است.

پس از اتصال دوباره یا تغییر شبکه دوباره بررسی کنید، چون دروازه پیش از VPN و مسیر موجود ویژگی‌های همان لحظه‌اند، نه ویژگی‌های پروفایل.