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 प्रशासन पृष्ठभाग अजूनही बंद आहे का?