چرا مسیر تونل کامل سروری را که آن را حمل می‌کند قطع می‌کند
مسیر پیش‌فرض از میان تونل بسته‌های بیرونی را هم که آن را حمل می‌کنند می‌گیرد. نقطه پایانی را با یک مسیر میزبان تثبیت کنید و پاسخ‌های سرور را بیرون از آن نگه دارید.
تونل کامل را روشن کنید و اکنون هر مقصدی به رابط VPN تعلق دارد، از جمله ماشینی که آن را پایان می‌دهد. بسته‌های بیرونی که تونل را حمل می‌کنند به همان ماشین نشانه‌روی شده‌اند، بنابراین مسیر در نهایت همان انتقالی را مصرف می‌کند که به آن وابسته است. یک مسیر مشخص اضافی این را حل می‌کند و دلیلش ارزش فهمیدن دارد. بدون آن دلیل، بازسازی بعدی دوباره این نقص را وارد می‌کند.
مسیری که انتقال خودش را می‌خورد
کپسوله‌سازی هر بسته را در یک سرآیند دوم می‌پیچد. سرآیند بیرونی از نشانی فیزیکی محلی به نشانی عمومی سرور نشانه‌روی می‌شود و باید پیش از آنکه هر تونلی وجود داشته باشد از پیوند فیزیکی عبور کند.
اکنون بگذارید جست‌وجوی آن نشانی عمومی تونل را انتخاب کند. برای فرستادن بسته، ماشین باید آن را کپسوله کند، که به مسیری به همان نشانی نیاز دارد، و آن مسیر تونل را برمی‌گرداند. کارخواه‌ها این را به یکی از دو روش مدیریت می‌کنند. یک کارخواه محتاط از نصب مسیر پیش‌فرض خودداری می‌کند و خطا گزارش می‌دهد، در حالی که یکی کم‌دقت‌تر موفقیت گزارش می‌کند و سپس هیچ چیزی را جابه‌جا نمی‌کند. شکست خاموش همانی است که یک بعدازظهر را می‌بلعد.
تطبیق بلندترین پیشوند پیش از هر متریکی جست‌وجو را تعیین می‌کند، بنابراین مسیر یک‌نشانی از هر مسیر پیش‌فرض روی ماشین پیشی می‌گیرد. تمام سازوکار پشت این تعمیر همین است.
استثنا را پیش از مسیر پیش‌فرض نصب کنید
برای سرور یک مسیر یک‌نشانی بسازید، با دروازه فیزیکی به‌عنوان گام بعدی، پیش از آنکه مسیر پیش‌فرض جابه‌جا شود. ترتیب مهم است: نصب بعد از آن یعنی زندگی با تونلی خراب در حالی که تایپ می‌کنید.
بیشتر کارخواه‌ها این کار را بدون درخواست انجام می‌دهند. OpenVPN نشانی دور را جست‌وجو می‌کند و پیش از بازنویسی دروازه پیش‌فرض آن را تثبیت می‌کند، و گزینه route-delay آن برای سکوهایی وجود دارد که این توالی در آن‌ها مسابقه می‌دهد. wg-quick مسیر کاملاً دیگری می‌رود، با علامت‌گذاری بسته‌ها و مراجعه به یک قاعده سیاست به‌جای افزودن یک استثنا. سازوکارهای متفاوت، یک نیاز: بسته بیرونی باید از تونلی که می‌سازد بگریزد.
ip route add 203.0.113.10/32 via 192.168.1.1 dev eth0
ip route get 203.0.113.10خروجی جست‌وجو آزمون پذیرش است. باید دستگاه فیزیکی و گام بعدی فیزیکی را نام ببرد. وجود یک دستگاه تونل در آن پاسخ یعنی استثنا غایب است یا بعد از چیزی قرار گرفته که آن را خنثی می‌کند.
تصویر آینه‌ای روی سرور
همان دام در طرف دیگر، برعکس، منتظر است. به سرور یک مسیر پیش‌فرض از طریق تونل دیگر بدهید، یا مسیری به سویش بفرستید که نشانی‌های عمومی کارخواه‌ها را پوشش می‌دهد، و پاسخ‌هایش عادت مسیر اشتباه پیدا می‌کنند.
کارخواهی را تصور کنید که متصل می‌شود و درخواستی می‌فرستد. پاسخ به نشانی عمومی همان کارخواه نشانه‌روی می‌شود، که اکنون با یک مسیر تونل مطابقت دارد، پس از رابط دیگری خارج می‌شود و مبدأیی را حمل می‌کند که کارخواه هرگز آن را شماره‌گیری نکرده است. کارخواه می‌تواند آن بسته را دریافت کند و باز هم دورش بیندازد، چون هیچ چیز آن را به درخواستی که فرستاده پیوند نمی‌دهد. از تصمیم مسیریابی سرور شروع کنید نه از مهلت زمانی کارخواه، چون تنها یکی از آن دو انتخاب واقعی را نشان می‌دهد.
ip route get 198.51.100.44 from 10.90.0.1
ip rule show
sudo tcpdump -ni any host 198.51.100.44سه تعمیر وجود دارد و برابر نیستند. تثبیت سرویس روی نشانی فیزیکی، یا ترجمه مبدأ، هر دو تصمیم مسیریابی را پنهان می‌کنند به‌جای اصلاح آن. فرستادن ترافیک پاسخ استخر تونل از یک جدول اختصاصی علت را برطرف می‌کند، و دو تای دیگر تنها تا زمانی پذیرفتنی‌اند که طراحی مسیریابی ثابت مانده باشد.
استثناهایی که تونل مدام می‌دزدد
مشتی از کارها حتی وقتی تونل مالک مسیر پیش‌فرض است به اینترنت باز نیاز دارند، و هر کدام استثنای خودش را لازم دارد. به‌روزرسان DNS پویا معمولاً نخستین چیزی است که می‌شکند.
ارائه‌دهنده را تجزیه می‌کند، اتصالی باز می‌کند و می‌بیند بسته‌های خودش از تونلی می‌گذرند که نشانی‌اش ثانیه‌هایی پیش تغییر کرده است، پس به‌روزرسانی شکست می‌خورد یا نشانی نادرست را منتشر می‌کند. سه راه خروج: ارائه‌دهنده را با یک مسیر میزبان از دروازه فیزیکی تثبیت کنید، به‌روزرسانی را پیش از بالا آمدن تونل اجرا کنید، یا به به‌روزرسان جدول سیاستی بدهید که تونل هرگز به آن دست نمی‌زند. همگام‌سازی زمان روی دستگاهی که بدون تجزیه‌کننده بوت می‌شود همین مواجهه را دارد، و نقاط پایانی اعتبارسنجی گواهی نیز به همین دلیل در فهرست جای دارند.
استثنایی که کسی آن را ننوشته باشد، استثنایی است که بازسازی بعدی بی‌صدا رهایش می‌کند.
پس از اتصال مجدد اثباتش کنید، نه پیش از آن
سه مقصد را بیازمایید، نه یکی: نقطه پایانی، یک نشانی خصوصی پشت تونل، و یک نشانی عمومی آن‌سوتر. یک جست‌وجوی موفق تقریباً هیچ درباره دو تای دیگر نمی‌گوید.
ip route get 203.0.113.10
traceroute -n 203.0.113.10
ip route get 10.90.0.5
ip route get 1.1.1.1سپس اتصال را از نو برقرار کنید، چون کارخواهی که جدولش را در اتصال مجدد بازسازی می‌کند مسیری را که با دست تایپ کرده‌اید دور می‌اندازد. اگر kill switch فعال است بررسی کنید که نقطه پایانی مجاز باشد، وگرنه تونل پس از تغییر شبکه نمی‌تواند برگردد و نشانه شبیه قطعی به نظر می‌رسد. استثنا را در نمایه یا فایل unit نگه دارید نه در تاریخچه shell، تا اتصال مجدد آن را بازسازی کند نه پاک.