सुरंग दफ़्तर के नेटवर्क पर चलती थी और घर पर अटक जाती है, और लॉग दिखाता है कि पहला आदान-प्रदान बाकी कुछ होने से पहले पूरा हो जाता है। यह पैटर्न प्रमाणीकरण के आदान-प्रदान की ओर इशारा करता है, क्रेडेंशियल की ओर नहीं: सर्टिफ़िकेट श्रृंखला उस संदेश को पिछले से कहीं बड़ा बना देती है, और बड़े डेटाग्राम पसंद न करने वाला मार्ग उसे चुपचाप गिरा देगा। इसमें दो अलग-अलग फ्रैगमेंटेशन तंत्र शामिल हैं, और यह जानना कि आप किसे देख रहे हैं, समाधान तय करता है।

दो फ्रैगमेंटेशन तंत्र, एक लक्षण

IKEv2 का अपना फ्रैगमेंटेशन एक्सटेंशन है, जो RFC 7383 में परिभाषित है और सुरक्षित IKE संदेशों को छोटे IKE संदेशों में बाँटता है। दोनों पक्ष उस क्षमता पर बातचीत करते हैं, और संदेश को IP परत के बजाय IKE कार्यान्वयन फिर से जोड़ता है।

साधारण IP फ्रैगमेंटेशन अलग विफलता-विधि वाला दूसरा तंत्र है। दोनों पक्षों के बीच का राउटर बड़े डेटाग्राम को विखंडित करता है, या उसे गिराकर ऐसा ICMP संदेश लौटाता है जो शायद प्रेषक तक कभी न पहुँचे। कुछ नेटवर्क खंडों को चुपचाप त्याग देते हैं, और कुछ मध्यवर्ती उपकरण पहले खंड को संभालते हैं पर बाकी को नहीं। एप्लिकेशन की दृष्टि से तीनों स्थितियाँ एक जैसी दिखती हैं।

NAT ट्रैवर्सल तीसरा चर जोड़ता है, क्योंकि तब ESP को UDP में लपेटा जाता है और बाहरी पैकेट बड़ा हो जाता है जबकि वह पोर्ट 4500 पर साधारण UDP ट्रैफ़िक जैसा दिखता है। UDP को अच्छी तरह पार कराने वाला मार्ग भी ऐसे डेटाग्राम पर विफल हो सकता है जो अब सिमटता नहीं।

विफल हुआ आदान-प्रदान पढ़ें

त्रुटि के बजाय संक्रमण खोजें। ऐसा लॉग जो दिखाता है कि आरंभिक आदान-प्रदान भेजा और उत्तरित हुआ, और उसके बाद कुछ नहीं, आपको बताता है कि अगला संदेश कभी पूरा नहीं हुआ। लॉग स्तर अस्थायी रूप से बढ़ाएँ और दोनों पक्षों पर बताए गए आकारों की तुलना करें।

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

मार्ग बदलें, सर्टिफ़िकेट नहीं

वही क्लाइंट, वही सर्टिफ़िकेट और वही कॉन्फ़िगरेशन किसी दूसरे नेटवर्क से जाँचें। मोबाइल हॉटस्पॉट आमतौर पर सबसे सस्ता दूसरा मार्ग होता है, और वह दफ़्तर के लिंक से सचमुच अलग है, सिर्फ़ नाम का अलग नहीं।

यदि दूसरे मार्ग पर हैंडशेक पूरा होता है, तो सर्टिफ़िकेट श्रृंखला ठीक है और पहला मार्ग चर है। यदि दोनों पर एक जैसा विफल हो, तो नेटवर्क जाँचना बंद करें और संदेशों को ही देखें। वह एक तुलना संभावित व्याख्याओं का लगभग आधा हटा देती है।

कुछ भी संपादित करने से पहले आदान-प्रदान मापें

श्रृंखला का आकार और मार्ग का आकार प्राप्त करें। दोनों संख्याएँ सीमित करती हैं कि हैंडशेक क्या भेज सकता है, और दोनों को मापना सस्ता है:

openssl crl2pkcs7 -nocrl -certfile chain.pem | openssl pkcs7 -print_certs -noout | grep -c subject
ls -l chain.pem
ping -M do -s 1400 198.51.100.7
ip -s link show eth0 | sed -n '1,6p'

पहले दो सर्टिफ़िकेट की संख्या और फ़ाइल का आकार देते हैं, जो इस बात का उचित संकेतक है कि प्रमाणीकरण संदेश कितना बड़ा होगा। ping जाँच बताती है कि उस आकार का डेटाग्राम मार्ग पर टिकता है या नहीं, और इंटरफ़ेस काउंटर दिखाते हैं कि आपके छोर पर खंड गिराए गए या नहीं। Windows पर समतुल्य जाँच do-not-fragment ध्वज और स्पष्ट पेलोड आकार वाली ping है।

सफल होने तक जाँच को नीचे की ओर दोहराएँ। जो सबसे बड़ा आकार पार होता है वही उस मार्ग का कार्यशील बजट है, और यह किसी भी प्रकाशित डिफ़ॉल्ट से अधिक उपयोगी है।

जो परत सचमुच टूटी है उसे ठीक करें

यदि मार्ग बड़े डेटाग्राम गिराता है, तो दोनों पक्षों पर IKE फ्रैगमेंटेशन चालू करें और पुष्टि करें कि एक्सटेंशन पर बातचीत हुई है, केवल प्रस्ताव नहीं दिया गया। यदि मार्ग IP स्तर पर खंडों को खराब संभालता है, तो सुधार वहीं या बाहरी इंटरफ़ेस के MTU में है, सर्टिफ़िकेट भंडार में नहीं।

यदि श्रृंखला बेवजह लंबी है, तो इसे उन मध्यवर्ती सर्टिफ़िकेट तक छोटा करें जिनकी किसी पक्ष को सचमुच ज़रूरत है। जिस रूट पर क्लाइंट पहले से भरोसा करता है उसे हटाना उचित रखरखाव है; मध्यवर्ती को हटाना नहीं, और संदेश छोटा करने के लिए सत्यापन बंद करना पहुँचाने की समस्या को सुरक्षा की समस्या से बदल देता है।

लिख लें कि कौन-सा तंत्र बदला और उसके बाद हैंडशेक कैसा दिखा। अगली घटना आमतौर पर उसी लक्षण के साथ किसी दूसरे नेटवर्क पर होती है, और नोट ही दो घंटे को दस मिनट में बदलता है।

संबंधित लेख