لماذا تجعل المسارات متساوية الكلفة أعطال VPN صعبة الملاحظة
عندما تتقاسم عدة أنفاق الكلفة نفسها، يمكن لكل تدفق أن يسلك نفقاً مختلفاً. نجاح ping لا يقول شيئاً عن المسار الذي يستخدمه تطبيقك فعلاً.
يروي مستخدم أن التطبيق الداخلي يعمل من جهاز ويفشل من جهاز آخر، بينما ينجح ping تشغّله من البوابة في الحالتين. مع وجود عدة أنفاق متساوية الكلفة، هذا ليس تناقضاً. يُوضع كل تدفق على قفزته التالية الخاصة، لذا فقد يستخدم فحصك وجلسة المستخدم مسارين مختلفين ببساطة. يستعيد العرض التالي هذا الاختيار قبل تغيير أي شيء.
ping واحد، مسارات محتملة عدة
عندما يكون للمسار أكثر من قفزة تالية واحدة بالكلفة نفسها، على الموجّه أن يختار واحدة لكل حزمة. معظم التطبيقات تُجزّئ حقولاً من الحزمة، عادةً عنوانَي المصدر والوجهة مع البروتوكول والمنافذ، كي تبقى الاستجابات على المسار نفسه. التطبيقات المختلفة، أو حتى الاتصالات المختلفة من تطبيق واحد، تنتج تجزئات مختلفة.
لهذا السبب لا يثبت تشخيص من البوابة إلا القليل. لفحص البوابة عنواناه ومنافذه، وبالتالي تجزئته الخاصة. قد يهبط على النفق السليم بينما يظل المستخدم يهبط على النفق المعطوب.
كيف تختار المنصة القفزة التالية
أعد إنتاج الاختيار بدل تخمينه. اسأل النواة عن المسار الذي ستستخدمه للمصدر والوجهة نفسيهما اللذين تستخدمهما الجلسة الفاشلة. يشمل ذلك البحث حقولاً يتجاهلها بحث عادي عن الوجهة. نفّذه أيضاً من عميل يعمل، وقارن الجوابين:
ip route get 10.20.5.7 from 10.20.0.14تقبل إصدارات iproute2 الأحدث أيضاً البروتوكول ومنفذ الوجهة، وهذا مهم عندما تتضمن التجزئة هذين الحقلين. قارن ذلك الناتج بالبحث نفسه من عميل يعمل، وستكون الفروق هي الدليل الذي كان ينقصك.
| Observation | Likely cause | First check |
|---|---|---|
| Ping works, application fails | A different flow hash selects another tunnel | Per-flow lookup from the client's address |
| Some users fail, others do not | One tunnel lacks a prefix or selector | Compare both tunnels' installed routes |
| Fails only at larger sizes | Tunnels have different effective MTU | Probe the same size over each path |
| Fails after a reconnect | Stateful asymmetry between paths | Session state on both gateways |
تتبّع التدفق الفاشل، لا جدول المسارات
يسرد جدول المسارات النفقين ويبدو صحيحاً بحكم التعريف. السؤال هو ما يفعله كل نفق بالحزمة بعد اختياره. تحقق من أن كليهما يحمل البادئات المحمية نفسها، وإذن التمرير نفسه، ومسار عودة يصل إلى العميل نفسه.
انتبه إلى الأجهزة ذات الحالة في المنتصف. إذا خرج طلب عبر نفق وعاد الرد عبر النفق الآخر، فإن جدار حماية أو NAT لم يرَ التدفق الأصلي قط سيسقطه. كلا النفقين يمرران البيانات بشكل صحيح، ومع ذلك تفشل الاتصال.
تحقق أيضاً من MTU لكل مسار. المسار ذو تغليف إضافي يقلّص الحجم القابل للاستخدام، ونقل ينجح على نفق يتعطّل على الآخر عند الحجم نفسه الذي ينكسر عنده الأصغر بالضبط.
قارن مساراً واحداً في كل مرة
حيث يسمح التصميم بالصيانة، أخرج نفقاً واحداً من الخدمة وأعد مهمة المستخدم. إذا اختفى العطل، فالمشكلة تنتمي إلى المسار الذي أزلته، والخطوة التالية هي مقارنة إعداداته بجاره بدل إعادة فحص جدول التوجيه.
قارن التطبيق الحقيقي، لا فحوص ping المتكررة. سجّل ما إذا كان العطل يتبع قفزة تالية معينة أو حجم حزمة أو انتقالاً بعد إعادة الاتصال، لأن تلك الأنماط الثلاثة تشير إلى إصلاحات مختلفة.
أخيراً، دوّن سبب اعتبار المسارات متكافئة وكيف يُفترض أن يزيل عطلٌ أحدها من الخدمة. التعددية آمنة فقط عندما تكون المسارات قابلة للتبادل فعلاً، وهذا تصريح تصميمي يستحق التحقق لا الافتراض.