डुअल-स्ट्याक VPN: ठेगाना परिवार क्लाइन्टले छान्छ, तपाईंले होइन

टनेल चलिरहेको छ, IPv4 साइटहरू लोड हुँदै छन्, र एउटा होस्टनाम समय सकिँदै छ। तुरुन्तै निष्कर्ष आउँछ कि VPN बिग्रेको छ वा प्रमाणहरू गलत छन्, र सामान्यतया दुवै साँचो हुँदैन। नामले IPv4 र IPv6 दुवै ठेगाना फर्कायो, एपले एउटा छान्यो, र ती उम्मेदवारमध्ये एउटाले मात्र काम गर्ने मार्ग पायो। छनोटको निर्णय क्लाइन्टले गर्‍यो; टनेलले उसले छानेको कुरा समेटेन मात्र।

छनोट कभरेजको वाचा होइन

RFC 6724 मा वर्णन गरिएको पूर्वनिर्धारित ठेगाना छनोटले धेरै उपलब्ध हुँदा होस्टले कुन स्रोत-गन्तव्य जोडीलाई प्राथमिकता दिन्छ भनी निर्धारण गर्छ। Happy Eyeballs ले त्यसमाथि जडान रणनीति थप्छ: दुवै परिवारमा प्रयास सुरु गर्छ र पहिले जवाफ दिने राख्छ, ताकि प्रयोगकर्ताले बिग्रेको परिवारको टाइमआउट कुर्नु नपरोस्।

दुवैमध्ये कुनै पनि संयन्त्रले मार्ग बनाउँदैन। तपाईंको टनेलले मात्र IPv4 बोक्छ भने, AAAA उम्मेदवार अझै पनि क्लाइन्टले प्रयास गर्न सक्ने वैध गन्तव्य हो, र असफलता त्रुटिको रूपमा होइन, ढिलो लोडिङको रूपमा देखिन्छ, किनकि ब्राउजर पछाडि हट्यो। प्रयोगकर्ताले बिग्रेको साइट होइन, ढिलो साइट रिपोर्ट गर्छ, र सहयोग टिकटले त्यो अस्पष्टता उत्तराधिकारमा पाउँछ। स्थिर परिवारसँग यो पुन: उत्पादन गर्नुहोस्, प्रतिवेदन विशिष्ट हुन्छ।

त्यही पछाडि हट्ने कारणले लक्षण एपहरूमा असंगत छ। ब्राउजरले ढिलाइ लुकाउँछ; स्थिर परिवार भएको कमाण्ड-लाइन क्लाइन्टले वास्तविक असफलता तुरुन्तै देखाउँछ।

अनुरोधले वास्तवमा कुन परिवार प्रयोग गर्‍यो पत्ता लगाउनुहोस्

टनेलबाट होइन, नामबाट सुरु गर्नुहोस्। दुवै रेकर्ड प्रकार सोध्नुहोस् र के फर्कियो लेख्नुहोस्:

dig +short A example.com
dig +short AAAA example.com
curl -4 -sS -o /dev/null -w '%{http_code}\n' https://example.com
curl -6 -sS -o /dev/null -w '%{http_code}\n' https://example.com

v4 अनुरोध सफल भई v6 अनुरोध असफल भयो भने, तपाईंले समस्या डिबग गर्न सकिने रूपमा पुन: उत्पादन गर्नुभएको छ। शेलबाट दुवै सफल भई ब्राउजर अझै असफल भयो भने, टनेल छुनु अघि एपको आफ्नै रिजोल्भर वा क्यास गरिएको उत्तर हेर्नुहोस्।

परिवार र गन्तव्य आफ्नो नोटमा राख्नुहोस्। VPN मा साइट लोड हुँदैन भन्ने टिकट कोहीले पनि जाँच्न सक्दैन, तर AAAA असफल हुन्छ र A काम गर्छ भन्ने टिकटले विशेष मार्ग देखाउँछ।

त्यो परिवारको मार्ग जाँच्नुहोस्

असफल हुने परिवारका लागि कर्नेललाई कुन मार्ग प्रयोग गर्छ भनी सोध्नुहोस् र टनेलका कन्फिगर गरिएका ठेगानासँग तुलना गर्नुहोस्। Linux मा, ip -6 route get गन्तव्यका लागि छानिने इन्टरफेस र स्रोत देखाउँछ।

त्यसपछि टनेल आफै जाँच्नुहोस्। WireGuard पियरहरूले अनुमत IP सूची बोक्छन्, र 0.0.0.0/0 को प्रविष्टिले IPv6 बारे केही भन्दैन। पियरको सूचीमा IPv6 प्रिफिक्स छैन भने, क्लाइन्टसँग AAAA ट्राफिक टनेलमा पठाउने कुनै कारण छैन, र प्याकेट होस्टले अन्यथा गर्ने बाटोबाट बाहिरिन्छ।

फायरवाल नियम र NAT नीति प्रत्येक परिवारका लागि उही जाँचको योग्य छन्। IPv4 का लागि लेखिएको नियमले कुनै पनि प्लेटफर्ममा IPv6 समेट्दैन, र एउटा परिवार चल्ने अर्को नचल्ने सबैभन्दा सामान्य कारण यही हो।

स्क्रिनसट सजिलो बनाउन IPv6 बन्द नगर्नुहोस्

प्रणालीभर IPv6 बन्द गर्दा लक्षण हराउँछ र तपाईं निदानविना रहनुहुन्छ। यसले IPv6 मात्र भएको कुनै पनि गन्तव्य पनि तोड्छ, र अर्को एपका लागि त्यही बग लुकाउँछ। कुनै मेसिनले साँच्चै IPv6 प्रयोग गर्नु हुँदैन भने, त्यो मालिक र परीक्षणसहितको जानाजानी नीति हो। घटनाको समयमा यसलाई बन्द गर्नु दुवै होइन।

परिवारसँग क्लाइन्टले के गर्नुपर्छ निर्णय गर्नुहोस् र त्यो स्पष्ट रूपमा कन्फिगर गर्नुहोस्: यसलाई टनेलबाट लैजानुहोस्, वा समर्थित तरिकाले ब्लक गर्नुहोस् ताकि छनोटले कहिल्यै पुग्न नसकिने उम्मेदवार नदेओस्। दुवै वैध डिजाइन हुन्। विश्वव्यापी बन्द दुवै होइन, किनकि त्यो डिजाइन नै होइन।

टिकटमा के लेख्ने

चार कुरा लेख्नुहोस्: होस्टनाम, असफल परिवार, कर्नेलले छानेको मार्ग, र परिवार-विशिष्ट अनुरोधको नतिजा। यो सेट अरू कसैलाई असफलता पुन: उत्पादन गर्न पर्याप्त छ, तपाईंले कुन दुई मार्ग भन्न खोज्नुभएको थियो अनुमान नगरी।

RFC 6724 ठेगाना छनोट नियमहरू क्लाइन्टले किन त्यो उम्मेदवारलाई प्राथमिकता दियो व्याख्या गर्छन्, र RFC 8305 ले ढिलाइ लुकाएको दौड व्यवहार व्याख्या गर्छ। तीमध्ये कुनैले पनि तपाईंका लागि प्याकेट रुट गर्दैन, र टनेलले त्यही भाग गर्नुपर्छ।