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 बदलू शकतो। फक्त पुढील सत्रापर्यंत कार्य करणारा मार्ग कार्यशील मार्ग नाही।