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 प्रबंधन सतह अब भी बंद है?