VPN सर्व्हरसाठी क्लाउड फायरवॉल विरुद्ध होस्ट फायरवॉल

क्लाउड धोरणात VPN पोर्टला परवानगी दिली तरी हँडशेक इन्स्टन्सवरच मरू शकतो: पाहुणा स्वतःचा फिल्टर आणि स्वतःचे श्रोता-बंधन चालवतो, आणि यापैकी कोणतेही क्लाउडने मंजूर केलेले टाकून देऊ शकते. उलटेही घडते, जेव्हा होस्टचा नियम पोर्टला परवानगी देतो आणि वरचे धोरण तो आधीच टाकून देते. दोन मालक, नियमांचे दोन संच, एक पॅकेट मार्ग. सर्वात संशयास्पद स्तरावर अंदाज लावण्याऐवजी तो क्रमाने चाला.

कडापासून सुरुवात करा आणि आत जा

क्रम निश्चित आहे: सार्वजनिक टोक, संसाधन इंटरफेस, जोडलेले क्लाउड धोरण, पाहुण्याचा पत्ता, प्रक्रिया श्रोता, स्थानिक इनपुट नियम. प्रत्येक टप्पा पॅकेट पुढे सोडतो किंवा तपासणी संपवतो, म्हणून पाहुण्यापासून सुरुवात केल्यास सर्वाधिक वेळ वाया जातो.

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

पाहुण्याला स्पर्श करण्यापूर्वी क्लाउड धोरण वाचा

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

व्याप्ती अर्थपूर्ण होईपर्यंत अरुंद करा. VPN पोर्ट संपूर्ण इंटरनेटसाठी उघडणे सिद्ध करायला सोपे आणि संरक्षित करायला कठीण, तर एका पत्त्यावर खोचलेला नियम तुमचा चाचणी क्लायंट नेटवर्क बदलल्यावर तुटतो. नियमाचा ओळखकर्ता आणि धोरणाचा मालक नोंदवा, जेणेकरून पुढील बदल व्यक्तीपर्यंत शोधता येईल.

आधी श्रोता, नंतर इनपुट साखळी निश्चित करा

इन्स्टन्सवर तपासा की VPN प्रक्रिया तुम्ही अपेक्षित असलेल्या पत्त्या व पोर्टला बांधलेली आहे, उदाहरणार्थ ss -lntp 'sport = :1194' वापरून. फक्त 127.0.0.1 ला बांधलेला डीमॉन स्थानिक क्लायंट स्वीकारतो आणि टनेलमधून काहीही नाही, जे बाहेरून अगदी फिल्टर केलेल्या पोर्टसारखे दिसते.

नंतर स्थानिक नियम ते बदलण्यासाठी वापरण्याच्या त्याच वाक्यरचनेत वाचा, उदाहरणार्थ iptables -S INPUT किंवा nft list chain inet filter input. फाइलमध्ये लिहिलेला पण कधीही लोड न केलेला नियम, किंवा जुळणारी परवानगी नसलेला डीफॉल्ट ड्रॉप, पॅकेट गुपचूप टाकून देतो. पुढे पाठवणाऱ्या गेटवेसाठी पाठवणे व उलट मार्ग सेटिंग्जही तपासा. इन्स्टन्सला उद्देशून नसलेल्या पण त्यातून मार्गक्रमण होणाऱ्या पॅकेटचे काय होते हे तेच ठरवतात.

एका स्तरात स्टेटफुल, पुढच्या स्तरात स्टेटलेस

सुरक्षा गटांना त्यांनी परवानगी दिलेले प्रवाह आठवतात आणि प्रतिसाद परत आत येऊ देतात. सबनेट प्रवेश नियंत्रण सूची आणि अनेक होस्ट फायरवॉल अशी स्थिती ठेवत नाहीत, त्यामुळे फक्त बाहेर जाणारी दिशा व्यापणारा नियम विनंती पुढे सोडतो आणि प्रतिसाद टाकून देतो. दुसऱ्या स्तराचा नियम न वाचता स्तरांमध्ये परतीच्या रहदारीबद्दलची गृहीतक कधीही पुढे नेऊ नका (second layer's rule).

खात्यातील प्रत्येक नियम वाचण्यापेक्षा काउंटर लवकर निर्णय देतात. वाढणारा काउंटर म्हणजे पॅकेट तिथे पोहोचले आणि तिथेच टाकून दिले गेले, तर शून्यावर गोठलेला काउंटर म्हणजे ते तिथपर्यंत पोहोचलेच नाही; नियम काउंटरसह लोड केले असतील तर iptables -vnL INPUT आणि nft list ruleset ते आकडे दाखवतात.

जिवंत सत्राने नाही, नवीन सत्राने चाचणी करा

दृश्ये तुलना करताना स्रोत नेटवर्क आणि चाचणी प्रोफाइल बदलू नका, आणि प्रत्येक बदलानंतर नवीन कनेक्शन उघडा. 443 वर वेब कन्सोल गाठणे म्हणजे VPN डीमॉन 1194 ला बांधलेला आहे का हे काहीच सांगत नाही, म्हणून तुम्हाला आवश्यक असलेल्या पोर्टची चाचणी करा. येथे विद्यमान सत्र हा सर्वात वाईट साक्षीदार आहे. प्रत्येक नवीन लॉगिन नाकारले जात असतानाही ते चालू राहते.

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