IKEv2 UDP 500 और 4500 का उपयोग करता है: डेटा कौन सा पोर्ट ढोता है?

फ़ायरवॉल में UDP 500 खोलने से सुरंग बातचीत कर पाती है, और फिर कनेक्शन ट्रैफ़िक भेजना बंद कर देता है। पोर्ट की सूची अधूरी थी, ग़लत नहीं। IKEv2 एक सॉकेट पर शुरू होता है और कई वास्तविक परिनियोजनों में दूसरे पर जारी रहता है, जबकि पेलोड पोर्ट ही न हो। चरणों को क्रम में पढ़ने से समझ आता है कि कौन सा नियम गायब है।

दो पोर्ट, दो काम

IKEv2 UDP 500 पर कुंजी के आदान-प्रदान से शुरू होता है, जहाँ दोनों पक्ष प्रमाणित होते हैं और सुरंग के लिए सुरक्षा संबंध स्थापित करते हैं। इसके बाद का डेटा पथ अलग बात है: यह मूल ESP हो सकता है, जो पोर्ट नहीं बल्कि IP प्रोटोकॉल संख्या है, या 4500 पर UDP में लिपटा ट्रैफ़िक। फ़ायरवॉल समीक्षा में इन्हें अलग रखना ही बातचीत करने वाली सुरंग और काम करने वाली सुरंग का अंतर है। एक सॉकेट नियंत्रण ढोता है और दूसरा पेलोड।

इसलिए केवल 500 की अनुमति देने वाला नियम पूरे प्रोटोकॉल परिवार में सबसे उलझाने वाला लक्षण पैदा करता है: बातचीत सफल होती है और कोई उपयोगी चीज़ नहीं होती। स्थिति एक साथी दिखाती है, लॉग स्थापित IKE SA दिखाता है, और ऐप फिर भी समय-समाप्त होता है। गायब अनुमति उस प्रवाह की है जो अभी सफल हुआ, से भिन्न है।

4500 आख़िर क्यों मौजूद है

कई NAT उपकरण TCP या UDP के अलावा कोई प्रोटोकॉल आगे नहीं भेज सकते, और कुछ पते ऐसे फिर से लिखते हैं जिससे ESP की अखंडता जाँच टूट जाती है। ESP को UDP के भीतर लपेटना दोनों समस्याएँ हल करता है, पर अतिरिक्त हेडर और अनुमति देने योग्य दूसरे पोर्ट की कीमत पर। यही लपेट दूसरे पोर्ट के होने का कारण है।

NAT का पता चलते ही IKE स्वयं भी 4500 पर चला जाता है ताकि सारा ट्रैफ़िक अनुवादक से होकर एक ही पथ साझा करे। चार बाइट का एक गैर-ESP चिह्न उस सॉकेट पर नियंत्रण संदेशों को डेटा से अलग करता है। यह बदलाव प्रोटोकॉल का निर्णय है, प्रशासक की पसंद नहीं।

स्रोत पोर्ट कहाँ बदलता है

अनुवादक क्लाइंट का स्रोत पोर्ट फिर से लिख सकता है, इसलिए सर्वर पर दिखने वाला टपल क्लाइंट के टपल से मेल नहीं खाता। किसी नियम के अनदेखा होने का निष्कर्ष निकालने से पहले हर NAT हॉप के दोनों ओर देखें। केवल क्लाइंट पर समस्या ढूँढने से ऐसा नियम मिल सकता है जो सही दिखे और फिर भी विफल हो।

MOBIKE-सक्षम क्रियान्वयन NAT पहचाने बिना भी 4500 पर जा सकते हैं, और कुछ परिनियोजन जानबूझकर उस पथ को थोपते हैं। इसलिए 4500 देखना निर्णय का साक्ष्य है, घरेलू राउटर का प्रमाण नहीं।

हर सीमा पर दोनों प्रवाह जाँचें

तीन सीमाओं से गुज़रें: क्लाइंट नेटवर्क, कोई भी मध्यवर्ती फ़ायरवॉल और सर्वर। हर एक को वही प्रवाह चाहिए जो परिनियोजन दस्तावेज़ित करता है, किसी दूसरे मामले के लेख के प्रवाह नहीं।

sudo swanctl --list-sas
sudo tcpdump -ni any 'udp port 500 or udp port 4500'
sudo iptables -S | grep -E '500|4500|esp'
ip xfrm state

फ़ायरवॉल सूची में ESP पंक्ति एक प्रोटोकॉल मिलान है, इसलिए पोर्ट नियम उसे कभी नहीं ढकता। यदि ऑपरेटर कस्टम पोर्ट उपयोग करता है, तो दोनों सिरों पर दस्तावेज़ित कॉन्फ़िगरेशन का पालन करें, क्योंकि क्लाइंट जाना-पहचाना नंबर चुनकर सर्वर पर श्रोता नहीं बना सकता।

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