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