बिना उत्तर वाला आउटबाउंड ESP यह नहीं कहता कि VPN मर चुका है
ESP प्रति एसोसिएशन एक दिशा की रक्षा करता है और कुछ स्वीकार नहीं करता। सर्वर को अप्रतिक्रियाशील कहने से पहले आंतरिक बातचीत और इनबाउंड SA को मिलाएँ।
आपने IPsec होस्ट पर ट्रैफ़िक कैप्चर किया, ESP पैकेट जाते देखे, कुछ लौटते नहीं देखा और निष्कर्ष निकाला कि दूर का पक्ष खराब है। कैप्चर उस निष्कर्ष का समर्थन नहीं करता। ESP बातचीत की एक दिशा की रक्षा करता है और IP परत पर कुछ स्वीकार नहीं करता, इसलिए लौटने वाला ESP न होना उतनी ही आसानी से यह भी कह सकता है कि ऐप्लिकेशन के पास कहने को कुछ नहीं था, जितना आसानी से यह कि सुरंग मर चुकी है। किसी भी सिरे को दोष देने से पहले आंतरिक अदला-बदली और प्राप्ति पक्ष की स्थिति पढ़ें।
मिथक: हर संरक्षित पैकेट उत्तर का हकदार है
ESP अनुरोध-उत्तर प्रोटोकॉल नहीं है। यह वह सब एन्क्रिप्ट और प्रमाणित करता है जो नीति चुनती है, और प्राप्तकर्ता बिना अपना पैकेट बनाए उस आंतरिक पैकेट को सत्यापित, डिक्रिप्ट और वितरित करता है। जिस UDP क्वेरी को गंतव्य अनदेखा करता है, या जिस ICMP प्रतिध्वनि को इनबाउंड नीति छोड़ देती है, वे सही परिणाम के रूप में दोनों दिशाओं में मौन उत्पन्न करते हैं। उस मौन को परिवहन विफलता मानना आपको ऐसी नेटवर्क गड़बड़ी खोजने भेजता है जो कभी थी ही नहीं।
एकदिश कैप्चर वास्तव में यही सिद्ध करता है कि प्रेषक का स्टैक उस अवलोकन बिंदु पर कुछ एन्क्रिप्ट कर चुका है। आगमन के बारे में कुछ नहीं, और उत्तर देने के इरादे के बारे में भी कुछ नहीं। उपयोगी प्रश्न "उत्तर क्यों नहीं है" नहीं, बल्कि "आंतरिक बातचीत को क्या उत्पन्न करना चाहिए था" है।
दो SA, दो SPI, एक बातचीत
IPsec सुरक्षा एसोसिएशन एकदिशीय हैं, इसलिए सामान्य संरक्षित अदला-बदली में अलग पहचानकर्ताओं और स्वतंत्र स्थिति वाली इनबाउंड और आउटबाउंड एसोसिएशन होती हैं। इसलिए आउटबाउंड पैकेट के SPI के लिए लौटने वाला ट्रैफ़िक खोजना श्रेणीगत भूल है, क्योंकि कोई भी उत्तर साथी की अपनी आउटबाउंड SA के अंतर्गत अपने ही SPI के साथ जाता है। इसके बजाय जोड़ी को ट्रैफ़िक चयनकर्ताओं और साथी के पतों से मिलाएँ।
कुंजी पुनर्जनन एक बार में कुछ सेकंड के लिए चित्र को जटिल बना देता है, क्योंकि पुरानी और प्रतिस्थापन स्थिति ओवरलैप कर सकती हैं। यदि लक्षण किसी कुंजी पुनर्जनन के आसपास शुरू हुआ हो, तो केवल कनेक्शन का नाम नहीं, एसोसिएशन पहचानकर्ता और समय-चिह्न एक साथ इकट्ठा करें।
कुछ भी उत्तर देने से पहले प्राप्तकर्ता को क्या करना है
| Stage | What to look at | Wrong conclusion if skipped |
|---|---|---|
| Sender encrypts | outbound SA packet counter | "the tunnel is up" |
| Peer receives | inbound SA counter and replay window | "the peer is down" |
| Inner delivery | target host or service logs | "routing is broken" |
| Application replies | the app's own trace | "the reply was dropped" |
| Protected return | the 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 सर्वर से कोई प्रतिक्रिया नहीं" चार अलग-अलग खराबियों को एक वाक्य में दबा देता है जिसे कैप्चर ने कभी उचित नहीं ठहराया।
कैप्चर संकीर्ण रखें, और कच्ची कर्नेल स्थिति टिकटों से बाहर रखें, क्योंकि वह ऐसी कुंजी सामग्री ले जा सकती है जिसे होस्ट से बाहर जाने का कोई काम नहीं है। काउंटरों के अंतर और समय-चिह्न वही हिस्से हैं जो अगले व्यक्ति को देने लायक हैं।