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 डिवाइस है। पहले पथ पहचानें, फिर वह बिंदु चुनें जो प्रश्न का उत्तर देता है, और अपेक्षा करें कि दोनों दिशाएँ केवल तभी अलग दिखेंगी जब आप रूपांतरण के गलत पक्ष को देख रहे हों।