राउटरको एडमिन पृष्ठमा 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 मा प्रशासन प्रकाशित गर्ने कारण कहिल्यै होइन।