پاسخ از LAN خارج می‌شود، نه از تونل: چرا و چگونه
درخواستی که از تونل می‌رسد به این معنا نیست که پاسخ از همان مسیر خارج می‌شود. لینوکس مقصد را جست‌وجو می‌کند و معمولاً زیرشبکه محلی برنده می‌شود.
سرویسی که از طریق یک دروازه منتشر می‌شود از بیشترِ اینترنت کار می‌کند و از یک دفتر شکست می‌خورد. کسی تونل را بررسی می‌کند، می‌بیند درخواست می‌رسد و نتیجه می‌گیرد که پاسخ باید از همان مسیر برگردد. لینوکس این‌گونه کار نمی‌کند و هیچ بررسی‌ای در تونل این پاسخ را تغییر نمی‌دهد. پاسخ بر اساس مقصد مسیریابی می‌شود و همان یک تماس‌گیرندهٔ ناکام در زیرشبکه‌ای قرار دارد که میزبان از قبل مستقیم به آن دسترسی دارد.
چه چیزی واقعاً دربارهٔ یک بستهٔ خروجی تصمیم می‌گیرد
هسته برای مقصد بسته یک مسیر جست‌وجو می‌کند، قواعد سیاست را به ترتیب اولویت و سپس جدولی را که قاعدهٔ منطبق انتخاب می‌کند بررسی می‌کند. واسطی که بسته از آن رسیده هیچ نقشی ندارد، مگر اینکه قاعده یا علامتی نوشته شده باشد تا آن را مهم کند. این واقعیتی دربارهٔ مسیریابی همین میزبان است، نه نقصی در تونل.
بنابراین درخواستی که از تونل دریافت می‌شود می‌تواند پاسخی تولید کند که از واسط فیزیکی خارج می‌شود، و جریان بدون اینکه هیچ دستگاهی خطایی گزارش کند یک‌طرفه می‌شود. پیش از نتیجه‌گیری دربارهٔ تونل هر دو جهت را بررسی کنید. پاسخی که از جهت اشتباه خارج شود از شمارنده‌های تونل ناپدید می‌شود، و به همین دلیل دو سر دربارهٔ اینکه چیزی فرستاده شده یا نه هم‌نظر نیستند. پیش از دست‌زدن به هر قاعده توجه کنید کدام شمارنده تغییر کرده است.
چرا زیرشبکه محلی برنده می‌شود
میزبانی که نشانی در یک شبکهٔ محلی دارد، در جدول اصلی یک مسیر متصل برای آن پیشوند دارد، و مسیر متصل یک تطابق مستقیم است. وقتی تماس‌گیرنده از همان زیرشبکه می‌آید، جست‌وجو پیش از آنکه تونل حتی در نظر گرفته شود پیوند محلی را پیدا می‌کند.
همین عدم تقارن است که تشخیص را گیج‌کننده می‌کند. تماس‌گیرندگان از اینترنت گسترده‌تر کار می‌کنند چون با هیچ مسیر محلی منطبق نیستند، در حالی که تنها تماس‌گیرنده‌ای که پیشوند دفتر را شریک است شکست می‌خورد، و این دقیقاً همان تماس‌گیرنده‌ای است که کسی با آن آزمایش می‌کند.
پوشش همتاها همان مسیرهای نصب‌شده نیست
در سمت تونل، بازه‌های مجاز یک همتا توصیف می‌کند چه چیزی می‌تواند به تونل فرستاده شود و کدام منابع از آن پذیرفته می‌شوند. آن‌ها هیچ چیزی دربارهٔ اینکه جدول مسیریابی محلی بسته را کجا می‌فرستد نمی‌گویند.
اگر ابزار تونل یک مسیر پیش‌فرض روی میزبان نصب کند، می‌تواند ترافیک نامرتبط را به‌عنوان آسیب جانبی به تونل بکشد. جایی که به‌جای آن باید یک قاعدهٔ سیاست تصمیم را در دست بگیرد، گزینهٔ نصب مسیر ابزار دقیقاً برای جلوگیری از همین کار وجود دارد، و نشانی‌ها، کلیدها و تنظیمات نقطهٔ پایانی دقیقاً همان‌گونه که بودند می‌مانند. مسیر پیش‌فرضی که برای راحتی افزوده شود راهی رایج است که میزبان شبکهٔ محلی خود را از دست می‌دهد.
جدول را بر پایهٔ نشانی منبع انتخاب کنید
قاعده‌ای بر پایهٔ منبع، پاسخ‌ها را از نشانی سرویس به جدولی خصوصی می‌فرستد که پیش‌فرض آن تونل است، در حالی که هر چیز دیگری به استفاده از جدول اصلی ادامه می‌دهد. شماره‌های جدول و اولویت را انتخاب کنید که محلی استفاده نمی‌شوند، و پیش از درج هر چیزی قواعد موجود را بخوانید. قواعد زنده را بخوانید نه یک فایل ذخیره‌شده، زیرا این دو می‌توانند پس از راه‌اندازی مجدد متفاوت باشند.
ip -6 route add default dev wg0 table 200
ip -6 rule add priority 32000 from 2001:db8:aa::20/128 lookup 200
ip -6 rule add priority 32001 from 2001:db8:aa::20/128 unreachableخط آخر باعث می‌شود مسیر غایب به‌جای بازگشت به پیوند محلی به‌صورت دیدنی شکست بخورد. منبع باید واقعاً به میزبان اختصاص یافته باشد، و جست‌وجوهای معمول محلی و اصلی باید در جایگاه‌های پیشین خود بمانند. قاعده جدول را بر پایهٔ منبع انتخاب می‌کند؛ طول پیشوندها را میان جدول‌ها مقایسه نمی‌کند.
مسیر را تأیید کنید، سپس سرویس را
از هسته بپرسید چه می‌کرد به‌جای آنکه از یک ضبط نتیجه بگیرید، و نشانی سرویس را به‌عنوان انتخابگر منبع به کار ببرید. پاسخ نادرست در اینجا یک ردیابی کامل بسته را صرفه‌جویی می‌کند.
ip -6 route get 2001:db8:bb::30 from 2001:db8:aa::20خروجی باید نام تونل را بیاورد. سپس منبعی را که به آن دست نزده‌اید آزمایش کنید و تأیید کنید که هنوز پیوند محلی را برمی‌گزیند، تا تغییر به یک نشانی محدود مانده باشد. انتخابگر گسترده‌تر چیزی دربارهٔ شکایت اصلی ثابت نمی‌کرد.
چیزی که این اصلاح نمی‌کند
ارسال به جلو، قواعد دیوار آتش و رفتار ICMPv6 را روی دروازه همان‌گونه که بودند نگه دارید، زیرا مسیر منبع هیچ‌یک از آن‌ها را جایگزین نمی‌کند. پیام Packet Too Big که غایب است هنوز پاسخ‌های بزرگ را می‌شکند، هر جدولی که در جست‌وجو برنده شود. این را پیش از افزودن قواعد مسیریابی درست کنید، وگرنه نشانه از تغییر جان سالم به در می‌برد.
پیش از اعمال هر یک از این‌ها مدل انتشار را تأیید کنید. پروکسی معکوسی که اتصال بک‌اند خود را باز می‌کند منبع خود را ارائه می‌دهد و تماس‌گیرنده را حفظ نمی‌کند، پس این نقص در آن طراحی نمی‌تواند رخ دهد. اعمال قاعده در آنجا یک استثنای مسیریابی اضافه می‌کرد که چیزی را حل نمی‌کند و علت واقعی را پنهان می‌سازد.
در پایان، شماره‌های قاعده و جدول را در مدیریت پیکربندی میزبان بنویسید. قاعدهٔ سیاستی که دستی افزوده شود در بازسازی بعدی ناپدید می‌شود و تماس‌گیرندهٔ دفتر با همان شکایت بازمی‌گردد.