WireGuard मोबाइल डेटामा चल्छ, तर त्यही Wi-Fi मा चल्दैन
LAN भित्रबाट राउटरको सार्वजनिक ठेगानामा जाने अनुरोध मोबाइल डेटाबाट आउने अनुरोधभन्दा फरक बाटो लिन्छ। पहिले बाहिरबाट परीक्षण गर्नुहोस्, त्यसपछि स्थानीय बाटो रोज्नुहोस्।
मोबाइल डेटामा टनेल माथि आउँछ, तर घरमा त्यही प्रोफाइल, त्यही पियर कुञ्जी र बीचमा कुनै कन्फिगरेसन परिवर्तन नभई त्यो जोडिँदै छ भन्ने अवस्थामा बसिरहन्छ। फरक यात्रामा छ: LAN भित्रबाट राउटरको सार्वजनिक ठेगानामा जाने अनुरोध इन्टरनेटबाट आउने अनुरोधको त्यही यात्रा होइन। अधिकांश घरायसी गेटवेले फर्कने बाटो लागू गर्दैनन्, वा केही प्रोटोकलका लागि मात्र लागू गर्छन्। यसले कुञ्जीबारे केही नबदलिए पनि लक्षण भाँचिएको कुञ्जीजस्तो देखिन्छ। कुञ्जी, पोर्ट फर्वार्ड वा क्लाइन्ट प्रोफाइल छुनुअघि कुन बाटो असफल भयो निश्चित गर्नुहोस्।
एउटै ठेगाना, दुई फरक बाटो
बाहिरबाट एउटा प्याकेट राउटरको सार्वजनिक ठेगानामा पुग्छ र पोर्ट-फर्वार्ड नियमले त्यसलाई आन्तरिक होस्टको WireGuard श्रोतालाई सुम्पन्छ। भित्रबाट क्लाइन्टले त्यही सार्वजनिक ठेगाना डायल गर्छ, त्यसैले प्याकेट क्लाइन्टबाट निस्कन्छ, राउटरमा पुग्छ र फेरि LAN तर्फ फर्काउनुपर्छ। त्यही फर्कने मोडमा दुई बाटो छुट्टिन्छन्, किनकि राउटरले एउटै इन्टरफेसबाट बाहिर निस्केर फेरि त्यही इन्टरफेसमा प्रवेश गर्ने फ्लो अनुवाद गर्नुपर्छ। धेरै कार्यान्वयनले अनुवाद गर्नुको सट्टा त्यो फ्लो फ्याँकिदिन्छन्, र त्यसपछि क्लाइन्ट कहिल्यै नपठाइएको ह्यान्डसेकको प्रतीक्षा गर्छ।
यो व्यवहारलाई सामान्यतया NAT लूपब्याक वा हेयरपिनिङ भनिन्छ, र त्यो WireGuard को होइन, राउटरको गुण हो; RFC 4787 ले गेटवेले समर्थन गर्न सक्ने वा नसक्ने अनुवादका अवस्थाहरू वर्णन गर्छ। WireGuard आफैँ बाटोबारे कुनै मत राख्दैन, किनकि यसले आफ्नो इन्टरफेसमा पुग्ने प्याकेट मात्र देख्छ। राउटरले फ्लो फ्याँक्दा डेमनले केही पाउँदैन, क्लाइन्टले ह्यान्डसेक टाइमआउट रिपोर्ट गर्छ र सर्भर लग खाली रहन्छ। त्यसैले खाली लग प्याकेट कहाँ रोकियो भन्ने सङ्केत हो, सर्भर बन्द छ भन्ने प्रमाण होइन। पुनः स्थापना गर्दा केही नबदलिनुको कारण पनि यही हो।
उल्टो पनि महत्त्वपूर्ण छ: LAN ठेगानाबाट ह्यान्डसेक प्रयास देखाउने सर्भर लगले प्याकेट आएको र बाटो ठीक छ भनी प्रमाणित गर्छ, जसले जाँचलाई कुञ्जी र अनुमत ठेगानातर्फ सार्छ। लगलाई तपाईंले देख्न चाहेको कुराका लागि होइन, यसले के प्रमाणित गर्छ त्यसका लागि पढ्नुहोस्।
केही बदल्नुअघि त्यो अवस्था पुनः उत्पादन गर्नुहोस्
एउटै यन्त्र र एउटै प्रोफाइलसँग अधिकृत बाह्य नेटवर्कबाट परीक्षण गर्नुहोस्, त्यसपछि केही नबदली LAN भित्र त्यही परीक्षण दोहोर्याउनुहोस्। बाहिर पूरा भएको ह्यान्डसेक र भित्र यन्त्र नछोड्ने क्लाइन्टले अनुमानको सट्टा त्यो अवस्था पुनः उत्पादन गर्छन्। दुवै प्रयासले एउटै प्रोफाइल प्रयोग गर्नुपर्छ, नत्र तुलनाले केही प्रमाणित गर्दैन।
त्यसपछि यो यन्त्रका लागि इन्डपोइन्ट नाम कुन ठेगानामा रिजोल्भ हुन्छ हेर्नुहोस्। यी तीन कमान्डले क्लाइन्टले वास्तवमा कुन ठेगाना डायल गर्यो पनि देखाउँछन्:
wg show wg0 endpoints
dig +short vpn.example.net A
resolvectl query vpn.example.netपहिलो कमान्डले इन्टरफेसले अहिले कुन इन्डपोइन्ट प्रयोग गरिरहेको छ भन्ने बताउँछ, र बाँकी दुईले यो मेसिनमा नाम कुन ठेगानामा रिजोल्भ हुन्छ देखाउँछन्। सर्भरकै नेटवर्कमा बसेर सार्वजनिक ठेगाना डायल गर्ने क्लाइन्टले हेयरपिन बाटो प्रयोग गरिरहेको हुन्छ। LAN ठेगाना डायल गर्ने क्लाइन्टले त्यसो गर्दैन, र त्यहाँको असफलता अर्कै जाँचको विषय हो। यही भिन्नताले अर्को खण्ड यहाँ लागू हुन्छ वा हुँदैन भन्ने निर्धारण गर्छ।
नजिकको सर्भरसम्म पुग्ने समर्थित तरिकाहरू
सबैभन्दा सफा व्यवस्था स्प्लिट-होराइजन उत्तर हो: सार्वजनिक नाम इन्टरनेटका लागि सार्वजनिक ठेगानामा र भित्रका क्लाइन्टका लागि सर्भरको LAN ठेगानामा रिजोल्भ हुन्छ। प्रोफाइलले एउटै इन्डपोइन्ट नाम राख्छ र रिजोल्भरले बाटो रोज्छ। यसका लागि आन्तरिक DNS उत्तरमाथिको नियन्त्रण चाहिन्छ, जुन घरायसी राउटरले सामान्यतया दिन्छ र संस्थाले जानाजानी मिलाउन सक्छ। त्यो नियन्त्रण नभए बाँकी विकल्प राउटरको कुनै सुविधा वा दोस्रो प्रोफाइल हुन्।
राउटरको सुविधा परावर्तन हो: गेटवेले भित्रबाट-बाहिर जाने फ्लो अनुवाद गरी फेरि भित्र पठाउँछ। जहाँ यो चल्छ त्यहाँ क्लाइन्टमा परिवर्तन चाहिँदैन, र जहाँ चल्दैन त्यहाँ कुनै क्लाइन्ट सेटिङले उद्धार गर्दैन। राउटरको सुविधा-सूची पढ्नुको सट्टा आन्तरिक प्रयासका बेला सर्भर लग हेरेर यसको परीक्षण गर्नुहोस्।
प्रोफाइललाई निजी ठेगानामा बदल्नु निदान हो, डिजाइन होइन। यसले सर्भर LAN मा उत्तर दिन्छ भनी प्रमाणित गर्छ, र ल्यापटप घरबाट बाहिर निस्कने बित्तिकै त्यही प्रोफाइल भाँचिन्छ।
| Approach | What it depends on | Where it fails |
|---|---|---|
| Split-horizon name | Control of the internal DNS answer | Clients that resolve through a server outside the zone |
| Router reflection | Gateway support for hairpin translation | Routers that drop the flow silently |
| Private address in the profile | Nothing beyond the LAN | Every network except the one at home |
घरबाट टाढा पनि प्रोफाइल प्रयोगयोग्य राख्नुहोस्
जुनसुकै बाटो रोज्नुहोस्, पहिचान जाँचमा हात नलगाउनुहोस्। इन्डपोइन्ट ठेगाना पियरको पहिचान होइन, र ठेगाना सर्दैमा संयोगले उत्तर दिने असम्बन्धित सार्वजनिक कुञ्जी स्वीकार्ने कुनै जायज आधार हुँदैन। WireGuard ले कुञ्जीबाटै प्रमाणित गर्छ, त्यसैले गलत होस्टले ह्यान्डसेक असफल गराउँछ, अप्रत्याशित कुरामा पहुँच दिँदैन।
सार्वजनिक ठेगाना सर्ने हो भने नामलाई उपयोगी राख्ने डाइनामिक DNS हो, र परिवर्तन कति छिटो लागू हुन्छ क्लाइन्टको रिफ्रेस व्यवहारले निर्धारण गर्छ। ठेगाना सरेपछि यो बाहिरबाट परीक्षण गर्नुहोस्, किनकि LAN को अवस्थाले यसलाई प्रमाणित गर्न सक्दैन। रेकर्डको आयु सकिएपछि पनि पुरानो उत्तर क्यासमा राख्ने रिजोल्भरप्रति सतर्क रहनुहोस्। अघिल्लो ठेगानातिरै देखाइरहेको नाम ठ्याक्कै बन्द भएको सर्भरजस्तै देखिन्छ।
प्रोफाइलले कुन नाम प्रयोग गर्छ र सीमाका दुवैतिर त्यो कुन ठेगानामा रिजोल्भ हुन्छ लेखिराख्नुहोस्। कसैले अभिलेख नगरेको राउटर सुविधामा निर्भर प्रोफाइल अर्को फर्मवेयर अपडेटको प्रतीक्षामा रहेको सहयोग कल हो। त्यही टिप्पणीले अर्को व्यक्तिलाई आन्तरिक असफलता चिनिएको हेयरपिन अवस्था हो वा नयाँ कुरा भनी बताउँछ।