IKEv2 फ्र्याग्मेन्टेसनलाई प्रमाणपत्र चेनको समस्याबाट छुट्याउने

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

दुई फ्र्याग्मेन्टेसन संयन्त्र, एउटा लक्षण

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 मा पर्छ, प्रमाणपत्र भण्डारमा होइन।

यदि चेन अनावश्यक रूपमा लामो छ भने, त्यसलाई पक्षलाई साँच्चै आवश्यक पर्ने मध्यवर्ती प्रमाणपत्रसम्म छोट्याउनुहोस्। क्लाइन्टले पहिले नै विश्वास गर्ने रुट हटाउनु उचित मर्मत हो; मध्यवर्ती हटाउनु त्यस्तो होइन, र सन्देश सानो बनाउन प्रमाणीकरण बन्द गर्नुले पुर्‍याउने समस्यालाई सुरक्षा समस्यासँग साट्छ।

कुन संयन्त्र बदल्नुभयो र त्यसपछि ह्यान्डसेक कस्तो देखियो लेख्नुहोस्। अर्को घटना सामान्यतया त्यही लक्षणसँग अर्को सञ्जालमा हुन्छ, र त्यही टिप्पणीले दुई घण्टालाई दस मिनेट बनाउँछ।