tcpdump IPsec मधील साधा मजकूर फक्त एकाच दिशेने का दाखवतो

तुम्ही Linux IPsec गेटवेच्या बाहेरील इंटरफेसवर tcpdump चालवता आणि एकाच वेळी दोन गोष्टी पाहता: येणारे ESP फ्रेम्स आणि त्यानंतर लगेच डिक्रिप्ट केलेले आतील पॅकेट। बाहेर जाताना फक्त ESP दिसतो। स्वाभाविक निष्कर्ष असा येतो की प्रतिसाद पाठवले जात नाहीत किंवा IPsec एक दिशा एन्क्रिप्ट करतो आणि दुसरी विसरतो। दोन्हीपैकी काहीही खरे नाही।

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

कॅप्चर बिंदूच ठरवतो तुम्हाला काय दिसते

सामान्य इंटरफेसवर AF_PACKET सॉकेट उपकरणाच्या स्तराजवळ बसते। होस्ट सोडणारी पॅकेट प्रथम IPsec आउटपुट प्रोसेसिंगमधून जातात, जी आतील TCP विभागाचे ESP किंवा UDP-4500 डेटाग्राममध्ये रूपांतर करते, आणि त्यानंतरच त्या स्तरावर पोहोचतात। येणारी पॅकेट तारेतून येताच, अजूनही एन्क्रिप्टेड स्थितीत सॉकेटमध्ये कॉपी होतात, आणि डिक्रिप्ट केलेला निकाल स्टॅक तो स्थानिक पातळीवर पोहोचवतो किंवा पुढे पाठवतो तेव्हा नंतर दिसतो।

हा क्रम विषमता पूर्णपणे स्पष्ट करतो। हा दिशा, धोरण किंवा अनुप्रयोगाच्या वर्तनाचा पुरावा नाही, आणि त्याला तसे मानल्यास लोक सुरुवातीपासून योग्य पद्धतीने पाठवलेल्या प्रतिसादाच्या मागे धावतात। हे अशा मोजक्याच नेटवर्किंग कोड्यांपैकी एक आहे जिथे विसंगती नेटवर्क नाही, साधन निर्माण करते।

तुम्हाला अभिप्रेत असलेल्या स्तराशी फिल्टर जुळवा

tcp port 443 सारखे अभिव्यक्ती आतील TCP कनेक्शन निवडते। बाहेर जाताना सॉकेटला विचारले जाईपर्यंत ते कनेक्शन आधीच ESP झालेले असते, त्यामुळे फिल्टर कशाशीही जुळत नाही। तुम्हाला संरक्षित रहदारी मोजायची असेल तर त्याऐवजी बाहेरील स्वरूपावर फिल्टर करा: कच्च्या ESP साठी प्रोटोकॉल 50, किंवा NAT ट्रॅव्हर्सल असल्यास UDP पोर्ट 4500। दोन्ही फिल्टर दोन सहभागींमध्ये तुलना करता येणारी पॅकेट संख्या देतात, आणि साधारणपणे मोजण्याचे कारणही तेच असते। त्यांपैकी कोणतेही आतील विनंतीला उत्तर मिळाले का हे सांगत नाही।

UDP 4500 च्या संख्येला ESP पॅकेट संख्या मानू नका। IKE तो पोर्ट NAT-T कीपअलाइव्ह आणि एन्कॅप्स्युलेटेड देवघेवीसाठीही वापरतो, त्यामुळे संख्येमध्ये तुम्हाला मोजायचा असलेला डेटा नसलेली रहदारीही येते। UDP 500 वरील सुरुवातीच्या IKE देवघेवीला तोच प्रश्न असेल तर स्वतःचा फिल्टर लागतो। नियंत्रण रहदारी डेटाशी मिसळणारी संख्या कोणत्याही बँडविड्थ अंदाजालाही अज्ञात प्रमाणात चुकीचे करते। वेगवेगळी मोजणी वेगवेगळ्या प्रश्नांची उत्तरे देते।

फिल्टर तो ज्या प्रश्नाचे उत्तर देतो त्याच्या शेजारी लिहा। «बॉक्समधून किती ESP बाहेर गेले» आणि «वेब विनंती बॉक्समधून बाहेर गेली का» या वेगवेगळ्या फिल्टरसह वेगवेगळ्या मोजण्या आहेत, आणि एक कॅप्चर दोन्ही ठरवू शकत नाही। ती नोंद नसेल तर दोन माणसे अशा संख्यांची तुलना करतील ज्यांनी कधीच एकच गोष्ट मोजली नाही।

रूपांतरापूर्वी निरीक्षण करा, नंतर नाही

तुम्हाला बाहेर जाणारा साधा मजकूर पाहायचा असेल तर निरीक्षण बिंदू आधी, IPsec आउटपुट प्रोसेसिंगपूर्वी हलवा। NFLOG तुम्हाला Netfilter हुक देतो जिथे नियम निवडलेली पॅकेट वापरकर्ता-जागेतील सॉकेटमध्ये कॉपी करू शकतो, जे tcpdump वाचू शकतो। strongSwan चे रहदारी-डंप मार्गदर्शक हा दृष्टिकोन याच कारणासाठी नोंदवते।

धोरण जुळणी नियमाला बोगद्यात प्रवेश करणार्या रहदारीपुरता मर्यादित करते। -m policy --pol ipsec --dir out नियमाला विशिष्ट बनवते, बॉक्स पाठवत असलेल्या प्रत्येक पॅकेटची नोंद करण्याऐवजी। नंतर लॉग गट मर्यादित कॅप्चरने वाचा: थोडी स्नॅपशॉट संख्या आणि आकार मर्यादा निदानाला रहदारी-संग्रह बनण्यापासून रोखतात। मर्यादित कॅप्चर समीक्षकाकडे सोपवणेही सोपे आहे, असंबंधित पेलोड ओढावे लागत नाही। किती आले हे पाहिल्यानंतर नाही, सुरू करण्यापूर्वी संख्या ठरवा।

iptables -I OUTPUT 1 -d 10.83.0.44/32 -p tcp --dport 8443 -m policy --pol ipsec --dir out -j NFLOG --nflog-group 5
tcpdump -ni nflog:5 -s 128 -c 20 'host 10.83.0.44 and tcp port 8443'

प्रवाहाला अनुरूप हुक निवडा। OUTPUT गेटवे स्वतः निर्माण करणार्या रहदारीचा समावेश करतो; LAN क्लायंटमधून जाणे त्याऐवजी FORWARD साखळीतून होते, आणि OUTPUT वरील नियम ते कधीच पाहणार नाही। वरील पत्ता आणि पोर्ट मंजूर चाचणी गंतव्यासाठी जागाधारक आहेत।

निरीक्षण काय सिद्ध करते

NFLOG हे लॉगिंग लक्ष्य आहे, स्वीकृतीचा निर्णय नाही। तिथे दिसणारे पॅकेट दाखवते की ते हुकपर्यंत पोहोचले आणि नियमाशी जुळले। त्यानंतरच्या फिल्टरने ते अनुमत केले, उपकरणाने ते पाठवले, किंवा सहभागीला काही मिळाले हे ते दाखवत नाही।

रिकामा लॉगही तितकाच संदिग्ध आहे। नियमाचा पॅकेट काउंटर तपासा, दिशा पुष्टी करा, प्रवाह खरोखर IPsec धोरणाशी जुळला हे पुष्टी करा, आणि गंतव्य पुष्टी करा। दोन्ही सहभागींवर जुळणारा काउंटरच निरीक्षणाचे निष्कर्षात रूपांतर करतो। नंतर त्याच नियंत्रित प्रयत्नासाठी दोन्ही सहभागींवरील सुरक्षा संघटनेचे काउंटर तुलना करा, कारण SA काउंटर हे काय संरक्षित केले आणि पाठवले याचे अधिकृत नोंद आहे।

अजून एक सापळा: या संदर्भात «साधा मजकूर» म्हणजे IPsec एन्क्रिप्शन स्तराबाहेर। आतील HTTPS सत्राला अजूनही स्वतःचे TLS असते। डीकॅप्स्युलेट केलेले पॅकेट पकडल्याने अनुप्रयोगाचे TLS डिक्रिप्ट होत नाही, आणि तिथे वाचनीय HTTP दिसले तर अनुप्रयोगाने सुरुवातीपासून HTTPS वापरलेच नाही असे होते।

स्वच्छ करा आणि दोन्ही टोके तुलना करा

निरीक्षण संपताच तुम्ही घातलेला नेमका तोच नियम, त्याच्या मालकानुसार, काढून टाका। लॉगिंग नियम तसाच ठेवल्यास प्रत्येक जुळणार्या पॅकेटवर CPU खर्च होतो आणि शांतपणे डेटा धारणा समस्या निर्माण होते। तुमची नसलेली साखळी फ्लश करण्याऐवजी -D सह नियम पुन्हा करून हटवा।

iptables -D OUTPUT -d 10.83.0.44/32 -p tcp --dport 8443 -m policy --pol ipsec --dir out -j NFLOG --nflog-group 5

जर उपयोजन वापरकर्ता-जागा IPsec, XFRM इंटरफेस किंवा हार्डवेअर ऑफलोड वापरत असेल तर निरीक्षण बिंदू सरकतात आणि ही कृती अजिबात लागू होणार नाही। libipsec सह आतील रहदारी पाहण्याचे नोंदवलेले स्थान TUN उपकरण आहे। प्रथम मार्ग ओळखा, नंतर प्रश्नाचे उत्तर देणारा बिंदू निवडा, आणि दोन्ही दिशा फक्त तेव्हाच वेगळ्या दिसतील जेव्हा तुम्ही रूपांतराच्या चुकीच्या बाजूला पाहत असाल।