VPN وصل می‌شود اما به دستگاه‌های LAN نمی‌رسد: چه چیزی را بررسی کنیم
دروازه به نشانی خودش پاسخ می‌دهد، در حالی که هیچ‌چیز پشت آن پاسخ نمی‌دهد. جریان کارخواه را قدم‌به‌قدم دنبال کنید تا مرزی که شکست می‌خورد را پیدا کنید.
ترافیک وارد تونل می‌شود، دروازه به نشانی خودش پاسخ می‌دهد و هیچ‌چیز پشت آن پاسخ نمی‌دهد. این الگو رایج است و تناقض نیست: پاسخ دروازه ثابت می‌کند که تونل پایان یافته و هیچ‌چیز درباره آنچه برای بسته‌ای که به فراتر از آن نشانی شده رخ می‌دهد ثابت نمی‌کند. دو آزمون مسیرهای کد متفاوتی را روی همان ماشین به کار می‌گیرند.
از این پس چیزی را در آن سوی دروازه بیازمایید. نشانی خود دروازه پاسخ‌دادن را ادامه می‌دهد، هر‌قدر هم که هدایت بسته خراب باشد.
دروازه از پشته خودش پاسخ می‌دهد
بسته‌ای که به دروازه نشانی شده به مسیر ورودی محلی آن تحویل داده می‌شود، جایی که هسته تصمیم می‌گیرد آیا سوکتِ در حال گوش‌دادن آن را می‌پذیرد. بسته‌ای که به میزبانی پشت دروازه نشانی شده، به‌جای آن به مسیر هدایت تحویل داده می‌شود، جایی که مجموعه دیگری از بررسی‌ها اعمال می‌شود. هدایت می‌تواند کاملاً غیرفعال باشد، یا هسته آن را فعال کند و سپس قاعده فیلتری که هرگز از تونل نام نمی‌برد آن را رد کند. هیچ‌یک از این‌ها بر پاسخ خود دروازه اثر نمی‌گذارد، و به همین دلیل این نشانه چنین قابل‌اعتماد گمراه می‌کند.
صفحه‌های مدیریتی که از طریق تونل به آن‌ها می‌رسید نیز به دسته اول تعلق دارند. آن‌ها شاهدی درباره تونل هستند، نه درباره شبکه پشت آن.
جریان را تا نخستین مرزی که آن را رها می‌کند دنبال کنید
از کارخواه شروع کنید و مسیر و نشانی مبدأ را که جریان استفاده خواهد کرد تأیید کنید. سپس دروازه را برای رسیدن همان جریان دقیق، و بار دیگر برای خروج همان جریان به سوی LAN زیر نظر بگیرید. اگر هرگز نمی‌رسد، مشکل در سمت کارخواه یا در پیشوندهای مجاز تونل است. اگر می‌رسد و هرگز خارج نمی‌شود، مشکل در هدایت یا در فیلتر مسیر رو به جلو است، و ضبط تصویر از قبل گفته است کدام.
اجرای همان آزمون از دروازه نیمه جالب را پنهان می‌کند، چون بسته‌ای که از دروازه سرچشمه می‌گیرد مبدأ دیگری و شرط برگشت دیگری دارد. در هر قدم از جریان کارخواه، با نشانی مبدأ خودش، استفاده کنید. ضبطی که روی رابط اشتباه گرفته شود، بی‌معنای مطمئن تولید می‌کند.
مسیرهای برگشت و دیوارهای آتش میزبان جداگانه شکست می‌خورند
وقتی بسته به میزبان می‌رسد، سه چیز دیگر باید برقرار باشد. سرویس باید روی نشانی‌ای که بسته به آن فرستاده شده گوش دهد، دیوار آتش میزبان باید آن را بپذیرد، و پاسخ باید مسیری به عقب به سوی استخر کارخواهان داشته باشد. مورد آخر اغلب شکست می‌خورد، چون مسیر پیش‌فرض میزبان به مسیریابی اشاره می‌کند که هرگز از محدوده تونل نشنیده است. نتیجه اتصالی است که از دید میزبان برقرار می‌شود و در جهت دیگر بی‌صدا می‌میرد.
مسیر برگشت را عمداً با فرستادن از کارخواه و پایش برگشت بیازمایید. ضبط یک‌طرفه در چند ثانیه چیزی را روشن می‌کند که یک ساعت گمانه‌زنی روشن نمی‌کند.
هر گام را با نشانی مبدأ کارخواه تأیید کنید
بررسی‌ها را به ترتیب اجرا کنید و هر خروجی را نگه دارید، چون ارزش در مقایسه است نه در یک خط تنها. فرمان‌های زیر نشانی مبدأ را تثبیت می‌کنند، مسیر انتخاب‌شده را نشان می‌دهند و هر دو سوی هدایت را ضبط می‌کنند. میزبان LAN و رابط تونل خودتان را جایگزین کنید.
ip route get 192.168.50.20 from 10.8.0.2
ping -I 10.8.0.2 -c 3 192.168.50.20
sudo tcpdump -ni tun0 host 192.168.50.20
sudo tcpdump -ni br0 host 192.168.50.20پرسش مسیر نشان می‌دهد آیا کارخواه اصلاً آن بسته را به تونل می‌فرستد، و ping نشان می‌دهد آیا چیزی از میزبان برگشته است. مقایسه دو ضبط، رسیدن را از خروج جدا می‌کند، چون قابی روی رابط تونل بدون همتای خود روی رابط LAN تصمیم هدایت است نه نقص سرویس. وقتی هر دو ضبط درخواست را نشان می‌دهند و تنها یکی پاسخ را، مسیر برگشت مظنون باقی‌مانده است.
ثبت کنید کدام نشانی پاسخ داد و کدام مقصد هدایت‌شده شکست خورد. همان جمله گزارش را قابل‌اقدام می‌کند، به‌جای ادعای اینکه سرور دسترسی‌ناپذیر است.