दिइएको भर्चुअल IP मा IKEv2 क्लाइन्टसम्म पुग्ने

गेटवेले 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 फेरिन सक्छ। अर्को सत्रसम्म मात्र काम गर्ने मार्ग काम गर्ने मार्ग होइन।