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 यन्त्र हो। पहिले मार्ग पहिचान गर्नुहोस्, त्यसपछि प्रश्नको जवाफ दिने बिन्दु छान्नुहोस्, र रूपान्तरणको गलत पक्षतिर हेर्दा मात्र दुई दिशा फरक देखिन्छन् भन्ने अपेक्षा गर्नुहोस्।