IKEv2 क्लाइंट तक उसके आवंटित वर्चुअल IP पर पहुँचना

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

टनल स्रोत पता ठीक नहीं करती

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

क्लाइंट की ओर रूटिंग ज़रूरी है और पर्याप्त नहीं है। नीति को उस स्रोत को स्वीकार करना होगा जिसे आपने वास्तव में इस्तेमाल किया।

इंस्टॉल की गई नीति पढ़ें, कॉन्फ़िग फ़ाइल नहीं

सक्रिय एसोसिएशन और उसके सिलेक्टरों से शुरू करें, क्योंकि गतिशील आवंटन बदल देता है कि कर्नेल में क्या इंस्टॉल है।

ipsec statusall
ip xfrm policy

स्थिति का आउटपुट कनेक्शन, आवंटित वर्चुअल पता और उस पीयर के लिए अभी लागू सिलेक्टरों के नाम बताता है। नीति का डंप वही सिलेक्टर कर्नेल स्थिति के रूप में दिखाता है, और पैकेट चयन वास्तव में उसी से सलाह लेता है। गेटवे पक्ष के सिलेक्टर की तुलना उस स्रोत से करें जिसका आपका एप्लिकेशन इस्तेमाल करेगा, क्योंकि बेमेल विफलता को तुरंत समझा देता है। क्लाइंट का मौजूदा पता पढ़ें, पिछले सत्र का नहीं, क्योंकि फिर से आवंटित VIP पुरानी नीति को अमान्य कर देता है।

क्लाइंट को वहीं सुनना चाहिए जहाँ पैकेट पहुँचता है

सही नीति भी बंद पोर्ट तक पहुँचती है जब सेवा केवल लूपबैक से बँधी हो। श्रोता को आवंटित पते पर या किसी वाइल्डकार्ड स्थानीय पते पर होना चाहिए।

ss -ltnp 'sport = :9090'
iptables -S INPUT

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

नई दिशा को अलग से जाँचें

क्लाइंट-से-सर्वर सफल अनुरोध इस रास्ते को कभी नहीं आज़माता। अनुरोध गेटवे से बनाएँ और दोनों सिरों को देखें।

ip route get 10.90.0.42 from 192.168.50.1
tcpdump -ni any host 10.90.0.42 and tcp port 9090

रूट लुकअप बताता है कि गेटवे कौन-सा स्रोत और इंटरफ़ेस इस्तेमाल करेगा, और नीति को यही मान स्वीकार करना होगा। कैप्चर में अनुरोध सार्वजनिक इंटरफ़ेस पर सादे TCP के बजाय ESP के भीतर निकलता दिखना चाहिए। क्लाइंट पर, पहुँच और सेवा के उत्तर की पुष्टि के लिए डिक्रिप्ट किया गया ट्रैफ़िक कैप्चर करें। अगर अनुरोध बिना ESP के तार पर गायब हो जाए, तो क्लाइंट के फ़ायरवॉल से पहले स्रोत पते पर संदेह करें।

कुंजी बदलने या दोबारा कनेक्ट होने के बाद परीक्षण दोहराएँ, क्योंकि VIP बदल सकता है। जो रास्ता केवल अगले सत्र तक काम करे वह काम करने वाला रास्ता नहीं है।