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 ची स्थिती ते पडताळू शकत नाही। रेकॉर्डचे आयुष्य संपल्यानंतरही जुने उत्तर स्मृतीत ठेवणाऱ्या रिझॉल्व्हरकडे लक्ष ठेवा। पूर्वीच्या पत्त्याकडे अजूनही निर्देश करणारे नाव बंद पडलेल्या सर्व्हरसारखेच दिसते।
प्रोफाइल कोणते नाव वापरते आणि सीमेच्या दोन्ही बाजूंना ते कोणत्या पत्त्यावर रिझॉल्व्ह होते ते लिहून ठेवा। कुणीही नोंद न केलेल्या राउटर वैशिष्ट्यावर अवलंबून असलेले प्रोफाइल म्हणजे पुढील फर्मवेअर अपडेटची वाट पाहणारा सपोर्ट कॉल। तीच नोंद पुढच्या व्यक्तीला सांगते की अंतर्गत अपयश ज्ञात हेअरपिन प्रकरण आहे की नवीन काही।