तपाईंले IPsec होस्टमा ट्राफिक क्याप्चर गर्नुभयो, ESP प्याकेट बाहिर जाँदै गरेको देख्नुभयो, फर्केर केही आएको देख्नुभएन, र टाढाको पक्ष बिग्रिएको निष्कर्ष निकाल्नुभयो। क्याप्चरले त्यो निष्कर्षलाई समर्थन गर्दैन। ESP कुराकानीको एउटा दिशा मात्र सुरक्षित गर्छ र IP तहमा केही पुष्टि गर्दैन, त्यसैले फर्कने ESP नहुनु भनेको एपसँग भन्न केही नभएको पनि हुन सक्छ, जति सजिलै सुरुङ मरेको पनि हुन सक्छ। कुनै पनि छेउलाई दोष दिनु अघि आन्तरिक आदानप्रदान र प्राप्त गर्ने पक्षको अवस्था पढ्नुहोस्।

भ्रम: हरेक सुरक्षित प्याकेटले जवाफ पाउँछ

ESP अनुरोध-जवाफ प्रोटोकल होइन। नीतिले छान्ने जे पनि यसले इन्क्रिप्ट र प्रमाणित गर्छ, र प्राप्तकर्ताले त्यो आन्तरिक प्याकेट आफैं प्याकेट नबनाई प्रमाणित गर्छ, डिक्रिप्ट गर्छ र पुर्याउँछ। गन्तव्यले बेवास्ता गर्ने UDP प्रश्न, वा आउने नीतिले फाल्ने ICMP प्रतिध्वनि, दुवै दिशामा मौनतालाई सही नतिजाको रूपमा उत्पन्न गर्छ। त्यो मौनतालाई यातायात विफलता मान्नुले तपाईंलाई कहिल्यै नभएको सञ्जाल खराबी खोज्न पठाउँछ।

एकतर्फी क्याप्चरले वास्तवमा प्रमाणित गर्ने कुरा त्यो अवलोकन बिन्दुमा पठाउनेको स्ट्याकले केही इन्क्रिप्ट गरेको हो। आइपुग्नेबारे केही होइन, र जवाफ दिने नियतबारे पनि केही होइन। उपयोगी प्रश्न „जवाफ किन छैन“ होइन, „आन्तरिक कुराकानीले के उत्पादन गर्नुपर्थ्यो“ हो।

दुई SA, दुई SPI, एउटा कुराकानी

IPsec सुरक्षा एसोसिएसनहरू एकतर्फी हुन्छन्, त्यसैले सामान्य सुरक्षित आदानप्रदानले छुट्टाछुट्टै पहिचान र स्वतन्त्र अवस्था भएको आउने एसोसिएसन र जाने एसोसिएसन चलाउँछ। बाहिर जाने प्याकेटको SPI का लागि फर्कने ट्राफिक खोज्नु त्यसैले वर्गको त्रुटि हो, किनकि कुनै पनि जवाफ साथीको आफ्नै जाने SA मुनि आफ्नै SPI सहित यात्रा गर्छ। बरु जोडीलाई ट्राफिक चयनकर्ता र साथीको ठेगानाले मिलाउनुहोस्।

कुञ्जी नवीकरणले केही सेकेन्डका लागि चित्र जटिल बनाउँछ, किनकि पुरानो र प्रतिस्थापन अवस्था एकआपसमा पर्न सक्छन्। यदि लक्षण कुञ्जी परिवर्तनको वरपर सुरु भयो भने, कनेक्सनको नाम मात्र नभई एसोसिएसन पहिचान र समय-छापहरू सँगै संकलन गर्नुहोस्।

केही पनि जवाफ दिनु अघि प्राप्तकर्ताले के गर्नुपर्छ

StageWhat to look atWrong conclusion if skipped
Sender encryptsoutbound SA packet counter"the tunnel is up"
Peer receivesinbound SA counter and replay window"the peer is down"
Inner deliverytarget host or service logs"routing is broken"
Application repliesthe app's own trace"the reply was dropped"
Protected returnthe peer's outbound SA"ESP only works one way"

हरेक पङ्क्ति स्वतन्त्र रूपमा असफल हुन्छ र हरेक विफलताको फरक मालिक हुन्छ, त्यसैले एउटा क्याप्चरले तिनीहरूलाई छुट्याउन सक्दैन। आउने काउन्टर नै आइपुग्नेको एकमात्र प्रत्यक्ष प्रमाण हो, किनकि प्रमाणीकरण वा पुनरावृत्ति जाँचमा असफल हुने प्याकेट कुनै जवाफबिना फालिन्छ। त्यसैले आउने काउन्टर नसरेको साथीले तपाईंलाई आफ्नो नीतिबारे कुनै जानकारी दिँदैन।

पुर्याउनु डिक्रिप्शनबाट छुट्टै चरण हो। अवस्था मान्य हुन सक्छ र प्याकेट पछि आउने नीति वा आन्तरिक गन्तव्य समावेश नगर्ने मार्गले फाल्न सक्छ, त्यसैले सफा काउन्टरको अर्थ प्याकेट तपाईंले चाहेको ठाउँ गयो भनी मान्नुको सट्टा लक्ष्य होस्टले सादा पाठ देख्यो कि देखेन जाँच्नुहोस्।

मूल ESP UDP होइन

मूल ESP IP प्रोटोकल 50 हो, जो न TCP हो न UDP र यसको कुनै पोर्ट छैन। त्यसैले UDP 500 मा IKE लाई अनुमति दिने फायरवाल नियमले डाटा मार्गबारे केही भन्दैन, र पोर्टहरू वरिपरि लेखिएको फिल्टरले सुरुङलाई वार्ता गर्न दिएर त्यसभित्र बोकिएको सबै फाल्न सक्छ। डाटा मार्गलाई तपाईंले वास्तवमा अवलोकन गरेको मोडमा छुट्टै परीक्षण गर्नुहोस्।

NAT पछाडि आकार बदलिन्छ: सुरक्षित पेलोड UDP भित्र यात्रा गर्छ, सामान्यतया पोर्ट 4500 मा, जसरी RFC 3948 परिभाषित गर्छ। कुनै पनि नियम लेख्नु अघि सक्रिय मोड रेकर्ड गर्नुहोस्, किनकि मार्गमा रहेको यन्त्रले मूल ESP र UDP मा बेरिएको ESP लाई पूर्ण रूपमा फरक व्यवहार गर्न सक्छ, र केही बीचका बाकसमा एउटालाई अनुमति दिएर अर्को फाल्छन्।

यो घटनासँग सम्बन्धित काउन्टरहरू पढ्नुहोस्

strongSwan होस्टमा swanctl --list-sas ले दुवै दिशामा प्रत्येक एसोसिएसनको प्याकेट र बाइट काउन्टर रिपोर्ट गर्छ, जुन „कहिल्यै आएन“ लाई „आयो तर जवाफ दिइएन“ बाट छुट्याउन पर्याप्त छ। Linux मा /proc/net/xfrm_stat ले हराएको अवस्था, हराएको नीति र प्रोटोकल त्रुटिजस्ता समग्र विफलता गन्छ। ती जोडहरू बुटदेखि जम्मा हुन्छन् र एउटै सञ्जाल नामस्थानसँग सम्बन्धित हुन्छन्, त्यसैले ठूलो संख्या आरोप होइन।

सही नामस्थानमा घटनाको विन्डो वरपर दुई पठन लिनुहोस् र भिन्नताहरू तुलना गर्नुहोस्, नत्र गत हप्ताका त्रुटिहरू आज दिउँसोको टिकटमा जोड्नुहुनेछ। नामस्थान र दुवै समय-छापहरू टिकटमा राख्नुहोस् ताकि अर्को पाठकले जोडमा भर पर्नुको सट्टा तुलना दोहोर्याउन सकोस्।

चरणको नाम दिनुहोस्, शंकास्पदको होइन

उपयोगी निष्कर्षले प्याकेट कहाँ रोकियो भन्छ: कहिल्यै प्राप्त भएन, प्राप्त भयो र फालियो, पुर्याइयो तर जवाफ आएन, वा जवाफ दिइयो र फर्कने बाटोमा हरायो। यी प्रत्येकले फरक मालिक र फरक अर्को आदेशतर्फ सङ्केत गर्छ। „VPN सर्भरबाट कुनै जवाफ आएन“ ले चार फरक खराबीलाई क्याप्चरले कहिल्यै न्यायोचित नठहराएको एउटै वाक्यमा खुम्च्याउँछ।

क्याप्चरहरू साँघुरो राख्नुहोस्, र कर्नेलको कच्चा अवस्था टिकटहरूमा नराख्नुहोस्, किनकि यसले होस्ट छोड्नु नपर्ने कुञ्जी सामग्री बोक्न सक्छ। काउन्टरका भिन्नता र समय-छापहरू नै अर्को व्यक्तिलाई दिन लायक भागहरू हुन्।

सम्बन्धित लेखहरू