राउटरच्या अॅडमिन पानापर्यंत WAN नाही, VPN ने पोहोचा

राउटरचे अॅडमिन पान सोफ्यावरून दोन सेकंदात उघडते आणि हॉटेलच्या खोलीतून वेळ संपते, तर VPN क्लायंट सतत जोडलेले असल्याचे सांगत असतो. तुमच्याकडे बाहेर जाण्याचा मार्ग आहे, परत येण्याचा नाही: टनेल तुमचा रहदारी इंटरनेटपर्यंत नेते आणि तिथेच थांबते. तुमच्याच LAN मधील उपकरणापर्यंत पोहोचण्यासाठी तिथपर्यंत मार्ग असलेल्या एखाद्यावर संपणारे सत्र लागते. हा डिझाइनचा निर्णय आहे, सेटिंग नाही, आणि उर्वरित काम अजिबात शक्य आहे का हे तोच ठरवतो.

हा फरक गमावणे सोपे आहे कारण एकच उत्पादन दोन्ही कामे करू शकते. व्यापारी एग्झिट क्लायंट आणि दूरस्थ प्रवेश सर्व्हर एकाच पोर्टवर एकाच प्रोटोकॉलने बोलू शकतात, आणि फरक एवढाच की एंडपॉइंटच्या मागील पत्ता जागेचा मालक कोणता बाजू आहे.

टनेलची कोणती बाजू LAN ची मालक आहे

प्रशासनासाठी एंडपॉइंट तुम्हाला पोहोचायच्या नेटवर्कमध्ये असावा, किंवा त्यात अधिकृत मार्ग असावा. स्वतःचा VPN सर्व्हर चालवणारा राउटर पात्र आहे; स्थिर पत्ता आणि LAN पर्यंत मार्ग असलेला छोटा, सतत सुरू असणारा होस्टही पात्र आहे. तिसऱ्या पक्षाची एग्झिट सेवा पात्र नाही, कारण तिच्या एंडपॉइंटचा तुमच्या LAN वर इंटरफेस नाही आणि एक दिसू देईल असे नियमही नाही. दुसरे काहीही हात लावण्यापूर्वी ही तपासणी पूर्ण करायला हवी.

फर्मवेअर हा फरक क्वचितच लेबल करते, म्हणून प्रोटोकॉलचे नाव नाही, वैशिष्ट्य काय करते ते वाचा. WireGuard, OpenVPN आणि IKEv2 हे सर्व बाजाराच्या दोन्ही बाजूंना दिसतात: एक बिल्ड घरगुती रहदारी बाहेर पाठवते, दुसरे तुमचे दूरस्थ उपकरण स्वीकारते. फक्त-क्लायंट बिल्डला कॉन्फिगरेशनने सर्व्हर करता येत नाही, मेनू कसाही लिहिला असला तरी.

परतीचा मार्ग तयार करणे

राउटरवरील WireGuard सर्व्हरला 10.8.0.1/24 सारखा इंटरफेस पत्ता आणि लॅपटॉपसाठी एक पीअर नोंद असते. कोणती गंतव्ये टनेलमध्ये पाठवायची हे क्लायंट ठरवतो, आणि फक्त टनेलचे सबनेट असलेली यादी LAN अदृश्य ठेवते, सर्व्हर कसाही कॉन्फिगर केलेला असला तरी. दोन्ही टोकांनी सहमती द्यावी लागते, आणि सहसा त्यातील एकच संपादित केले जाते.

wg show wg0 allowed-ips
ip route get 192.168.1.1

पहिला कमांड सर्व्हरच्या दृष्टिकोनातून प्रत्येक पीअरला काय पाठवता येते ते सांगतो; दुसरा क्लायंटवर LAN पत्ता प्रत्यक्षात कुठे जाईल ते सांगतो. टनेल इंटरफेसवर सोडवला जाणारा LAN गंतव्य म्हणजे चालणारे राउटिंग, आणि भौतिक गेटवेमधून बाहेर पडणारा फायरवॉल काहीही म्हणो, कधीच पोहोचणार नाही. क्लायंटच्या परवानगी यादीत LAN प्रीफिक्स जोडा, मग तेच दोन कमांड निदानाऐवजी पडताळणीचे पाऊल होतील.

IPsec गेटवेसाठी तोच उडी वर्णन करते strongSwan ची फॉरवर्डिंग माहिती, जिथे फॉरवर्डिंग आणि source-NAT नियम टनेल क्लायंटला अंतर्गत होस्टशी जोडतात. पत्ता पद्धत वेगळी; आवश्यकता नाही.

अॅडमिन पान कोण उघडू शकतो

प्रवेश नियंत्रण राउटरवर असते, सावध राहण्याच्या हेतूत नाही. पानाची गरज असलेल्या प्रमाणित टनेल ओळखीला किंवा स्रोत श्रेणीला मात्र परवानगी द्या, आणि राउटरची स्वतःची इनपुट साखळी तसेच कोणतेही फॉरवर्ड केलेले LAN धोरण वाचा. वायर्ड LAN ला अॅडमिन पानापर्यंत पोहोचू देणारा नियम टनेल इंटरफेसवर येणाऱ्या क्लायंटबद्दल काहीच सांगत नाही. ठराविक ओळखीसाठी अपवाद लिहा, मग नाकारला पाहिजे अशी दुसरी ओळख ठेवा.

श्रोता दुसरा अर्धा आहे आणि फायरवॉल आउटपुटमध्ये तो अदृश्य आहे. ss -ltnp वेब सर्व्हर ज्या पत्त्यावर बांधलेला आहे तो दाखवतो, आणि फक्त LAN पत्त्यावर बांधलेली सेवा टनेल पत्त्यावर उत्तर देणार नाही, नियम कितीही परवानगी देणारे असले तरी. तिला पुन्हा बांधणे किंवा पत्ता जोडणे हे राउटरवरील कॉन्फिगरेशन बदल आहे, फायरवॉल बदल नाही.

प्रमाणीकरण आणि वाहतूक पडताळणी एकाच फेरीत सुरू ठेवा. पोहोचणे म्हणजे विश्वास नाही, आणि टनेलमधील प्रत्येक उपकरण त्यामुळे प्रशासक होत नाही. टनेल क्रेडेन्शियल आणि राउटर खाते वेगवेगळ्या जीवनचक्रांचे वेगवेगळे विशेषाधिकार आहेत, म्हणून हरवलेल्या लॅपटॉपची की प्रत्येक प्रशासकाचा पासवर्ड रीसेट न करता रद्द करता येते.

सोफ्यावरून नाही, बाहेरून चाचणी

तुम्ही नियंत्रित न करता त्या नेटवर्कमधून चाचणी करा. मंजूर टनेलमधून जोडा, नवीन अॅडमिन सत्र उघडा आणि पानावर प्रतिबिंबित होताना दिसणारे निरुपद्रवी काहीतरी बदला. सोफ्यावरून तुम्ही LAN चालते हे सिद्ध करता, ज्याबद्दल कधीच शंका नव्हती.

मग तितक्याच काळजीने नकारांची चाचणी करा. टनेलशिवाय पान उघडण्याचा प्रयत्न करा आणि ते अयशस्वी होते हे पुष्टी करा, आणि प्रशासन सेवा WAN पत्त्यावर अजिबात ऐकत नाही याची पुष्टी करा. फक्त दुवा नसलेले पान प्रवेश नियंत्रण नाही, आणि लॉगिन फॉर्म दाखवणारा WAN श्रोता तरीही WAN श्रोता आहे. इंटरनेट आणि राउटर कन्सोलमध्ये फक्त पासवर्ड असेल, तर डिझाइन म्हणजे पासवर्ड.

घरातील सेवा तुम्ही तिथे असताना एक नजर टाकण्यासारख्या आहेत. व्यवस्थापन नियम कडक करणे अनेकदा गेस्ट नेटवर्क किंवा कुटुंबाची उपकरणे वापरत असलेला रिझोल्व्हर तोडते, आणि ते दिवसांनंतर असंबंधित तक्रार म्हणून समोर येते.

बदल करताना परतीचा मार्ग ठेवणे

दूरून मार्ग किंवा टनेल सेटिंग्ज बदलण्यापूर्वी स्वतंत्र परतीचा मार्ग तयार करा. विद्यमान सत्र नवीन कनेक्शन्स आधीच अडवणाऱ्या बदलातून टिकू शकते, आणि अजूनही चालू असलेले सत्र पाहत लोक स्वतःला बाहेर कुलूपबंद करतात ते नेमके अशाच प्रकारे. पर्याय ठोस आहेत: ज्ञात कॉन्फिगरेशनवर नियोजित रीबूट, कन्सोल किंवा भौतिक प्रवेश, संपादित होत असलेल्या सेटिंगवर अवलंबून नसलेले दुसरे टनेल, किंवा हार्डवेअर देते तिथे आउट-ऑफ-बँड व्यवस्थापन. एक निवडा आणि देखभाल विंडोच्या आधी ते सिद्ध करा, तिच्या दरम्यान नाही.

नोंद थोडक्यात आणि अद्ययावत ठेवा: कोणता होस्ट टनेल संपवतो, कोणत्या ओळखी पानापर्यंत पोहोचू शकतात, सेवा कोणत्या पत्त्यावर बांधली आहे आणि हरवलेले उपकरण कसे रद्द होते. ती यादी पुनर्प्राप्ती योजना म्हणूनही काम करते, कारण प्रत्येक अवलंबित्व कुठे आहे ते सांगते. गहाळ परतीचा मार्ग ही दुरुस्त करायची राउटिंग समस्या आहे, आणि ते WAN वर प्रशासन प्रकाशित करण्याचे कारण कधीच नाही.