समान लागतका रुटहरूले 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 होइन, वास्तविक एप्लिकेसन तुलना गर्नुहोस्। खराबी कुनै निश्चित अर्को हप, प्याकेट आकार वा पुनः जोडिएपछिको परिवर्तनको पछि लाग्छ कि भनी अभिलेख गर्नुहोस्, किनकि यी तीन ढाँचाले फरक मर्मततर्फ संकेत गर्छन्।
अन्तमा, बाटोहरू किन समतुल्य मानिन्छन् र खराबीले कसरी एउटालाई सेवाबाट हटाउनुपर्छ भनी लेख्नुहोस्। बाटोहरू साँच्चै अदलबदल गर्न सकिने भएमा मात्र बहुबाटो सुरक्षित हुन्छ, र यो अनुमान गर्नुको सट्टा जाँच्न लायक डिजाइन-कथन हो।