VPN डिस्कनेक्ट झाल्यानंतर Mac ची IPv6 स्थिती कशी तपासावी

टनेल पडल्यानंतर IPv4 ने साइटवर पोहोचलात तरी IPv6 बद्दल तुम्ही काहीही सिद्ध केलेले नाही. macOS दोन्ही कुटुंबे प्रत्येक नेटवर्क सेवेसाठी स्वतंत्रपणे कॉन्फिगर करते, आणि VPN क्लायंट एकाला दुसऱ्याला न स्पर्श करता बदलू शकतो. तीन स्तर क्रमाने पाहा: पत्ता कॉन्फिगरेशन, मार्ग निवड, आणि नंतर डिस्कनेक्ट असताना क्लायंट स्थापित करतो ते कोणतेही धोरण. यादरम्यान प्रवेश नेटवर्क बदलू देऊ नका, अन्यथा तुम्ही दोन वेगळ्या समस्यांची तुलना कराल.

खरोखर तुटलेल्या कुटुंबापासून सुरुवात करा

IPv4 ने लोड होणारे पान तुम्हाला सांगते की भौतिक नेटवर्क जिवंत आहे. सेवेकडे जागतिक IPv6 पत्ता आहे का, प्रीफिक्स अजूनही जाहीर होत आहे का, किंवा काहीतरी कुटुंब फिल्टर करत आहे का, हे ते सांगत नाही. साधन निवडण्यापूर्वी काय अयशस्वी झाले ते निश्चित करा, कारण अगम्य पत्त्यावर रिझोल्व्ह होणारे नाव अजिबात न रिझोल्व्ह होणाऱ्या नावासारखेच दिसते. कोणत्या स्तराने चुकीचे उत्तर दिले ते विचारा आणि उत्तर लिहून ठेवा. त्याशिवाय पुढील प्रत्येक पायरी प्रक्रियेच्या वेशातील अंदाज आहे.

संपूर्ण तुलनेत तेच Wi-Fi नेटवर्क आणि तेच प्रवेश बिंदू ठेवा. काल IPv6 देणारे कॅफे नेटवर्क आता तुम्ही ज्या नेटवर्कवर आहात त्याबद्दल काहीही सांगत नाही.

मार्गापूर्वी पत्ता वाचा

सिस्टम सेटिंग्जमध्ये, सक्रिय सेवेचे TCP/IP पॅनेल IPv6 स्वयंचलित, हस्तचालित किंवा फक्त लिंक-स्थानिक आहे का हे दाखवते. तुमच्या अपेक्षेशी त्याची तुलना करा, संस्थेने जाणीवपूर्वक हस्तचालित कॉन्फिगरेशन निवडले असू शकते हे लक्षात ठेवा. नंतर ifconfig चालवा आणि संबंधित इंटरफेस वाचा. फक्त fe80:: पत्ता म्हणजे इंटरफेस त्याच्या शेजाऱ्यांशी बोलू शकतो आणि त्यापेक्षा जास्त काही नाही, म्हणून लिंक-स्थानिक उपस्थिती वापरण्यायोग्य मार्गाचा पुरावा नाही.

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

अयशस्वी गंतव्यासाठी मार्ग सारणी वाचा

कर्नेलला अयशस्वी गंतव्याबद्दल विचारा, डीफॉल्ट मार्गाबद्दल नाही. route -n get 2001:db8::25 त्या पत्त्यासाठी निवडलेला इंटरफेस आणि गेटवे छापते, आणि netstat -rn -f inet6 तुलनेसाठी संपूर्ण सारणी दाखवते. डीफॉल्ट मार्ग सांगतो की डीफॉल्ट अस्तित्वात आहे; हे गंतव्य तो वापरते हे सांगत नाही.

DNS स्वतंत्र कप्प्यात ठेवा. IPv4 ने पोहोचण्यायोग्य रिझोल्व्हर अजूनही AAAA रेकॉर्ड परत करू शकतो, म्हणून लुकअप अयशस्वीता आणि राउटिंग अयशस्वीता ब्राउझरमध्ये एकच लक्षण निर्माण करतात.

क्लायंटचे ब्लॉक धोरण उरलेल्या नियमापासून वेगळे करा

काही क्लायंट डिस्कनेक्ट असताना रहदारी ब्लॉक करण्यासाठी बनवलेले आहेत, दुसरे पत्ता कुटुंबासह, आणि हे वर्तन दोष नसून वैशिष्ट्य आहे.

ब्लॉकला हानी मानण्यापूर्वी तुमचा क्लायंट कोणते वर्तन दस्तऐवजीकरण करतो ते शोधा. scutil --dns प्रत्येक सेवेसाठी लागू रिझोल्व्हर दाखवते, आणि क्लायंटने स्थापित केलेला रिझोल्व्हर किंवा मर्यादित DNS सेटिंग तिथेच दिसते. नंतर पॅकेट फिल्टर नियम स्थापित करून सोडले गेले का ते तपासा. अपेक्षित ब्लॉक आणि उरलेला नियम विरुद्ध प्रतिक्रिया मागतात, आणि फक्त मालकाची कागदपत्रे त्यांना वेगळे करतात.

पुरावे गोळा करा, मग एक गोष्ट बदला

एका कनेक्ट-डिस्कनेक्ट चक्राच्या दोन्ही बाजूंना क्लायंट आवृत्ती, macOS आवृत्ती, नेटवर्क सेवा, इच्छित डिस्कनेक्ट धोरण आणि पत्ता व मार्गाचे आउटपुट नोंदवा. तीच नोंद तक्रारीचे कोणीही तपासू शकेल अशा जीवनचक्र समस्येत रूपांतर करते. मग एकच बदल करा आणि पुन्हा मोजा.

रीसेटला प्रतिकार करा. व्हर्च्युअल इंटरफेस हटवणे, मार्ग सारणी रिकामी करणे आणि संपूर्ण मशीनवर IPv6 बंद करणे—हे सर्व तुम्हाला कॅप्चर करायची असलेली स्थिती नष्ट करतात, आणि ते असंबंधित कॉन्फिगरेशनही सोबत नेऊ शकतात. क्लायंटकडे समर्थित विराम, दुरुस्ती किंवा अनइन्स्टॉल प्रवाह असल्यास तो वापरा, आणि नेटवर्क व्यवस्थापित असलेल्या ठिकाणी प्रशासकाची प्रक्रिया अनुसरा. आधीच रीसेट झालेले मशीन मालकाला काम करण्यासाठी काहीही देत नाही, आणि सामान्यतः पुढील कनेक्शनवर दोष पुन्हा निर्माण करते.