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