VPN टनेलमध्ये traceroute एकाच दिशेने का मरतो

traceroute चे जे आउटपुट एका दिशेने पूर्ण होते आणि दुसरीकडे ताऱ्यांच्या रांगा छापते, ते असममित फॉरवर्डिंगसारखे दिसते, आणि सहसा तसे नसते। प्रत्येक दर्शविलेल्या हॉपसाठी प्रोब पोहोचणे, राउटरने उत्तर देण्याचा निर्णय घेणे आणि उत्तर परत येऊन प्रोबशी जुळणे आवश्यक आहे। यापैकी कोणतीही कडी तोडली तर रांग तारा होते, तर टनेल माहिती वाहून नेणे सुरू ठेवते।

ट्रेस वाहतुकीबद्दलचा पुरावा होण्याआधी निदानाबद्दलचा पुरावा आहे। विचारण्यासारखा प्रश्न हा आहे की तीनपैकी कोणती कडी अयशस्वी झाली, आणि उत्तर आउटपुटच्या आकारातून नाही तर पॅकेटमधून येते।

तारा म्हणजे गहाळ उत्तर, गहाळ हॉप नाही

traceroute प्रत्येक फेरीत TTL एका राउटरने दूर संपणाऱ्या प्रोब पाठवून बाहेरच्या दिशेने पुढे जाते। कालबाह्य झालेल्या प्रोबला टाकून देणाऱ्या राउटरने स्वतःचे नाव सांगणारा ICMP Time Exceeded संदेश परत द्यायला हवा, आणि साधन ते नाव छापते। साधन प्रत्यक्षात त्या संदेशाची वेळेच्या मर्यादेत येण्याची वाट पाहते। राउटरने दुसऱ्या स्रोत पत्त्यावरून उत्तर दिले, दोष निर्माणाची वारंवारता मर्यादित केली, किंवा प्रोबला शब्द न बोलता टाकून दिले, तर ती फेरी छापण्यासारखे काहीही देत नाही।

यापैकी कोणताही निकाल पुढचा मार्ग तुटलेला आहे असे म्हणत नाही। तारा हा उत्तर न मिळालेल्या टपालाचा अहवाल आहे, रिकाम्या रस्त्याचा नाही।

प्रोब पद्धत ठरवते की तुम्हाला कोणता फिल्टर भेटेल

Linux वर डीफॉल्ट पद्धत सहसा मोठ्या क्रमांकाचा UDP गंतव्य पोर्ट असते, Windows चा tracert 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 बद्दलचा निर्णय नाही तर निदानाबद्दलचा खुला प्रश्न माना।