چرا traceroute در یک جهت از یک تونل VPN می‌میرد
مسیری که در یک جهت کامل می‌شود و در جهت دیگر ستاره چاپ می‌کند معمولاً یک مشکل تشخیصی است. روش‌های کاوش، مسیرهای بازگشت و یک درخواست واقعی را مقایسه کنید.
خروجی traceroute که در یک جهت کامل می‌شود و در جهت دیگر ردیف‌هایی از ستاره چاپ می‌کند شبیه ارسال نامتقارن به نظر می‌رسد و معمولاً این‌گونه نیست. هر گامی که نمایش داده می‌شود نیاز دارد که کاوشگر برسد، یک روتر تصمیم بگیرد پاسخ دهد و پاسخ بازگردد و با کاوشگر تطبیق داده شود. هر یک از این حلقه‌ها را بشکنید و ردیف به ستاره تبدیل می‌شود در حالی که تونل همچنان داده حمل می‌کند.
ردیابی پیش از آن‌که شاهدی بر انتقال باشد، شاهدی بر تشخیص است. پرسشی که ارزش پرسیدن دارد این است که کدام یک از سه حلقه شکست خورد، و پاسخ از بسته‌ها می‌آید نه از شکل خروجی.
ستاره یعنی پاسخ گم‌شده، نه گام گم‌شده
traceroute با فرستادن کاوشگرهایی که TTL آن‌ها در هر دور یک روتر دورتر منقضی می‌شود به بیرون پیش می‌رود. روتری که کاوشگر منقضی‌شده را دور می‌ریزد باید پیام ICMP Time Exceeded را با نام خودش برگرداند و ابزار آن نام را چاپ می‌کند. آنچه ابزار واقعاً منتظر آن است رسیدن همین پیام در یک مهلت زمانی است. اگر روتر از نشانی مبدأ دیگری پاسخ دهد، بسامد تولید خطا را محدود کند یا کاوشگر را بی هیچ سخنی بیندازد، دور چیزی برای چاپ تولید نمی‌کند.
هیچ‌یک از این نتایج نمی‌گوید مسیر رفت شکسته است. ستاره گزارشی درباره نامه بی‌پاسخ است، نه درباره جاده خالی.
روش کاوش تعیین می‌کند با کدام فیلتر روبه‌رو می‌شوید
روش پیش‌فرض در Linux معمولاً یک درگاه مقصد UDP با شماره بالا است، tracert در Windows پژواک ICMP می‌فرستد و می‌توان به Linux گفت به‌جای آن از ICMP یا TCP استفاده کند. هر یک از این‌ها برای یک دیواره آتش حالت‌دار یا یک گروه امنیتی ابری نوع متفاوتی از ترافیک به نظر می‌رسد. مقایسه یک رد UDP از یک سو با یک رد ICMP از سوی دیگر دو آزمایش متفاوت را مقایسه می‌کند. پیش از آن‌که نتایج را تفاوت بنامید، روش، خانواده نشانی، نشانی مبدأ و مهلت را ثابت کنید.
برای مقایسه‌ای منصفانه، رد را از میزبان‌هایی اجرا کنید که واقعاً ترافیک را حمل می‌کنند، نه از دروازه‌ای که به نمایندگی از آن‌ها ارسال می‌کند. رد تولیدشده توسط روتر از نشانی مبدأ و سیاست خروج خود روتر استفاده می‌کند که می‌تواند سخت‌گیرانه‌تر از هر چیزی باشد که یک کارخواه می‌بیند. فرمان دقیق را ثبت کنید تا نفر بعدی بتواند آن را تکرار کند.
مقدار مهلت نیمه دیگر آزمایش است و به‌آسانی از یادداشت‌ها جا می‌ماند. انتظار دو ثانیه‌ای در مسیری شلوغ ستاره گزارش می‌کند جایی که انتظار پنج ثانیه‌ای گام گزارش می‌کند. مقدار را در همه اجراها یکسان نگه دارید تا مقایسه درباره شبکه بماند.
مسیر بازگشت مسیری از خودش است
خطای ICMP یک بسته معمولی با مبدأ و مقصد خودش است و به مسیری بازگشتی به ردیاب نیاز دارد. اگر سیاست تونل پیشوندهای LAN را حمل کند اما نشانی روتری را که خطا را تولید کرده حمل نکند، پیام از مسیری خارج می‌شود که نمی‌تواند به شما برسد. فیلتر کردن پاسخ‌ها می‌تواند آن را بیندازد حتی وقتی مسیر وجود دارد، چون بسته از نشانی غیرمنتظره روی رابطی غیرمنتظره می‌رسد. این ناسازگاری در صفحه تشخیص است نه شکست برنامه.
گستردن هر انتخابگر تا وقتی رد کامل شود تصویر را زیباتر و سیاست را بدتر می‌کند. نشانی تشخیصی مشخص را تعمیر کنید، یا ستاره را بپذیرید و برنامه را به روشی دیگر بیازمایید.
تونل را با یک درخواست واقعی تأیید کنید
یک دست‌دادن TCP روی درگاه خود سرویس، ارسال، مسیریابی بازگشت و فیلتر کردن را در جهتی که اهمیت دارد می‌آزماید. فرمان‌های زیر در هر دو سر اجرا می‌شوند و مقایسه می‌کنند هر طرف چه چیزی می‌تواند باز کند. درگاه سرویس و نام رابط تونل را از پیکربندی خود جایگزین کنید.
traceroute -I -n -w 2 203.0.113.40
traceroute -T -p 443 -n -w 2 203.0.113.40
curl -sS -o /dev/null -w '%{http_code} %{time_total}\n' --max-time 5 http://203.0.113.40:8080/health
ss -tan state establishedنخست دو اجرای traceroute را بخوانید: اگر اجرای ICMP گام‌ها را نشان دهد و اجرای TCP نه، تفاوت در روش است نه در مسیر. سپس نتیجه curl را پاسخ در سطح برنامه بگیرید، چون تبادلی کامل با کد وضعیت معقول یعنی مسیرهای رفت و بازگشت هر دو برای ترافیک واقعی کار می‌کنند. فهرست سوکت نشان می‌دهد اتصال اصلاً برقرار شده است یا نه، چیزی که هیچ ردی نمی‌تواند به شما بگوید.
تونلی که یک نشست تعاملی را در هر دو جهت حمل می‌کند در حالی که یک traceroute ستاره چاپ می‌کند سالم است و فقط عکاسانه نیست. خروجی فرمان‌ها از هر طرف را به‌عنوان سند نگه دارید و گام‌های گم‌شده را پرسشی باز درباره تشخیص بدانید نه حکمی درباره VPN.