VPN परिवर्तनपछि राउटरको एडमिन पृष्ठले जवाफ दिन किन बन्द गर्छ

सुरुङ परीक्षण गर्न तपाईंले मार्ग वा फायरवाल नियम बदल्नुभयो, र अब दस मिनेट अघि राम्रो चलेको ल्यापटपबाट एडमिन पृष्ठले जवाफ दिँदैन। पहिलो प्रतिक्रिया VPN लाई दोष दिनु हो। प्रायः सुरुङ स्वस्थ हुन्छ र तीनमध्ये एउटा अरू कुरा बिग्रन्छ: राउटरको आफ्नै ठेगानामा फर्कने मार्ग छैन, कुनै इनपुट नीतिले अनुरोध फाल्छ, वा कुनै वेब सेवा तपाईंले कल गरेको ठेगानामा सुनिरहेको छैन। तीनवटै ब्राउजरमा उस्तै देखिन्छन्, त्यसैले मानिसहरू एक घण्टा सुरुङ पुनः सुरु गर्छन् र केही सिक्दैनन्।

पहिले मार्न लायक मिथक यही हो: चलिरहेको सुरुङ भित्र फर्कने बाटो होइन। यो आफ्नै भरोसाका प्रश्नहरू भएको नयाँ सञ्जाल जडान हो, र कसैले समीक्षा नगरेको नयाँ मार्ग खोल्दै पुरानो व्यवस्थापन मार्ग चुपचाप हटाउन सक्छ।

सुरुङ कहिल्यै व्यवस्थापन मार्ग थिएन

फर्वार्डिङ र इनपुट फरक काम हुन्। "के क्लाइन्ट सुरुङबाट NAS सम्म पुग्न सक्छ?" भन्ने राउटरबाट जाने प्याकेटबारे फर्वार्डिङ प्रश्न हो। "के मैं राउटरको SSH पोर्ट खोल्न सक्छु?" भन्ने राउटरलाई नै सम्बोधित प्याकेटबारे इनपुट प्रश्न हो। फर्वार्ड गरिएको ट्राफिकका लागि लेखिएको अनुमति नियम दोस्रो प्रश्नका लागि केही गर्दैन, र ट्राफिक राम्ररी बोक्ने सुरुङले पनि तपाईंको एडमिन सत्र अस्वीकार गर्नुको सबैभन्दा सामान्य कारण यही हो।

उल्टो गल्ती इन्टरफेसको नाममा भरोसा गर्नु हो। सुरुङ साथीसम्म इन्क्रिप्ट हुन्छ, त्यसको पछाडिका हरेक सेवासम्म होइन, र इन्टरफेस लेबलको VPN शब्दले कुन स्रोतलाई लगइन गर्न दिनुपर्छ भन्ने कुरा बताउँदैन।

पहिलो तह: राउटरको आफ्नै ठेगानामा मार्ग छ?

क्लाइन्टबाट सुरु गर्नुहोस् र कर्नेललाई प्याकेट कहाँ जान्छ भनी सोध्नुहोस्। Linux मा ip route get 10.6.0.1 ले छानिएको मार्ग, बाहिर जाने इन्टरफेस र स्रोत ठेगाना छाप्छ। यदि यसले तपाईंको ISP तर्फको पूर्वनिर्धारित मार्ग देखाउँछ भने प्याकेट कहिल्यै सुरुङमा पस्दैन, र राउटरको कुनै नियमले यसलाई बचाउन सक्दैन।

सुरुङ पक्षसँग प्रश्नको आफ्नै संस्करण छ। WireGuard ले AllowedIPs लाई क्रिप्टोकी राउटिङ तालिका मान्छ: प्रत्येक छेउमा यसले साथीले कुन स्रोत ठेगाना प्रयोग गर्न सक्ने र कुन गन्तव्य त्यो साथीलाई पठाइने घोषणा गर्छ। यदि क्लाइन्ट प्रविष्टिमा राउटरको सुरुङ ठेगाना छैन भने क्लाइन्टसँग त्यहाँ मार्ग छैन। यदि त्यो क्लाइन्टका लागि सर्भर प्रविष्टिले क्लाइन्टको सुरुङ ठेगाना ढाक्दैन भने सर्भरले कुनै पनि फायरवाल नियम हेर्नुअघि प्याकेट फाल्छ।

नीति डिबग गर्नुअघि तपाईं पुग्न चाहेको ठ्याक्कै ठेगाना पुष्टि गर्नुहोस्। पुरानो DNS रेकर्ड वा परिवर्तन अघिको क्यास गरिएको छिमेकी प्रविष्टिले तपाईंलाई राउटरसँग कहिल्यै नभएको ठेगानामा पठाउँछ।

दोस्रो तह: इनपुट नीति, फर्वार्डिङ नीति होइन

फायरवालहरूले प्याकेट आउने इन्टरफेसमा नियमहरू मूल्यांकन गर्छन्। pfSense र OPNsense मा इन्टरफेस ट्याब र नियमको क्रमले फायरवालका आफ्नै सेवाहरूमा ट्राफिक अनुमति छ कि छैन भन्ने निर्धारण गर्छ; LAN क्लाइन्टहरूलाई इन्टरनेटमा जान दिने नियम सुरुङ साथीलाई वेब GUI खोल्न दिने नियम होइन। firewall4 भएको OpenWrt मा प्रत्येक जोनले इनपुट नीति बोक्छ, option input 'ACCEPT' वा 'REJECT', र इनपुट REJECT भएको जोनको सुरुङ इन्टरफेसले व्यवस्थापन जडान अस्वीकार गर्छ तर फर्वार्डिङ अनुमति भए ट्राफिक अझै फर्वार्ड गर्छ।

नयाँ मार्ग चल्न भनी एन्टी-लकआउट नियम बन्द नगर्नुहोस्। त्यो नियमले खराब नियमले LAN व्यवस्थापन ठेगाना लक गर्नबाट रोक्छ; यसले LAN सबनेटको रक्षा गर्छ, तपाईंले भर्खरै बनाएको सुरुङ सबनेटको होइन। प्रशासकको स्रोतका लागि एउटा साँघुरो नियम थप्नुहोस् र सुरक्षा जालीलाई छुनुहोस् न। pfSense को एडमिन पहुँच कागजात ले ती नियन्त्रणहरू कहाँ छन् भनी व्याख्या गर्छ।

# on the router: bind addresses and the loaded ruleset
ss -ltnp | grep -E ':(22|80|443)\b'         # Linux / OpenWrt
sockstat -4 -l | grep -E ':(22|80|443)\b'   # FreeBSD / pfSense
nft list ruleset | grep -A6 'chain input'    # firewall4
pfctl -sr | head -40                         # pf / pfSense

तेस्रो तह: त्यो ठेगानामा केही सुनिरहेको छ?

सेवा चलिरहेको हुन सक्छ तर एउटै ठेगानामा बाँधिएको हुनाले पुग्न नसकिने हुन सक्छ। OpenWrt को uhttpd ले /etc/config/uhttpd मा स्पष्ट श्रवण प्रविष्टिहरू राख्छ, उदाहरणका लागि list listen_http '0.0.0.0:80'; केवल LAN ठेगानामा बाँधिने बिल्डले सुरुङ ठेगानामा केही स्वीकार गर्दैन, र श्रवण इन्टरफेस सेटिङ देखाउने उत्पादनहरूले पनि त्यसै गर्छन्। माथिका श्रवण आदेशहरूले यसको सिधा जवाफ दिन्छन्।

त्यसपछि अस्वीकारलाई मौनताबाट अलग गर्नुहोस्। nc -vz 10.6.0.1 443 ले अस्वीकृत जडान फर्काउनु भनेको प्याकेट राउटरसम्म पुग्यो र कसैले अस्वीकार गर्यो, या त बन्द पोर्ट या स्पष्ट अस्वीकृति नियम। टाइमआउटसम्म अड्किनु भनेको प्याकेट फालिएको वा कहिल्यै राउट भएको छैन। यो भिन्नताले अब कुन तह जाँच्ने भनी बताउँछ, र यसलाई पाँच सेकेन्ड लाग्छ।

VPN इन्टरफेस एउटा सीमा हो, पुनःप्राप्ति मार्ग होइन

इन्क्रिप्शनले तारको रक्षा गर्छ; एडमिन पृष्ठ कसले खोल्न सक्छ भन्नेबारे यसले केही भन्दैन। सुरुङ चल्न थालेपछि सुरुङ इन्टरफेसमा सबै अनुमति दिएर पुग्ने समस्या समाधान गर्ने लालसाको प्रतिकार गर्नुहोस्। प्रशासकहरूलाई उनीहरूको आफ्नै सुरुङ ठेगानामा बाँधिएको नियम वा छुट्टै प्रशासक-मात्र सुरुङ दिनुहोस्, र सामान्य प्रयोगकर्ता, NAS, क्यामेरा र परिवारका ल्यापटपलाई व्यवस्थापन पोर्टबाट टाढा राख्नुहोस्। फाइल साझेदारी चाहिने साथी राउटरको लगइनबाट एक नियमको दूरीमा पनि हुनु हुँदैन।

राउटरको भूमिकाले जवाफ बदल्छ। सुरुङ अन्त्य गर्ने राउटरले त्यसबाट प्रशासकहरूलाई कानुनी रूपमा स्वीकार गर्न सक्छ, जबकि सुरुङलाई केवल इन्टरनेट निकासका रूपमा प्रयोग गर्ने राउटरले सामान्यतया त्यसो गर्नु हुँदैन। दुवै अवस्थामा सबनेट अनुमति भनेको लगइन होइन, त्यसैले खाता प्रमाणीकरण र यातायात सुरक्षा सक्रिय राख्नुहोस्।

लकआउटपछि मानिसहरूले गर्ने क्षतिपूर्ति कदम अझ नराम्रो हुन्छ: WAN व्यवस्थापन सक्रिय गर्नु वा वेब GUI तर्फ पोर्ट फर्वार्ड गर्नु। यसले छोटो अवरोधलाई स्थायी खुलासामा बदल्छ, र लगइन पृष्ठ त्यसपछि इन्टरनेटका हरेक स्क्यानरका लागि पुग्नयोग्य हुन्छ। अनुमति दिइएको पक्षजस्तै अस्वीकृत पक्ष पनि परीक्षण गर्नुहोस्, ताकि एडमिन पहुँच हुनु नहुने साथीले लगइन अनुरोधको सट्टा टाइमआउट वा अस्वीकृति पाओस्।

नयाँ जडानसँग पनि परीक्षण गर्नुहोस्। स्टेटफुल फायरवालले हालका प्रवाहहरू आफ्नो स्टेट तालिकामा राख्छ, त्यसैले तपाईंको पहिले नै खुला SSH सत्र हरेक नयाँ जडान अवरुद्ध गर्ने परिवर्तनबाट जोगिन सक्छ। यसरी लकआउट अर्को रिबुट वा ल्यापटपको अर्को निद्रासम्म अदृश्य रहन्छ।

नीतिलाई छुनुअघि फर्कने बाटो तयार पार्नुहोस्

पहिलो परिवर्तन अघि चार कुरा लेख्नुहोस्: सुरुङ मरेमा तपाईं यन्त्रसम्म कसरी पुग्नुहुन्छ, जस्तै सिरियल कन्सोल, प्रदायकको कन्सोल वा LAN मा रहेको मेसिन; हालको कन्फिगरेसन कहाँ निर्यात हुन्छ; कुन एउटा नियम वा मार्ग बदल्न लाग्नुभएको छ; र त्यही वस्तु ठ्याक्कै कसरी फर्काउनुहुनेछ। OpenWrt मा sysupgrade -b /tmp/backup.tar.gz ले कन्फिगरेसन समात्छ, र परिवर्तनहरू uci commit सम्म पेन्डिङ रहन्छन्, जसले समयमै ध्यान दिए सस्तो पूर्ववत् गर्ने मौका दिन्छ। pfSense ले कन्फिगरेसन इतिहास राख्छ, र AutoConfigBackup ले पहिले नै सक्रिय भएमा मात्र मद्दत गर्छ। राउटरले fail-closed नियम समूह चलाउँछ भने तपाईंको योजनाबद्ध मर्मत मार्ग त्यो नियमले अवरुद्ध गर्ने ट्राफिकभित्र नभएको पुष्टि गर्नुहोस्, र रिबुटले स्थायी नियमहरू मेट्नुको सट्टा फेरि लागू गर्छ भनी सम्झनुहोस्।

प्रत्येक प्रयासमा एउटा सीमा बदल्नुहोस्, त्यसपछि खुला राखिएको शेलको सट्टा नयाँ जडानबाट परीक्षण गर्नुहोस्। परीक्षण असफल भए अर्को तह छुनुअघि त्यही एक परिवर्तन फर्काउनुहोस्। सुरुङ सधैं माथि रहन सक्छ, तर यसको हरियो स्थिति चिन्ह तपाईं अझै भित्र पस्न सक्नुहुन्छ भन्ने प्रमाण होइन।

जानुअघि छिटो जाँच:

• तपाईंले भर्खरै सम्पादन गरेको नियममा निर्भर नहुने स्रोतबाट राउटरसम्म पुग्न सक्नुहुन्छ?
• सुरुङ इन्टरफेसको इनपुट नीतिले प्रशासकको स्रोतलाई मात्र अनुमति दिन्छ?
• व्यवस्थापन सेवा सुरुङमा रहेको ठेगानामा बाँधिएको छ?
• तपाईंले एउटा अस्वीकृत साथी र एउटा नयाँ सत्र परीक्षण गर्नुभयो?
• WAN व्यवस्थापन सतह अझै बन्द छ?