टनेल उठ्छ, क्लाइन्ट हरियो बिन्दु देखाउँछ, र 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 ट्राफिक टनेलभित्र त्यो मार्ग साँच्चै अवस्थित भएमा मात्र राख्छ।

सम्बन्धित लेखहरू