समान लागत वाले रूट VPN की खराबियों को देखना कठिन क्यों बनाते हैं
जब कई टनल एक ही लागत साझा करते हैं, तो हर फ़्लो अलग चुन सकता है। सफल ping इस बात का कुछ नहीं बताता कि आपका एप्लिकेशन वास्तव में कौन-सा रास्ता इस्तेमाल करता है।
एक उपयोगकर्ता बताता है कि आंतरिक एप्लिकेशन एक मशीन से काम करता है और दूसरी से नहीं, जबकि गेटवे से चलाया गया ping दोनों ही स्थितियों में सफल रहता है। समान लागत वाली कई टनल होने पर यह विरोधाभास नहीं है। हर फ़्लो को उसके अपने अगले हॉप पर रखा जाता है, इसलिए आपकी जाँच और उपयोगकर्ता का सत्र बस अलग-अलग रास्ते इस्तेमाल कर सकते हैं। नीचे दिया गया विवरण कुछ भी बदलने से पहले उसी चुनाव को दोहराता है।
एक ping, कई संभावित रास्ते
जब किसी रूट में एक ही लागत पर एक से अधिक अगले हॉप हों, तो राउटर को हर पैकेट के लिए एक चुनना पड़ता है। ज़्यादातर कार्यान्वयन पैकेट के फ़ील्ड का हैश बनाते हैं, आम तौर पर स्रोत और गंतव्य पते के साथ प्रोटोकॉल और पोर्ट, ताकि जवाब उसी रास्ते पर रहें। अलग-अलग एप्लिकेशन, या एक ही एप्लिकेशन के अलग-अलग कनेक्शन भी अलग हैश बनाते हैं।
इसीलिए गेटवे से किया गया निदान इतना कम साबित करता है। गेटवे की अपनी जाँच के अपने पते और पोर्ट होते हैं, और इसलिए अपना हैश भी। वह स्वस्थ टनल पर पहुँच सकती है जबकि उपयोगकर्ता टूटी हुई पर पहुँचता रहता है।
प्लेटफ़ॉर्म अगला हॉप कैसे चुनता है
अनुमान लगाने के बजाय चुनाव को दोहराएँ। कर्नेल से पूछें कि विफल सत्र जैसे ही स्रोत और गंतव्य के लिए वह कौन-सा रूट इस्तेमाल करेगा। उस खोज में वे फ़ील्ड शामिल हैं जिन्हें साधारण गंतव्य-खोज अनदेखा करती है। इसे किसी काम करने वाले क्लाइंट से भी चलाएँ और दोनों जवाबों की तुलना करें:
ip route get 10.20.5.7 from 10.20.0.14iproute2 के नए संस्करण प्रोटोकॉल और गंतव्य पोर्ट भी स्वीकार करते हैं, जो तब मायने रखता है जब हैश में वे शामिल हों। उस आउटपुट की तुलना काम करने वाले क्लाइंट से की गई उसी खोज से करें, और अंतर ही वह सबूत है जो आपके पास नहीं था।
| 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 की नहीं। दर्ज करें कि खराबी किसी ख़ास अगले हॉप, पैकेट आकार या फिर से जुड़ने के बाद के बदलाव का पीछा करती है या नहीं, क्योंकि ये तीन पैटर्न अलग-अलग मरम्मतों की ओर इशारा करते हैं।
आख़िर में लिखें कि रास्तों को समतुल्य क्यों माना जाता है और खराबी को एक को सेवा से कैसे हटाना चाहिए। मल्टीपाथ तभी सुरक्षित है जब रास्ते वाकई बदले जा सकने योग्य हों, और यह एक डिज़ाइन-कथन है जिसे मान लेने के बजाय जाँचना चाहिए।