OpenVPN क्लायंट ब्लॉक नियम FORWARD पर्यंत का कधीच पोहोचत नाही

एकाच OpenVPN सर्व्हरवरील दोन क्लायंट त्यांच्या पूलसाठी DROP नियम जोडल्यानंतरही एकमेकांपर्यंत पोहोचू शकतात। नियम FORWARD शृंखलेत बसलेला आहे, रहदारी स्पष्टपणे वाहत आहे, आणि त्या नियमाचा काउंटर शून्यावरच राहतो। स्वाभाविक निष्कर्ष असा की फायरवॉल बिघडलेला आहे। बहुतेक वेळा पॅकेट शृंखलेत आलेच नाही।

OpenVPN सर्व्हरमधून पीअर पॅकेट दोन मार्गांनी जाऊ शकते, आणि ते फायरवॉल नव्हे तर कॉन्फिगरेशन ठरवते। कोणता मार्ग वापरात आहे हे कळल्यास यजमानाचा नियम योग्य जागी आहे की नाही हे कळते।

पीअर पॅकेट जाऊ शकणारे दोन मार्ग

अंतर्गत फॉरवर्डिंग पर्याय बंद असताना, क्लायंट Aचे पॅकेट टनेल इंटरफेसवर येते आणि त्याचे लक्ष्य क्लायंट Bला दिलेल्या पत्त्याच्या आत असते। सर्व्हरच्या राउटिंग तक्त्याला Bच्या पत्त्यापर्यंतचा मार्ग असल्याने तो तेच टनेल इंटरफेस वापरून परत पाठवते। हा यजमानातून आत-बाहेर जाणारा प्रवाह आहे, आणि IPv4 फॉरवर्डिंग मार्ग त्याचे मूल्यांकन करतो।

अंतर्गत फॉरवर्डिंग पर्याय सुरू असताना, सर्व्हर प्रक्रिया पॅकेट जोडलेल्या क्लायंटशी जुळवते आणि तेथेच त्या क्लायंटकडे परत लिहिते। पॅकेट डेमनच्या आत हाताळले जाते आणि टनेल उपकरणात पुन्हा कधीच प्रवेश करत नाही, म्हणून यजमानाचा फॉरवर्डिंग मार्ग पूर्णपणे वगळला जातो। OpenVPN 2.6 पुस्तिका या पर्यायाला अंतर्गत क्लायंट-ते-क्लायंट फॉरवर्डिंग म्हणते, आणि यजमान फायरवॉलचा नियम त्याला का दिसू शकत नाही याचे हेच कारण आहे।

डेटा चॅनेल कर्नेल मॉड्यूलवर ऑफलोड करणाऱ्या तैनातींमध्ये तिसरा प्रकारही आहे। फॉरवर्डिंगचा निर्णय आणि एन्क्रिप्शन वापरकर्ता जागेबाहेर जातात, आणि netfilter प्रवाह पाहतो की नाही हे ऑफलोड मार्ग कसा बांधला आहे यावर अवलंबून असते। जुना नियमसंच ऑफलोड केलेल्या सर्व्हरवर वापरकर्ता जागेच्या सर्व्हरसारखाच वागेल असे कधीही गृहीत धरू नका। मोड पॅकेज आवृत्तीवरून नव्हे तर चालू कॉन्फिगरेशनवरून निश्चित करा।

जेव्हा काउंटर कधीच हलत नाही

शून्य काउंटर म्हणजे त्या टप्प्यावर पॅकेट त्या नियमाशी जुळले नाही, आणि कारणे अनेक आहेत। पहिले म्हणजे वर सांगितलेला बायपास: रहदारी शृंखलेपर्यंत पोहोचलीच नाही। दुसरे म्हणजे इंटरफेस, दिशा, स्रोत किंवा लक्ष्य यातील विसंगती, जी पूल पुन्हा क्रमांकित झाला आणि नियम अजूनही जुना प्रीफिक्स सांगत असताना सामान्य असते।

तिसरे म्हणजे स्थान। शृंखलेतील आधीचा नियम तुमच्या DROPचे मूल्यांकन होण्यापूर्वीच प्रवाह स्वीकारू शकतो, आणि नंतरचा नियम निकाल खरोखर ठरवणारा असू शकतो। काउंटर दिसतील अशा क्रमाने शृंखला वाचा, नंतर चाचणी पुन्हा केल्यावर कोणत्या नियमाची गणना वाढते ते तपासा।

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

फिल्टर करू शकणारी सीमा निवडणे

धोरण यजमान फायरवॉलमध्येच राहायचे असेल तर फायरवॉलला दिसेल तिथे रहदारी ठेवा। अंतर्गत फॉरवर्डिंग बंद करणे हाच पीअर रहदारी टनेल इंटरफेस आणि फॉरवर्डिंग मार्गातून जाऊ देण्याचा समर्थित मार्ग आहे, परंतु त्याची किंमत म्हणजे प्रत्येक पीअर पॅकेट यजमान स्टॅकमधून जाते।

नंतर प्रवाह अचूक जुळवा। रहदारी दोन्ही दिशांनी टनेल इंटरफेसवर येते आणि टनेल इंटरफेसवरून बाहेर पडते, म्हणून केवळ भौतिक इंटरफेस विचारात घेणारे नियम जुळणार नाहीत। पत्त्यावर आधारित नियमांना सध्याचा पूल आवश्यक आहे, आणि परतीची दिशाही पुढील दिशेइतकीच विचारात घ्यावी लागते।

अनेक तैनातींसाठी क्लायंट किंवा गट पातळीवर फिल्टर करणे अधिक उपयुक्त असते, जिथे ओळख ज्ञात असते आणि धोरण पुन्हा जोडणीत बदलणाऱ्या पत्त्याऐवजी वापरकर्त्याच्या मागे जाते। ही यजमान शृंखलेपेक्षा वेगळी यंत्रणा आहे, आणि स्पष्ट कारणाशिवाय दोन्ही मिसळू नयेत।

जुन्या टोपोलॉजीचा नियमसंच स्थलांतरातून विनाबदल घेऊन जाऊ नका। पत्ता पूल, इंटरफेसची नावे आणि फॉरवर्डिंग मोड हे सर्व नियम जुळतो की नाही यावर परिणाम करतात, आणि पूर्वी चालणारा नकल केलेला नियम हा सर्वात भ्रामक पुरावा आहे। ज्या प्रवाहाला परवानगी द्यायची आहे त्यापासून सुरुवात करा आणि त्याला जुळणारा नियम लिहा।

नियमावर विश्वास ठेवण्याऐवजी अलगीकरण तपासणे

प्रतिबंधित प्रकरण आणि परवानगी असलेले प्रकरण एकाच फेरीत तपासा। एका क्लायंटकडून दुसऱ्याकडे नवीन जोडणी सुरू करा आणि ती अयशस्वी होते याची खात्री करा, नंतर परवानगी असावी अशी जोडणी अजूनही चालते याची खात्री करा। फक्त पहिलेच तपासले तर सर्व काही अडवणारी फायरवॉल यशस्वी वाटते।

सर्व्हर कॉन्फिगरेशन पुन्हा लोड केल्यानंतर आणि क्लायंट पुन्हा जोडल्यानंतर पुनरावृत्ती करा, कारण अंतर्गत फॉरवर्डिंग आणि पूल वाटप ही रनटाइम स्थिती आहे। दोन्ही दिशांनी काउंटर तपासा, कारण एका दिशेशी जुळणारा पण उत्तराशी न जुळणारा नियम असे अंशतः अलगीकरण निर्माण करतो जे झटपट चाचणीत लक्षात घेणे कठीण असते।

अलगीकरण म्हणजे प्रवाह खरोखर वाहून नेणाऱ्या सीमेवर दिसणारा निकाल। यजमानात कुठेतरी असलेला DROP नियम पुरावा नाही; अयशस्वी जोडणी आणि तिला कारणीभूत नियमाचा हललेला काउंटर हा पुरावा आहे।