VPN च्या बाहेर जाणारा IPv6 रहदारी: गळणारा मार्ग शोधा

दोन चाचणी पाने जुळत नाहीत: एक टनेलमधून प्रदात्याचा पत्ता सांगते, दुसरे तुमचा घरचा प्रीफिक्स सांगते, आणि स्पष्ट निष्कर्ष असा की VPN गळत आहे. तो निष्कर्ष एक पायरी वगळतो, कारण दोन्ही अहवालांनी दोन वेगळे राउटिंग निर्णय वापरले आणि त्यापैकी फक्त एकाने टनेलमध्ये जायचे होते. तफावत सहसा खरी असते, आणि ती कव्हरेजची समस्या आहे, तुटलेले टनेल नाही. तीन प्रश्न ती ठरवतात: कोणता प्रवाह प्रत्यक्षात बाहेर गेला, कर्नेलने त्यासाठी कोणता मार्ग निवडला, आणि क्लायंटचा कोणता वर्तनाचा हेतू होता.

त्या क्रमाने काम करा. त्यांना क्रम न देता उत्तर दिल्यास क्लायंटमध्ये दोष आहे का याबद्दल लांबलचक चर्चा होते, जेव्हा खरे उत्तर असे आहे की IPv6 मार्ग कधीही स्थापित झाला नाही.

कोणता प्रवाह प्रत्यक्षात बाहेर गेला, आणि कोणत्या ॲडॉप्टरवर

वापरलेल्या कुटुंबाचे नाव देणाऱ्या चाचणीपासून सुरुवात करा, नंतर ॲप्लिकेशन, प्रवेश नेटवर्क, चालू प्रोफाइल आणि कनेक्शन IPv6 देते का ते लिहा. त्या चार तथ्यांमुळे दोन रन तुलनीय होतात, आणि चौथे लोक विसरतात: v6 प्रीफिक्स नसलेले नेटवर्क v6 गळू शकत नाही, आणि नंतर एक जोडणारे नेटवर्क उत्तर बदलते.

पान लोड करून त्याचा निकाल वाचण्याऐवजी प्रत्येक कुटुंबासाठी एक विनंती पाठवा. एकच पान v6 आणि v4 संसाधने मिसळू शकते, पार्श्वभूमी प्रक्रिया तुमच्यासमोरच्या टॅबपेक्षा वेगळी वागू शकते, आणि कॅशे केलेले उत्तर तुम्ही तपासू पाहत असलेल्या नेटवर्क बदलापेक्षा जास्त टिकू शकते. तुम्ही तपासत असलेले गंतव्य निश्चित करा आणि नोंदवा, जेणेकरून पुनरावृत्तीची रन तेच मोजेल.

कर्नेलने निवडलेला मार्ग वाचणे

राउटिंग टेबल ब्राउझर उत्तर देऊ शकत नाही अशा प्रश्नाचे उत्तर देते. एखादे विशिष्ट गंतव्य कुठे जाईल असे सिस्टमला विचारा, आणि दिसणाऱ्या डीफॉल्टसह धोरण नियमही समाविष्ट करा, कारण दोन्हीपैकी कोणतेही त्याला मागे टाकू शकते:

ip -6 route get 2606:4700:4700::1111
ip -6 rule show
ip -6 route show table all

अधिक विशिष्ट प्रीफिक्स हे सामान्य कारण आहे की एक गंतव्य टनेलबाहेर राहते तर बाकी सर्व आत राहते, आणि धोरण नियम कोणत्याही मार्गापेक्षा उच्च प्राधान्याने तेच करू शकतो. मेट्रिकही वाचा, कारण एकाच प्रीफिक्सच्या दोन नोंदी स्क्रीनवरील क्रमाने नाही तर मेट्रिकने ठरतात. Windows वर समतुल्य यादी Get-NetRoute -AddressFamily IPv6 आहे, निर्णयक्रमाशी जुळण्यासाठी मेट्रिकनुसार क्रमवारीत. टेबलमध्ये बरोबर दिसणारा नियमही कमी क्रमांकाच्या धोरण नियमाकडून हरू शकतो, म्हणूनच नियमांची यादी मार्गांच्या यादीसोबत एकाच श्वासात येते.

क्लायंटचे IPv6 धोरण कुठून येते

क्लायंट v6 टनेलमधून नेण्यासाठी बनवला जाऊ शकतो, ते नाकारण्यासाठी, किंवा नामनिर्देशित अपवादाला परवानगी देण्यासाठी, आणि त्या तीन हेतूंमुळे तीन वेगवेगळे बरोबर निकाल मिळतात. निरीक्षणाला गळती म्हणण्यापूर्वी प्रोफाइल आणि क्लायंटचे स्वतःचे दस्तऐवज वाचा, कारण ऑपरेटिंग सिस्टम अजूनही भौतिक लिंकवर शेजारी शोध पाठवत असताना v6 अडवणारा क्लायंट रचनेनुसारच वागत असतो.

टनेलमधून जाणूनबुजून वगळलेले ॲप्लिकेशन हे टनेलने कधीही न नेलेल्या कुटुंबापेक्षा वेगळे प्रकरण आहे. पहिले एका प्रोग्रामबद्दलचा निर्णय आहे, दुसरे कव्हरेजमधील तफावत आहे, आणि दुरुस्ती त्यानुसार वेगळी असते. कधीही नसावा अशा मार्गाचा शोध घेण्यापूर्वी क्लायंटच्या वगळलेल्या प्रोग्रामांची यादी वाचा.

अरुंद निरीक्षण, जेव्हा टेबल विसंगत असते

मार्गाचा शोध संदिग्ध असताना, होस्टवरील एक इंटरफेस निरीक्षण तो ठरवू शकते, पण ते प्रश्नाकडे लक्ष्यित असेल तरच. VPN च्या टोकापर्यंतची रहदारी रचनेनुसार भौतिक ॲडॉप्टरवरून जाईल; महत्त्वाचे हे आहे की पूर्णपणे दुसरीकडे पत्ता दिलेला ॲप्लिकेशन प्रवाह तिथेही दिसतो का. सर्व गोळा करण्याऐवजी तुम्ही तपासत असलेल्या गंतव्यावर कॅप्चर फिल्टर करा.

रुंद कॅप्चर एका प्रश्नाला आवश्यक असण्यापेक्षा कितीतरी जास्त वैयक्तिक रहदारी उघड करते. ते प्रश्नाचे उत्तर कमी स्पष्टपणेही देते, कारण तुम्हाला महत्त्वाचा असलेला प्रवाह असंबंधित जोडण्यांच्या प्रवाहात पुरलेला येतो. तपासलेल्या गंतव्यावर फिल्टर करा, काही पॅकेटनंतर थांबा आणि कॅप्चर हटवा.

तफावत बंद करण्याचे तीन मार्ग

कुटुंबाला टनेलमधून न्या, टनेल ते नेऊ शकत नसेल तेव्हा क्लायंटमध्ये अडवा, किंवा मालक आणि पुनरावलोकन तारखेसह जाणूनबुजून अपवाद नोंदवा. प्रत्येकाचे समर्थन करता येते, आणि समर्थन करता येणार नाही अशी एकच गोष्ट म्हणजे निवड गर्भित ठेवणे, कारण गर्भित निवड हीच खरी गळती आहे. टनेलला v6 बाहेर पडण्याचा मार्गच नसेल, तर क्लायंटमध्ये v6 नाकारणे प्रामाणिकही आहे आणि तपासण्यायोग्यही. महत्त्वाचे हे आहे की निवड पुढच्या व्यक्तीला सापडेल तिथे लिहिलेली असेल, सहा महिन्यांनंतर वर्तनातून अनुमान काढले जाणार नाही.

पुन्हा कनेक्ट झाल्यानंतर आणि नेटवर्कदरम्यान हलल्यानंतर तपासणीची पुनरावृत्ती करा, कारण मागील लिंकसाठी स्थापित मार्ग बदल टिकून राहू शकतो. नंतर गंतव्य, निवडलेला मार्ग, क्लायंट धोरण आणि चाचणीने वापरलेले कुटुंब नोंदवा, जेणेकरून पुढची व्यक्ती निर्णय पुन्हा काढण्याऐवजी वाचेल.RFC 7359 दुहेरी-स्टॅक गळतीची बग म्हणून नाही तर रचना समस्या म्हणून नोंद करते, आणि कार्यरत v4 टनेल सर्व काही व्यापते असे कोणी दावा करताच उद्धृत करावयाचा संदर्भ तोच आहे.