OpenVPN कनेक्ट होते पण काहीच वाहत नाही: पॅकेट कोणत्या थरात पडते ते शोधा
ट्रॅफिक नसलेल्या जोडलेल्या बोगद्याला किमान पाच कारणे असतात. श्रोता सिद्ध करा, बाहेरील पॅकेट कॅप्चर करा, मग काउंटर किंवा ट्रेसला नियमाचे नाव सांगू द्या.
OpenVPN कनेक्ट आहे असे म्हणते आणि कोणताही ट्रॅफिक हलत नाही, हे वाक्य किमान पाच असंबंधित बिघाड झाकते। कोणता थर अयशस्वी होतो हे कळण्यापूर्वी फायरवॉल नियम संपादित केल्यास अज्ञात गोष्टी वाढतात आणि पुढच्या अभियंत्यासाठी गोंधळ राहतो। त्याऐवजी प्रक्रियेपासून बाहेरच्या दिशेने काम करा, कारण खालील प्रत्येक पायरी एकतर एक टप्पा स्वच्छ करते किंवा पॅकेट कुठे मरते ते अरुंद करते। येथे क्रम महत्त्वाचा आहे: कोणता पत्ता बांधलेला आहे हे कळण्यापूर्वी घेतलेले कॅप्चर काहीतरी सिद्ध करेल, पण तुम्हाला हवे ते नाही।
सॉकेट एकतर बांधलेले आहे किंवा नाही
सक्रिय असल्याचे सांगणारी सेवा तुम्ही कधीही इरादा नसलेल्या पत्त्यावर किंवा वाहतुकीवर बांधलेली असू शकते। सॉकेटलाच विचारा: ss -lunp UDP श्रोते सूचीबद्ध करते आणि ss -ltnp TCP, आणि वाचण्यासारखा स्तंभ स्थानिक पत्ता आहे, स्थिती नाही।
रिकामे उत्तर सहसा तीनपैकी एक अर्थ दर्शवते: प्रक्रिया सुरू झाल्यानंतर बाहेर पडली, तिने दुसरी कॉन्फिगरेशन फाइल लोड केली, किंवा ज्या पत्त्यावर डायल केले जाते त्यापेक्षा वेगळ्या पत्त्यावर ऐकत आहे।
ss -lunp | grep 1194
ss -ltnp | grep 1194
local निर्देश श्रोत्याला एका पत्त्यावर पिन करतो, म्हणून त्याच होस्टवर दुसरीकडे लक्ष्य केलेला क्लायंट नाकारला जातो आणि सेवा बाहेरून अजूनही निरोगी दिसते। इन्स्टन्स नाव देखील तुम्ही कधीही संपादित न केलेल्या फाइलकडे निर्देश करू शकते, जे दोन प्रोफाइल शेजारी चालवणाऱ्या होस्टवर होते।
बाहेरील पॅकेट कॅप्चर करा, बोगदा नाही
भौतिक इंटरफेस आणि प्रत्यक्ष पोर्टवर फिल्टर करा, तुमचा इंटरफेस बदलून: tcpdump -ni eth0 udp port 1194। मागे काहीही न येणारे बाहेर जाणारे पॅकेट वरच्या गोष्टीकडे निर्देश करतात: प्रदाता फिल्टरिंग, NAT उपकरण, किंवा तुम्ही विचार करता त्यापेक्षा वेगळा दूरचा पत्ता। दोन्ही दिशांना शांतता क्लायंट राउटिंग किंवा स्थानिक फायरवॉलकडे निर्देश करते। बोगद्याची प्रगती नसताना येणारी उत्तरे नियंत्रण चॅनेलकडे निर्देश करतात, म्हणजे की किंवा सिफरची विसंगती, फिल्टरिंगकडे नाही।
दोन्ही दिशा कॅप्चर करा आणि फाइल छोटी ठेवा। लांब कॅप्चर मनोरंजक तीन सेकंद पुरून टाकते, आणि उत्तर जवळजवळ नेहमी पहिल्या देवाणघेवाणीत असते।
आधी काउंटर, ट्रेस फक्त ते खोटे बोलतात तेव्हा
काउंटरपासून सुरुवात करा, कारण त्यांचा काहीच खर्च नाही। एकतर nft list ruleset किंवा iptables -L -n -v येथे महत्त्वाच्या एकमेव प्रश्नाचे उत्तर देते: नियम जुळला का? क्रम निकाल ठरवतो, कारण पहिली जुळणी जिंकते, म्हणून नंतरच्या ACCEPT आधी रुंद DROP तो ACCEPT मृत ठेवते आणि म्हणून नियम जोडणे इतक्या क्वचितपणे काही सुधारते।
मालकीही लोकांना अडखळवते। कर्नेल स्थानिक पातळीवर तयार झालेले पॅकेट सॉकेट उघडणाऱ्या प्रक्रियेला जोडते, आणि OpenVPN सहसा root म्हणून चालते, त्यामुळे सामान्य वापरकर्ता ID ला बांधलेला नियम बोगद्याचा स्वतःचा ट्रॅफिक कधीही पाहत नाही। नियम चुकीचा आहे असे ठरवण्यापूर्वी मालक UID तपासा।
काउंटर अस्पष्ट राहिल्यावरच लॉग गोंगाटाला पात्र ठरतो, आणि तेव्हाही फक्त अरुंद भागासाठी: दर मर्यादित करणारा आणि आपल्या लॉग ओळींना उपसर्ग देणारा iptables नियम, किंवा nft monitor trace चालू असताना meta nftrace set 1 धारण करणारा nftables नियम। ट्रेस पॅकेट स्वीकारणाऱ्या किंवा टाकून देणाऱ्या साखळीचे आणि नियमाचे नाव सांगते। नंतर दोन्ही काढून टाका आणि पेलोड लॉगिंग बाहेर ठेवा।
वाहतूकही तपासा। TCP पर्यंत मर्यादित फायरवॉल सेवा त्या क्रमांकावरील UDP श्रोत्याबद्दल काहीही सांगत नाही, म्हणून योग्य वाचला जाणारा नियमही प्रत्येक पॅकेट टाकून देऊ शकतो।
राउटिंग आणि परतीचा मार्ग
स्वीकारलेले पॅकेट तरीही गायब होत असेल तर त्याचा गंतव्य मार्ग तपासणे आवश्यक आहे। ip route get एका पत्त्यासाठी निवडलेला मार्ग सांगते, आणि उलट मार्गाचे फिल्टरिंग मुख्य तक्ता कधीही निवडणार नाही अशा इंटरफेसमधून येणारे उत्तर टाकून देऊ शकते। लक्षण अगदी फायरवॉलने टाकून दिल्यासारखे दिसते, म्हणून ही तपासणी दुसऱ्या NAT नियमापूर्वी येते।
गेटवेवर input साखळीऐवजी फॉरवर्डिंग आणि forward साखळी तपासा। नंतर खात्री करा की दूरच्या बाजूला स्रोत पत्त्यापर्यंत पोहोचण्याचा मार्ग माहीत आहे, कारण कार्यरत बाहेर जाणाऱ्या मार्गावर काहीही परत न आल्यास दोन्ही प्रकरणांत शांतता असते।
नोंदीने काय सांगावे
प्रत्येक बदलासाठी, तपासलेला टप्पा, वाचलेला पुरावा आणि त्याच्या दोन्ही बाजूंचे काउंटर मूल्य नोंदवा। तीच नोंद "आता ते चालते" पुढच्या पुनरावलोकनात टिकवते।
दोन शॉर्टकट नोंद प्रामाणिक ठेवतात। होस्ट कधीही न सोडलेले पॅकेट दुसरीकडच्या नियमाने टाकून दिलेले असू शकत नाही, दूरच्या बाजूची कॉन्फिगरेशन कितीही विश्वासार्ह दिसली तरी। बाहेर जाऊन परत आलेले पॅकेट प्रश्न नेटवर्क थराच्या वर नेते, जिथे फायरवॉल काउंटरना तुम्हाला सांगण्यासारखे आता काही उरले नाही।