टनल बन जाती है, क्लाइंट हरा बिंदु दिखाता है, और ssh 192.168.1.20 फिर भी टाइमआउट होने तक लटकी रहती है। छोटा क्लाउड इंस्टेंस किराए पर लेकर उस पर WireGuard लगाने के बाद मुझे ठीक यही मिला: हैंडशेक ठीक, DNS ठीक, और मेरे डेस्क का NAS उतना ही अगम्य जैसे चाँद पर हो। टनल में कोई खराबी नहीं थी। endpoint ऐसे नेटवर्क में था जिसका मेरे घर तक कोई मार्ग नहीं था। endpoint की जगह तय करती है कि कौन से नेटवर्क पड़ोसी हैं, इसलिए इसे पहले उस संसाधन के अनुसार चुनें जिसे छूना है और होस्टिंग की तुलना बाद में करें।

टनल केवल उन नेटवर्क तक पहुँचती है जिन्हें endpoint रूट कर सकता है

VPN आपके क्लाइंट को endpoint के अपने रूटिंग डोमेन के भीतर पता देता है। जब क्लाइंट 192.168.1.20 पर पैकेट भेजता है, endpoint को जानना होता है कि वह कहाँ जाता है। क्लाउड VM की तालिका प्रदाता के VPC सबनेट जानती है; आपके LAN के बारे में उसने कभी नहीं सुना। जुड़ा होना और पहुँच में होना दो अलग तथ्य हैं, और घर बनाम क्लाउड की अधिकांश उलझन पहले को दूसरे का प्रमाण मान लेने से आती है।

एक कमांड इसे तय कर देता है। endpoint पर, ip route get 192.168.1.20 या तो LAN इंटरफ़ेस का नाम लेता है या डिफ़ॉल्ट मार्ग की ओर इशारा करता है। घर के बॉक्स में उत्तर LAN पक्ष है। क्लाउड इंस्टेंस में पैकेट इंटरनेट की ओर निकलकर मर जाता है। net.ipv4.ip_forward=1 चालू करना और MASQUERADE नियम जोड़ना इसे नहीं बदलता, क्योंकि तब तक आगे भेजने के लिए कुछ नहीं है जब तक घर की ओर से कोई क्लाउड में लिंक समाप्त न करे।

घर के मामले का दूसरा आधा हिस्सा है: वापसी मार्ग। टनल बॉक्स से LAN छोड़ने वाले पैकेट NAT होते हैं, या LAN को टनल सबनेट तक स्थिर मार्ग चाहिए। जब केवल एक दिशा काम करे, तो जाँचें sysctl net.ipv4.conf.all.rp_filter। सख्त रिवर्स-पाथ फ़िल्टरिंग उन उत्तरों को गिरा देती है जो मार्ग के अनुमान से अलग इंटरफ़ेस पर आते हैं, और लक्षण बिल्कुल फ़ायरवॉल नियम जैसा दिखता है।

कॉन्फ़िगरेशन छूने से पहले लक्षण पढ़ें

टनल बनती नहीं: कुंजियाँ, endpoint पता या अवरुद्ध UDP पोर्ट। टनल ऊपर पर LAN मेज़बान मृत: जगह और रूटिंग। टनल ऊपर पर ब्राउज़िंग मृत: फ़ॉरवर्डिंग, NAT या DNS। ये तीन परतें और तीन अलग जाँचें हैं, और पहले से सही कॉन्फ़िगरेशन दोबारा लिखना एक शाम बर्बाद करता है।

SymptomFirst suspectCheck
Handshake fails, no transferKeys, endpoint port, UDP blockedwg show, then the port from outside
Peer pings, LAN host times outNo route to the LANip route get on the endpoint
Tunnel up, name resolution failsDNS options in the peer configResolve a name from the client
Large transfers reset the connectionMTULower the tunnel MTU and retry

घर की आवक पहुँच अपनी अलग जाँच की हक़दार है, क्योंकि यह तय करती है कि घर पर होस्टिंग संभव है या नहीं। आपके राउटर द्वारा बताए गए WAN पते की तुलना बाहरी मेज़बान द्वारा दिखाए गए पते से करें। अगर वह 100.64.0.0/10 में पड़ता है, या दोनों मेल नहीं खाते, तो आप carrier-grade NAT के पीछे हैं और कोई पोर्ट फ़ॉरवर्डिंग कभी काम नहीं करेगी। असली विकल्प रिले, घर से बाहर डायल करने वाली क्लाउड लिंक, या endpoint हटाना है।

घर की होस्टिंग क्या देती है और क्या लेती है

घर ही एकमात्र जगह है जो डिफ़ॉल्ट रूप से LAN के भीतर है, और वहीं सर्वर रखने का पूरा कारण यही है। केवल स्थानीय खंड पर उत्तर देने वाले उपकरण, जैसे प्रिंटर और ग़ैर-स्थानीय सबनेट अस्वीकार करने वाले NAS प्रशासन पृष्ठ, बिना अतिरिक्त रूटिंग के काम करते हैं। मशीन, राउटर और अपलिंक भी आप स्वयं चलाते हैं।

लागतें भौतिक हैं। घर का अपलोड एक साथ सभी क्लाइंट के लिए सीमा है, इसलिए वीडियो कॉल और बैकअप एक ही पाइप के लिए होड़ करते हैं। बिजली, डिस्क घिसाव, पैच, DDNS चाहने वाला गतिशील पता, अंदर UDP फ़ॉरवर्ड करने वाला राउटर, और संभवतः डबल NAT — सब आप पर पड़ता है। लोग जिसे छोड़ देते हैं वह है रिकवरी: अगर आप बाहर होते हुए बॉक्स मर जाए, तो घर में आने का आपका एकमात्र रास्ता भी उसके साथ मर जाता है। समान कुंजियों वाला दूसरा उपकरण, या कम से कम भौतिक पहुँच की योजना रखें।

अगर घर पर बॉक्स के बिना LAN पहुँच चाहिए, तो दिखावा करने के बजाय लिंक बनाएँ। क्लाउड endpoint राउटर बन जाता है: घर की ओर से AllowedIPs = 192.168.1.0/24 के साथ क्लाउड peer पर टनल, साथ में क्लाउड बॉक्स पर फ़ॉरवर्डिंग और NAT। strongSwan की फ़ॉरवर्डिंग मार्गदर्शिका उस सेटअप का वापसी आधा हिस्सा समझाती है, और यहीं इनमें से अधिकांश प्रयास विफल होते हैं। घर के peer को अब ऊपर रहना पड़ेगा ताकि कुछ भी काम करे, यानी आपने एक निर्भरता को दूसरी से बदल दिया और यह लिख लेना चाहिए।

क्लाउड endpoint वास्तव में किसलिए है

क्लाउड endpoint आपका सार्वजनिक निकास बदलता है। ट्रैफ़िक प्रदाता के पता-परिसर से निकलता है, और साइटें घर के पते के बजाय वह पता देखती हैं। मूल्य यही है, और इसीलिए क्लाउड VPN आपको NAS नहीं देता: आपने निकास हटाया, LAN नहीं।

आप अब भी अतिथि सिस्टम, VPN सेवा और उसके क्रेडेंशियल चलाते हैं जबकि प्रदाता हाइपरवाइज़र और भौतिक नेटवर्क चलाता है, और रात 2 बजे कुछ टूटने पर यह बँटवारा मायने रखता है। सार्वजनिक endpoint लगातार स्कैन होता है, इसलिए प्रबंधन पोर्ट बंद रखें, केवल VPN पोर्ट की अनुमति दें और तय समय पर पैच करें। सुरक्षा समूहों और प्रदाता फ़ायरवॉल को वह पोर्ट अनुमत करना चाहिए, और कुछ क्लाउड इंस्टेंस पर स्रोत-गंतव्य जाँच ठीक किए बिना फ़ॉरवर्ड किया गया ट्रैफ़िक गिरा देते हैं।

छोटा इंस्टेंस मुट्ठी भर क्लाइंट संभालता है, पर एन्क्रिप्शन CPU का काम है, और क्रेडिट ख़त्म हो चुका burstable इंस्टेंस लगातार भार में असमान व्यवहार करता है। स्पेक शीट नहीं, जो रास्ता आप वास्तव में उपयोग करते हैं उसे देखें।

ऐसा निर्णय जो लिखा जा सके

काम जगह तय करता है, बॉक्स पर लगा लेबल नहीं। अगर आपके घर के LAN पर उपकरण चाहिए, तो सबसे सस्ता सही उत्तर घर पर endpoint है; घर की ओर लिंक बनाने के बाद ही क्लाउड बॉक्स काम करता है। अगर अलग सार्वजनिक निकास चाहिए, तो उत्तर क्लाउड है और LAN का सवाल ही नहीं उठता। दोनों चाहना वाजिब है, पर इसका मतलब दो endpoint, दो कुंजी-सेट और दो प्रलेखित मार्ग हैं।

What you needEndpoint locationWhat else must exist
Reach a NAS or printer on the home LANA box on that LANPort forward or relay, DDNS, recovery plan
Browse from an exit unrelated to homeCloud instanceFirewall and egress rules, patching
Both, reliablyTwo endpoints, or cloud plus a link homeSeparate keys, routes, documented failure modes

क्लाइंट से क्रम में जाँचें: हैंडशेक, peer पता, LAN मेज़बान, फिर निकास IP। curl -s https://ifconfig.me दिखाता है कि इंटरनेट क्या देखता है, और ip route get 192.168.1.20 दिखाता है कि endpoint क्या मानता है। जब निकास जाँच पास हो और NAS जाँच लटके, तो जगह के बारे में उत्तर आपके पास है; क्लाइंट पर AllowedIPs बदलने से मार्ग नहीं बनेगा। 10.8.0.0/24, 192.168.1.0/24 जैसी विभाजित पंक्ति LAN ट्रैफ़िक को टनल में केवल तब रखती है जब वह मार्ग वास्तव में मौजूद हो।

संबंधित लेख