لماذا يموت 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.