route-gateway همان redirect-gateway نیست: در واقع چه چیزی تغییر می‌کند
این گزینه فقط یک گام بعدی برای مسیرهایی که OpenVPN نصب می‌کند فراهم می‌کند. حذف آن یک تونل کاملِ هل‌داده‌شده را خاموش نمی‌کند و اصلاح به تغییر مسیر تعلق دارد.
تونل شما بالا می‌آید، زیرشبکه خصوصی پاسخ می‌دهد، و مرور معمولی هنوز در VPN ناپدید می‌شود، هرچند کسی خط دروازه را از پروفایل حذف کرده است. این ترکیب اثر انگشت دستور اشتباهی است که ویرایش شده. آنچه حذف شد به کلاینت یک گام بعدی برای مسیرهایی می‌داد که نصب می‌کند؛ آنچه به گرفتن ترافیک ادامه داد از جای دیگری آمد و توسط سرور هل داده شد. پوشش و گام بعدی کارهای جداگانه‌ای هستند و فقط یکی از آن‌ها تعیین می‌کند که آیا مقصدهای عمومی از تونل استفاده می‌کنند.
خطی که حذف کردید یک گام بعدی بود، نه کلید سیاست
هر مسیری که کلاینت نصب می‌کند به یک آدرس دروازه برای اشاره نیاز دارد، و دستور دروازه همان جایی است که این آدرس می‌آید وقتی مسیر خودش هیچ آدرسی را نام نمی‌برد. آن را حذف کنید و آن مسیرها جایی برای اتصال ندارند، بنابراین یا نصب نمی‌شوند یا روی مسیری فرود می‌آیند که به جایی نمی‌رسد. زیرشبکه خصوصی دقیقاً همان چیزی است که چنین مسیری حمل می‌کرد.
در همین حال رفتارِ باقی‌مانده نویسنده دیگری دارد: یک گزینهٔ تغییر مسیر در بلوک هل‌داده‌شده که ترافیک خروجی معمولی را بر اساس پرچم‌هایش به تونل منتقل می‌کند. حذف دروازه نه آن را غیرفعال می‌کند و نه ضعیف. نتیجه بدترینِ هر دو حالت است: ترافیک عمومی همچنان گرفته می‌شود و مقصد خصوصی که تونل را توجیه می‌کرد اکنون دست‌نیافتنی است. به همین دلیل ویرایش دوم هم که با همان روحیه انجام شد چیزی را تغییر نمی‌دهد.
چهار اهرم، چهار کار متفاوت
چهار دستور در این بحث به‌جای یکدیگر نقل می‌شوند و تنها یکی از آن‌ها پوشش را اداره می‌کند، یعنی اینکه کدام مقصدها اصلاً از تونل عبور می‌کنند. دومی گام بعدی‌ای را تعیین می‌کند که مسیرها استفاده می‌کنند، سومی یک پیشوند واحد نصب می‌کند و چهارمی هر چیزی را که سرور هل داده دور می‌ریزد، از جمله مسیرهای خصوصی که استقرار به آن‌ها نیاز دارد. جدول آن‌ها را بر اساس آنچه مدیر می‌خواهد تغییر دهد مرتب می‌کند نه بر اساس نام، چون نام‌ها هستند که سردرگمی را ایجاد می‌کنند. با آن‌ها به‌عنوان چهار تصمیم جدا رفتار کنید و آنی را انتخاب کنید که واقعاً می‌خواهید برگردانید.
در عمل هر چهار غالباً در یک بلوک هل‌داده‌شده، خط به خط، می‌رسند و این باعث می‌شود بخش‌هایی از یک تنظیم واحد به نظر برسند. این‌طور نیستند، و مرجع OpenVPN دقیقاً به همین دلیل آن‌ها را سازوکارهای متمایز مستند می‌کند. فهمیدن اینکه کدام تصمیم را برمی‌گردانید کار است؛ ویرایش یک خط است.
| What you are trying to change | Directive that decides it | What it leaves alone |
|---|---|---|
| Which destinations use the tunnel | redirect-gateway | Per-prefix routes and resolver choice |
| The next hop a pushed route points at | route-gateway | Coverage of public destinations |
| One reachable prefix | route | Every other destination, default path included |
| All pushed routing and DNS at once | route-nopull | Nothing, which is the problem |
خط هل‌داده‌شده را فیلتر کنید، گام بعدی را نگه دارید
اگر پوششی که به آن اعتراض دارید به‌صورت یک گزینهٔ هل‌داده‌شده می‌رسد، پاسخ باریک این است که آن گزینه را با نامش نادیده بگیرید و بقیهٔ بلوک هل‌داده‌شده را دست‌نخورده بگذارید. وقتی به‌صورت فیلتر نوشته شود شبیه خط زیر است و جای آن در پروفایل کلاینت متأثر است نه در پیکربندی سرور.
pull-filter ignore "redirect-gateway"باریکی همان نکته است. چون فیلتر یک پیشوند متنی را مقایسه می‌کند، الگوی کوتاه‌تر با دستور گام بعدی هم مطابقت دارد و دقیقاً همان اطلاعاتی را که مسیرهای خصوصی به آن وابسته‌اند برمی‌دارد و خطای اصلی را در لباس جدید تکرار می‌کند. فیلتر همچنین فقط روی گزینه‌های هل‌داده‌شده عمل می‌کند، پس هرگز به خطی معادل که به‌صورت محلی نوشته شده یا توسط مدیر شبکه تحمیل شده دست نمی‌زند. پس از آن دوباره وصل شوید، چون نشست زنده آنچه سرور هل داده را دوباره ارزیابی نمی‌کند.
جستجو را بخوانید، نه جدول را
پس از بارگذاری مجدد پروفایل، از کرنل بپرسید دو مقصد واقعاً کجا می‌روند: یکی داخل پیشوند خصوصی و یکی در اینترنت عمومی. تخلیهٔ کامل جدول اصلی سخت‌تر خوانده می‌شود و راحت‌تر بد خوانده می‌شود، چون یک مسیر می‌تواند وجود داشته باشد و باز هم به تطابق مشخص‌تری ببازد. در مسیریابی مبتنی بر سیاست، قاعده، جدول و آدرس مبدأ هم بخشی از بررسی هستند.
ip route get 10.40.7.25
ip route get 203.0.113.77
ip rule showگونهٔ def1 شایستهٔ آشنایی است، چون ورودی پیش‌فرض قدیمی را قابل مشاهده می‌گذارد در حالی که یک جفت نیمه‌پیش‌فرض جستجو را می‌برند. بنابراین یک خط 0.0.0.0/0 در خروجی به‌خودی‌خود چیزی را ثابت نمی‌کند. جستجو به پرسشی پاسخ می‌دهد که فهرست فقط به نظر می‌رسد پاسخش می‌دهد.
DNS، IPv6 و مسیر خصوصی هنوز باید کار کنند
رد کردن یک تغییر مسیر IPv4 هیچ چیزی دربارهٔ حل‌کننده نمی‌گوید، پس یک گزینهٔ DNS هل‌داده‌شده می‌تواند به فرستادن پرس‌وجوها به تونل ادامه دهد در حالی که مسیرها درست به نظر می‌رسند. یک پیش‌فرض IPv6 می‌تواند همین کار را برای خانوادهٔ آدرسی بکند که بررسی IPv4 هرگز به آن دست نزده است. هر دو به تصمیمی صریح نیاز دارند نه به یک فرض. سپس تأیید کنید که سرویس خصوصی هنوز پاسخ می‌دهد، چون تونل شکافته‌ای که مسیر خصوصی‌اش را از دست داده تونل شکافته نیست، شکسته است.
یک ابزار گسترده‌تر شایستهٔ هشدار است: route-nopull هر مسیر هل‌داده‌شده و هر گزینهٔ DNS هل‌داده‌شده را دور می‌ریزد، که قطعاً تونل کامل را متوقف می‌کند و به همان اندازه قطعاً مسیرهای خصوصی‌ای را که استقرار به آن‌ها وابسته است می‌شکند، پس چکش بسیار بزرگ‌تری از یک فیلتر نام است که یک گزینه را هدف گرفته. پس از هر تغییری مقصد خصوصی، یک مقصد عمومی و حل‌کننده را بررسی کنید و دست‌دادن کامل‌شده را شاهدی برای چیزی جز خود دست‌دادن ندانید.