समान खर्चाचे मार्ग 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 नाही, प्रत्यक्ष अनुप्रयोगाची तुलना करा. दोष एखाद्या विशिष्ट पुढील हॉपचा, पॅकेट आकाराचा किंवा पुन्हा जोडल्यानंतरच्या संक्रमणाचा मागोवा घेतो का ते नोंदवा, कारण हे तीन नमुने वेगवेगळ्या दुरुस्त्यांकडे निर्देश करतात.
शेवटी, मार्ग समतुल्य का मानले जातात आणि दोषाने त्यातील एक सेवेतून कसा काढावा हे लिहा. मार्ग खरोखर अदलाबदल करण्यायोग्य असतानाच मल्टीपाथ सुरक्षित असते, आणि हे गृहीत धरण्याऐवजी तपासण्यासारखे रचना-विधान आहे.