WireGuard पूर्ण टनेल: AllowedIPs 0.0.0.0/0 पर्याप्त छैन

पियरको AllowedIPs मा 0.0.0.0/0, ::/0 राख्नु त्यो कदम हो जो सबैलाई सम्झना हुन्छ, र यसले पियरलाई कुन ट्राफिक बोक्न अनुमति छ भन्ने मात्र तय गर्छ। यी प्रिफिक्सहरूले कुनै रुट बनाउँदैनन्, अर्कोतर्फ केही फरवार्ड गर्दैनन्, र हरेक एप्लिकेसनको रिजोल्भरलाई जहाँ थियो त्यहीँै छोडिदिन्छन्। पूर्ण टनेल साँच्चै पूर्ण हुन चार अलग कुरा एकैसाथ सत्य हुनुपर्छ, र तिनीहरूलाई तलको क्रममा जाँच्नु उत्तम हुन्छ, किनकि पछिको जाँचले अघिल्लो जाँचलाई बचाउन सक्दैन। तलको हरेक जाँच मेसिनबाट पढ्न सकिने तथ्य हो, लागू भएको होला भनेर आशा गर्ने सेटिङ होइन।

पियर प्रिफिक्सले के छान्छ, र के छान्दैन

AllowedIPs एकैसाथ छनोटकर्ता र अनुमति दिने हो। यसले स्थानीय पक्षलाई कुन गन्तव्यहरू यो पियरमा पठाउन सकिन्छ भन्ने बताउँछ, र प्राप्त गर्ने पक्षलाई यो पियरले कुन स्रोत ठेगानाहरू प्रस्तुत गर्न सक्छ भन्ने बताउँछ। त्यही नै पूरै काम हो। त्यो विवरणमा केहीले पनि होस्टमा रुट बनाउँदैन, टाढाको पक्षमा फरवार्डिङ सक्षम गर्दैन, वा नाम समाधानलाई छुँदैन।

त्यसैले कन्फिगरेसन पूर्ण देखिन सक्छ र विभाजित टनेलजस्तै व्यवहार गर्न सक्छ। प्रिफिक्सले पियरले सबै स्वीकार्छ भन्छ; होस्टको रुटिङ तालिकाले त्यहाँ वास्तवमा के पुग्छ भन्ने तय गर्छ, र गेटवेले केही बाहिर जान्छ कि जाँदैन भन्ने तय गर्छ। यी तीनमध्ये कुनै पनि निर्णय पियर खण्डमा बस्दैन।

क्लाइन्टलाई रुट गर्नु, पियर सूची मात्र होइन

जस्तै म्यानेजरहरू wg-quick ले होस्टको रुटिङ तालिका तपाईंको तर्फबाट प्रोग्राम गर्छन्, त्यसैले दुई समान कन्फिगरेसन फाइलहरू इन्टरफेस कसरी माथि आयो भन्ने आधारमा फरक व्यवहार गर्छन्। न्यूनतम प्रोफाइल एकै पटक पढ्न सकिने जति छोटो छ:

[Interface]
Address = 10.8.0.2/32
DNS = 10.8.0.1

[Peer]
AllowedIPs = 0.0.0.0/0, ::/0
Endpoint = vpn.example.net:51820

काम दुई विवरणले बोक्छ। Address फिल्ड क्लाइन्टले आफ्नो ठान्ने सबनेट होइन, एउटा मात्र होस्ट प्रिफिक्स हो, र म्यानेजरले नै पूर्वनिर्धारित AllowedIPs लाई वास्तविक पूर्वनिर्धारित रुटमा बदल्छ। उही फाइल ip link र wg setconf ले माथि ल्याउनुहोस् र कुनै पनि रुट देखिँदैन, जो बिग्रिएको टनेलजस्तो देखिन्छ तर वास्तवमा रुटिङ चरण छोडिएको स्वस्थ टनेल हो। wg-quick पुस्तिकाले रुटिङ र Table व्यवहारको दस्तावेजीकरण गर्छ, जो ती म्यानेजरहरूले थप्छन्।

फाइल होइन, नतिजा पढ्नुहोस्: ip route get 1.1.1.1 ले टनेल इन्टरफेसको नाम बताउनुपर्छ, र wg show ले चलिरहेको स्थानान्तरण काउन्टरसहितको हालैको ह्यान्डशेक रिपोर्ट गर्नुपर्छ। रुट बिनाको ह्यान्डशेक भनेको म्यानेजर कहिल्यै चलेन, र प्रोफाइल फेरि सम्पादन गर्दा त्यो सुधारिँदैन। इन्टरफेसलाई प्रयोगकर्ताले सुरु गर्ने तरिकाले नै सुरु गर्नुहोस्, नत्र परीक्षणले तैनाथीको सट्टा तपाईंको शेल नाप्छ।

इन्डपोइन्टलाई टनेल बाहिर राख्नु

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

इन्डपोइन्ट धेरै ठेगानामा, वा तपाईंले नबोक्ने परिवारमा समाधान हुने होस्टनेम हो भने, अपवाद नराम्ररी पुरानो हुन्छ र नियमित देखिने पुनःजडानपछि टनेल असफल हुन सक्छ। इन्डपोइन्टलाई तपाईंले नियन्त्रण गर्ने ठेगानामा पिन गर्नुहोस्, वा म्यानेजरले यसको पुनर्मूल्यांकन गर्छ भनी पुष्टि गर्नुहोस्, र हरेक नेटवर्क परिवर्तनपछि होस्ट रुट फेरि पढ्नुहोस्।

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

गेटवेमा फरवार्डिङ र फर्कने बाटो

गेटवेमा, तपाईंले बोक्ने परिवारका लागि फरवार्डिङ सक्षम गर्नुहोस्, अनुवाद गर्दा forward शृंखलालाई दुवै दिशामा अनुमति दिनुहोस्, र स्रोत-विशिष्ट खोजीले फर्कने बाटो पुष्टि गर्नुहोस्। यीमध्ये केही पनि सफल ह्यान्डशेकबाट आउँदैन, किनकि ह्यान्डशेकले दुई पियरले UDP आदानप्रदान गर्न सक्छन् भन्ने मात्र प्रमाणित गर्छ। डिक्याप्सुलेट भएको प्याकेटलाई त्यसपछि के हुन्छ भन्ने यसले केही भन्दैन।

sysctl net.ipv4.ip_forward net.ipv6.conf.all.forwarding
ip route get 1.1.1.1 from 10.8.0.2

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

DNS र असफलता अवस्था, अलग जाँचिएको

प्रोटोकल आफैले कुनै पनि एप्लिकेसनको रिजोल्भर कन्फिगर गर्दैन। wg-quick ले वितरणको रिजोल्भर एकीकरणमार्फत DNS लाइन लागू गर्छ, आफ्नै स्ट्याक भएका कन्टेनर र ब्राउजरहरूले यसलाई बेवास्ता गर्न सक्छन्, र त्यसैले टनेलले प्याकेट उत्तम रूपमा बोकिरहेको बेला पनि नाम असफल हुन सक्छ। ठेगानाको सट्टा होस्टनेमले परीक्षण गर्नुहोस्, र प्रोफाइलको सर्भरले जवाफ दियो भनी मान्नुको सट्टा कुन सर्भरले जवाफ दियो त्यो लेख्नुहोस्।

ठेगाना परिवारहरू अलग जवाफ भएको अलग परीक्षण हुन्। v4 पूर्वनिर्धारितले कुनै एप्लिकेसनको v6 जडानले के गर्छ भन्ने केही भन्दैन, र दोस्रो परिवार चुपचाप चुहाउने टनेल ठूलो स्वरले असफल हुने टनेलभन्दा नराम्रो हो। हरेक परिवारमा नाम सोध्नुहोस्, हरेक अनुरोधले प्रयोग गरेको इन्टरफेस पढ्नुहोस्, र अनुवाद काउन्टर अघि र पछि जाँच्नुहोस्, किनकि केहीसँग नमिल्ने नियम हराएको नियमजस्तै देखिन्छ।

अन्तमा, टनेल रोकिँदा तपाईंले चाहेको अवस्था परीक्षण गर्नुहोस्। पूर्ण टनेलले आफूले दाबी गरेको ट्राफिकका लागि बन्द भएर असफल हुनुपर्छ: इन्टरफेस तल झर्यो र एप्लिकेसनहरू भौतिक लिंकमा चुपचाप जारी रहे, भने डिजाइन थप चरण भएको विभाजित टनेल हो। इच्छित असफलता व्यवहार लेख्नुहोस्, त्यसलाई जानाजान जाँच्नुहोस्, र चार उत्तर लेखेर अन्त्य गर्नुहोस् — कुन म्यानेजरले इन्टरफेस माथि ल्याउँछ, कुन रुटले पूर्वनिर्धारित बोक्छ, गेटवेमा कसले फरवार्ड र अनुवाद गर्छ, र कुन रिजोल्भरले जवाफ दिन्छ।