TCP मा IKE 4500: पोर्ट नियम अघि दुवै छेउ जाँच्नुहोस्
TCP इन्क्याप्सुलेसन दुवै छेउले वार्ता गर्छन्, फायरवाल नियमले यो दिँदैन। लिसनर जाँच, क्याप्चर र चार स्वीकृति चरण क्रममा चलाउनुहोस्।
सहयोग टिकटहरू प्रायः तब आउँछन् जब फायरवाल परिवर्तन पहिले नै स्वीकृत भइसकेको हुन्छ र टनेल अझै माथि उठ्न मान्दैन। सुविधा एउटै छेउमा मात्र हुँदा यही अपेक्षित परिणाम हो: RFC 9329 अनुसार TCP इन्क्याप्सुलेसन दुवै छेउमा लागू र कन्फिगर गर्नुपर्छ, र कुनै पनि सुरक्षित ट्राफिक सर्नु अघि सहमति जडानभित्रै हुन्छ। पोर्ट खोल्नु भनेको नहुन सक्ने लिसनरको घोषणा गर्नु हो, र अर्को छेउमा मिल्ने कन्फिगरेसन नभएको लिसनरले जडान स्वीकार गरेर पछि चुप बस्छ। तलको क्रमले सस्ता जाँचहरूलाई अगाडि राख्छ।
विकल्पले वास्तवमा के थप्छ जान्नुहोस्
मूल IPsec ले इन्क्रिप्ट गरिएका पेलोडहरू यसरी बोक्छ: IP प्रोटोकल 50, अनुमति दिनुपर्ने कुनै पोर्ट नम्बर बिना। NAT ट्राभर्सलले ती प्याकेटहरूलाई UDP मा बेरेर पोर्ट 4500 मा पठाउँछ, र त्यसैले धेरै फायरवाल नियमहरूले त्यो पोर्ट उल्लेख गर्छन्। RFC 9329 ले स्ट्रिम प्रस्तुति थप्छ: IKE र IPsec प्याकेट दुवै एउटै TCP जडानभित्र, सामान्यतया पोर्ट 4500 मा यात्रा गर्छन्।
स्ट्रिम वेब सेवा होइन। 4500 मा TCP जडानले HTTP, TLS वा प्रोक्सी-मैत्रीपूर्णताबारे केही भन्दैन, र बाटोमा रहेको HTTP प्रोक्सीले सामान्यतया बोक्नुको सट्टा फ्रेमिङ तोड्छ।
फायरवाल छुनु अघि पूर्व-जाँच
मानकले TCP लाई UDP मार्ग छोड्ने नेटवर्कहरूका लागि ब्याकअपका रूपमा राख्छ, यसको विकल्पका रूपमा होइन। प्रत्येक विक्रेताबाट दुई तथ्य लिनुहोस्: सुविधाको ठ्याक्कै नाम र स्वामित्वको प्रकारको सट्टा RFC 9329 लागू गर्ने संस्करण। IPsec over TCP जस्ता लेबल असम्बन्धित डिजाइनका लागि प्रयोग भएका छन्, त्यसैले कागजात सन्दर्भ र यसलाई खोल्ने कन्फिगरेसन कुञ्जी माग्नुहोस्। दुवै उत्तर बिना तार अनुकूलताबारे केही मान्नु हुँदैन।
दुवै छेउ तपाईंका हुने प्रयोगशालामा यो प्रमाणित गर्नुहोस्। TCP 4500 मा जवाफ दिने तर IKE कहिल्यै पूरा नगर्ने गेटवे अर्को छेउमा मिल्ने इन्क्याप्सुलेसन नभएको लिसनरको संकेत हो, र त्यहाँ पत्ता लगाउनु परिवर्तन विन्डोको क्रममा पत्ता लगाउनुभन्दा धेरै सस्तो हुन्छ।
प्रतिक्रियाकर्तामा: केही सुनिरहेको छ
सकेटबाट सुरु गर्नुहोस्। ss -ltnp | grep 4500 ले TCP लिसनर छ कि छैन र कुन प्रक्रियाले यसको स्वामित्व लिएको छ देखाउँछ। लाइन नहुनुले अन्वेषणलाई नेटवर्कमा होइन, गेटवे कन्फिगरेसनमा अन्त्य गर्छ।
सकेट भएमा, ग्राहक पक्षबाट अनुमान गर्नुको सट्टा ह्यान्डसेक हेर्नुहोस्: tcpdump -ni any 'tcp port 4500'। पूरा भएको तीन-तर्फी ह्यान्डसेकपछि मौनता भनेको स्ट्रिम स्वीकार भयो र भित्रको IKE आदानप्रदान असफल भयो, जबकि जवाफ नभएको SYN ले फिल्टरिङ वा गलत ठेगानातर्फ संकेत गर्छ।
दुवै नमिसियोस् भन्नका लागि त्यही क्याप्चर विन्डोमा UDP मार्गसँग तुलना गर्नुहोस्: tcpdump -ni any 'udp port 4500 or proto 50'। TCP प्रयोग भइरहेको छ भन्ने तपाईंलाई लाग्दा प्रोटोकल 50 वा UDP पोर्ट 4500 मा ट्राफिक हुनु भनेको दुवै छेउ ब्याकअपमा कहिल्यै सहमत भएनन्। सम्भव भएमा गेटवेमा पनि क्याप्चर गर्नुहोस्, किनकि ग्राहक-पक्षको क्याप्चरले टाढाको छेउले के पठायो देखाउन सक्दैन।
चार अलग चरणमा स्वीकार गर्नुहोस्
उठ्ने क्रमलाई चार नतिजाका रूपमा लिनुहोस्। प्रत्येक फरक कारणले असफल हुन सक्छ, र एउटै पास वा फेलले कुन थियो भन्ने लुकाउँछ, त्यसैले असफल हुने पहिलो चरणमा रोक्नुहोस् र फेरि माथिबाट सुरु गर्नुहोस्।
| Stage | What you check | What it proves |
|---|---|---|
| 1 | TCP connection established to 4500 | A listener exists and the path permits it |
| 2 | IKE_SA authenticated in the gateway log | Both peers agreed on the encapsulation |
| 3 | CHILD_SA installed, visible with ip xfrm state | Keys exist for the protected traffic |
| 4 | A new application exchange succeeds | The data path works, not just the control path |
चौथो चरण त्यो हो जुन छोडिन्छ। विद्यमान सत्र क्यास गरिएको अवस्थामा काम गरिरहन सक्छ, त्यसैले परिवर्तन बन्द गर्नु अघि गेटवेपछाडिको होस्टमा नयाँ जडान खोल्नुहोस्। दोस्रो चरण असफल भई पहिलो पास भएमा, मतभेद प्रस्ताव वा इन्क्याप्सुलेसन सेटिङमा छ, फायरवालमा होइन।
रोलब्याक, र यसलाई खुला राख्ने लागत
परिवर्तनअघि पूर्ववत गर्ने योजना बनाउनुहोस्: दुवै छेउमा इन्क्याप्सुलेसन विकल्प बन्द गर्नुहोस् र टनेल UDP मार्फत फर्किएको पुष्टि गर्नुहोस्। ब्याकअप फेरि आवश्यक परे एक समीक्षा चक्रका लागि TCP नियम राख्नुहोस्, त्यसपछि हटाउनुहोस्। 4500 मा अप्रयुक्त लिसनर कुनै पनि सञ्चालन मूल्य नभएको सतह हो।
वास्तविक काम बोक्न थालेपछि प्रदर्शनको संकेत हेर्नुहोस्। TCP भित्रको TCP एउटै हानिमा रोकिने स्वीकृति तहहरू थप्छ, र एउटै जडान साझा गर्ने स्ट्रिमहरूले एकअर्कालाई रोक्न सक्छन्, त्यसैले ping नभई टनेल प्रयोग गर्ने अनुप्रयोग मापन गर्नुहोस्।
स्वीकृति सूची
दुवै छेउमा सुविधाको नाम र संस्करण, प्रतिक्रियाकर्तामा लिसनर, पूरा ह्यान्डसेक देखाउने क्याप्चर, र समय-छापसहित अभिलेख गरिएका चार चरण पुष्टि गर्नुहोस्। अर्को इन्जिनियरले TCP किन छ भन्ने जान्न परिवर्तन अभिलेखमा ब्याकअपको कारण थप्नुहोस्। आवश्यक पर्नु अघि रोलब्याक अभ्यास गर्नुहोस्।
कुनै पनि चरण असफल भएमा त्यही चरण मात्र सुधार्नुहोस्। यातायात समस्याको पछि लाग्न साइफर सूट वा पहिचान सेटिङ बदल्नुले सामान्यतया पहिलोमाथि दोस्रो, असम्बन्धित असफलता थप्छ।