XFRM चा डीफॉल्ट रूट IKE आणि ESP गिळून टाकले: बाहेरील मार्ग ठेवा

ट्रॅफिक संरक्षित आहे, टनल सुरू आहे, आणि मग पुढील की नूतनीकरणात ते मरते। XFRM इंटरफेसवरून जाणारा डीफॉल्ट रूट तुम्हाला संरक्षित करायचा असलेल्या ट्रॅफिकचे वर्णन करत होता। त्याने संरक्षण सुरू ठेवण्यासाठी आवश्यक पॅकेटही गिळून टाकली।

सहभागी दोन गंतव्ये अदलाबदल करण्यायोग्य नाहीत। राउटिंगने ते स्पष्ट सांगितले पाहिजे।

पीअरचा शोध प्रत्यक्षात कुठे जातो

सक्रिय नियम, XFRM रूट असलेले तक्ते आणि पीअरचा सार्वजनिक पत्ता नोंदवा। नंतर बाहेरील कनेक्शन त्याच्या खऱ्या स्रोत आणि मार्कसह कोणता मार्ग घेईल ते पाहा। सामान्य गंतव्य त्या नियंत्रण मार्गाबद्दल काहीही सांगत नाही। फक्त खरा स्रोत आणि मार्क उपयुक्त उत्तर देतात।

यशस्वी प्रारंभिक कनेक्शनही फारसे सिद्ध करत नाही। रूट इंस्टॉलेशनने उत्तर बदलल्यानंतर अपयश अनेकदा दिसते। सुरुवात यशस्वी होते, मग पहिले नूतनीकरण होत नाही।

ip rule show
ip route show table 220
ip -4 route get 198.51.100.44 from 10.40.0.2
ip xfrm policy list

पीअरचा शोध XFRM इंटरफेसमध्ये गेला तर बाहेरील पॅकेट ते स्वतः तयार करत असलेल्या टनलमध्ये राउट होतात। हाच लूप, एका कमांडमध्ये दिसतो।

आधुनिक गेटवेवर वगळण्याचे पर्याय

strongSwan चे रूट-आधारित VPN वरील दस्तऐवज दोन व्यावहारिक उत्तरे देतात। एक IKE आणि ESP चिन्हांकित करते जेणेकरून XFRM तक्त्याकडे निर्देश करणारा नियम त्यांना लागू होणार नाही। दुसरे पीअरचा मार्ग किंवा वगळणे ठेवते जिथे शोध अजून पोहोचू शकतो।

तुमचा नियमसंच दुष्परिणामांशिवाय व्यक्त करू शकेल ते निवडा। स्टॅकचा उर्वरित भाग आधीच मार्क वापरत असेल तर मार्क स्वच्छ असतो। तोच मास्क दुसऱ्या नियमात दुसरे काही अर्थ देत असेल तर तो धोका आहे। दोन्ही प्रकारच्या पॅकेटांना तसेही हे उपचार आवश्यक आहेत।

फक्त IKE चिन्हांकित केल्यास डेटा पॅकेट पकडलेल्या मार्गावरच राहतात। त्यामुळे हँडशेक करून नंतर काहीही न वाहणारी टनल तयार होते।

मार्क म्हणजे पॅकेटच्या fwmark मधला गेटवेवर इतर कोणीही दावा न करणारा एक बिट: मास्क 0x1 सह 0x1 ही नेहमीची निवड आहे, आणि वगळणे कार्य करण्यासाठी तो दोन ठिकाणी सेट करावा लागतो। Charon ला तो IKE सॉकेटवर लागतो, आणि चाइल्ड कनेक्शनच्या इनबाउंड व आउटबाउंड मार्क सेटिंग्जना तेच मूल्य लागते जेणेकरून एन्कॅप्सुलेटेड पॅकेटही मार्क होऊन बाहेर पडतील। 0xffffffff ऐवजी 0x1 मास्क उर्वरित बिट मोकळे ठेवतो, जे त्याच होस्टवर दुसरे सबसिस्टम आधीच पॅकेट मार्क करत असेल तेव्हा महत्त्वाचे ठरते। दोन्ही सेट केल्यावर नियम वगळणे म्हणून लिहिला जातो, त्यामुळे मार्क केलेले पॅकेट XFRM रूट असलेले तक्ते वगळून मुख्य तक्त्यात पडतात:

ip rule add not fwmark 0x1/0x1 lookup 220 pref 1000
ip -4 route get 198.51.100.44 from 10.40.0.2 mark 0x1

नंतर मार्क लागू करून उत्तर वाचा। त्याशिवाय तुम्ही संरक्षित ट्रॅफिक ज्या मार्गाने जाते त्याची तपासणी करता, जे या विभागाच्या प्रश्नाच्या उलट आहे।

स्वयंचलित इंस्टॉलेशन बिल्डबद्दल काय गृहीत धरते

XFRM इंटरफेससाठी स्वयंचलित रूट इंस्टॉलेशन strongSwan आवृत्ती आणि तिच्या कॉन्फिगरेशनवर अवलंबून आहे। इंटरफेस ID, इंस्टॉल केलेले धोरण आणि असोसिएशन—सर्वांनी इच्छित ऑब्जेक्ट्सना संदर्भ द्यावा। विसंगती अशा रूटच्या रूपात दिसते जो शांतपणे कुठेतरी खऱ्या ठिकाणाकडे निर्देश करतो।

दुसऱ्या गेटवेवरून तक्ता क्रमांक किंवा मार्क मास्क कॉपी करणे हीच टकरी सुरू होण्याची पद्धत आहे। आधी ते आधीच काय वापरत आहे ते तपासा। टकरी तुम्ही बदलू इच्छित असलेल्या टनलच्या खूप पुढील ट्रॅफिकवर परिणाम करते, आणि लक्षण क्वचितच कॉपीकडे निर्देश करते।

पीअरच्या पत्त्यातील बदल डिझाइनचा भाग आहेत। कालच्या पत्त्यासाठीचा होस्ट रूट हा एंडपॉइंट पुनर्प्राप्तीचा आराखडा नाही, तर मार्क तो बदल टिकून राहतो।

पहिल्या नूतनीकरणावर लक्ष ठेवा

संरक्षित रूट इंस्टॉल झाल्यानंतर बाहेरील मार्ग तपासा, आधी नाही। नंतर पुढील नूतनीकरण आणि एका अनुप्रयोगाच्या देवघेवीवर लक्ष ठेवा। अपयश सामान्यतः त्या संक्रमणात दिसते, सुरुवातीला नाही।

ip -4 route get 198.51.100.44
sudo swanctl --list-sas
sudo tcpdump -ni any 'udp port 500 or esp'

संरक्षित डीफॉल्ट तात्पुरता काढल्यास सामान्यतः कनेक्टिव्हिटी परत येते। तो निकाल निदानात्मक आहे, अंतिम नाही।

ध्येय म्हणजे आतील ट्रॅफिक आणि ते वाहणाऱ्या बाहेरील पॅकेटांमधील स्थिर विभाजन। निवडलेली यंत्रणा आणि तिचे तक्ते किंवा मार्क गेटवेच्या नोंदींमध्ये लिहा। अन्यथा नियमांना हात लावणारी पुढील व्यक्ती लूप पुन्हा आणेल।