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 क्यों है, बदलाव रिकॉर्ड में बैकअप का कारण जोड़ें। ज़रूरत पड़ने से पहले रोलबैक का अभ्यास करें।
अगर कोई चरण विफल हो, तो केवल उसी चरण को ठीक करें। ट्रांसपोर्ट समस्या के पीछे भागने के लिए साइफ़र सूट या पहचान सेटिंग बदलना आमतौर पर पहले के ऊपर दूसरी, असंबंधित विफलता जोड़ देता है।