مسیریابی بازگشتی: وقتی تونل بسته‌های خودش را می‌گیرد
تونل می‌تواند بسته‌هایی را که آن را می‌سازند بگیرد. مسیر تا سرور را پیش و پس از تغییر مسیر پیش‌فرض مقایسه کنید و سپس صاحب آن مسیر را درست کنید.
تونل بالا می‌آید، گزارش دست‌دادن کامل‌شده را نشان می‌دهد و یک ثانیه بعد همان نشست می‌میرد و در حلقه دوباره وصل می‌شود. این الگو علت مشخصی دارد: مسیر تا سرور اکنون به داخل تونل اشاره میکند، پس بسته‌هایی که تونل را حمل می‌کنند از درون تونل فرستاده می‌شوند. در احراز هویت چیزی تغییر نکرده است، به همین دلیل وارد کردن دوباره اطلاعات ورود تفاوتی ایجاد نمی‌کند. مسیر بیرونی را پیش و پس از تغییر مسیر مقایسه کنید تا بازگشت نمایان شود.
نخست مسیر بیرونی را بررسی کنید
دو بسته در کار است، نه یکی. بسته درونی به برنامه تعلق دارد و باید رمزگذاری شده باشد، در حالی که بسته بیرونی به سرور نشانه‌گذاری شده و باید از مسیری به آن برسد که به تونل وابسته نباشد.
ip route get 198.51.100.7
ip rule show
ip route show table all | grep -F 198.51.100.7
wg show wg0 endpointsپس از بالا آمدن تونل از هسته مسیر تا نشانی سرور را بپرسید و بار دیگر پس از تغییر مسیر پیش‌فرض. پرش بعدی که روی دستگاه تونل فرود می‌آید همان بازگشت است و بدون هیچ عکس‌برداری از بسته دیده می‌شود. اتصال به رابط، نشانه‌ها یا فضای نام شبکه می‌توانند یک جست‌وجوی ساده را ناقص کنند، پس همان زمینه‌ای را به کار ببرید که خودِ کارخواه استفاده میکند. وقتی پاسخ درست به نظر می‌رسد اما نشست هنوز در حلقه است، قواعد سیاست مسیریابی را بخوانید، نه فقط جدول اصلی را.
چرا نشست لحظه‌ای دوام می‌آورد
دست‌دادن پیش از نصب مسیر تازه کامل می‌شود، بنابراین ثانیه‌های نخست سالم به نظر می‌رسند. همین‌که کارخواه مسیر پیش‌فرض را اضافه میکند، بسته بیرونی بعدی آن را به درون رابطی دنبال میکند که آن بسته بیرونی باید از آن بگذرد. سرور چیزی نمی‌بیند، کارخواه دوباره می‌فرستد و تلاش یا به پایان مهلت می‌رسد یا نشست را می‌کشد و از نو شروع میکند.
همین ترتیب توضیح می‌دهد چرا تونل روی یک لپ‌تاپ کار میکند و روی یک مسیریاب شکست می‌خورد، و چرا شکست اغلب با آغاز ترافیک شروع می‌شود نه هنگام اتصال. حلقه را هم توضیح می‌دهد: هر راه‌اندازی دوباره نشست را بازمی‌سازد، پیش از آنکه مسیر آن را ناممکن کند.
پیدا کنید استثنای نقطه پایانی از آنِ کیست
کارخواه‌های پشتیبانی‌شده استثنای خود را ترتیب می‌دهند: مسیری میزبان تا سرور از دروازه اصلی، یا نشانه‌ای که سوکت بیرونی را بیرون از تونل نگه می‌دارد. پرسش این است که آیا چیز دیگری آن را حذف کرده یا زیر پا گذاشته است.
در IPsec مبتنی بر مسیر، انتخابگرهای سیاستی را که تعیین می‌کنند کدام بسته‌ها وارد تونل شوند بررسی کنید و تأیید کنید که نشانی همتا از آنها بیرون گذاشته شده است. در WireGuard، نشانه دیوار آتش رابط و قواعد سیاست آن بسته‌های انتقال را بیرون از تونل نگه می‌دارند، پس مسیر پیش‌فرضی که دستی اضافه شود می‌تواند این ترتیب را بشکند. نمایه دوم VPN یا اسکریپت مدیریتی که مسیر پیش‌فرض را بازنویسی میکند مقصر رایجی است. قواعد عبور گسترده‌ای که یکی‌یکی اضافه می‌شوند نتیجه معمول‌اند و یک اشکال مسیریابی را به جدولی تبدیل می‌کنند که هیچ‌کس نمی‌تواند نگه دارد.
پس از تغییر شبکه دوباره بررسی کنید
مسیر میزبان از طریق دروازه Wi-Fi تا وقتی ماشین به شبکه دیگری منتقل نشده درست است. آنگاه همان نشانه بدون هیچ تغییری در پیکربندی بازمی‌گردد.
نشانی نقطه پایانی، مسیر پیش و پس از اتصال و رابطی که هر یک به کار برده است را ثبت کنید. این سه واقعیت معمولاً اشکال کارخواه را از زیر پا گذاشتن جدا میکند و پس از رفتن کسی که آنها را گرد آورده باقی می‌مانند.
روی شبکه تازه دوباره وصل شوید و خواندن را تکرار کنید. اگر استثنا دوباره غایب بود، اصلاح به نمایه‌ای تعلق دارد که آن را دارد، نه به فرمان یک‌باره‌ای که هنگام قطعی تایپ شده است.