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