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'

संरक्षित डिफ़ॉल्ट को अस्थायी रूप से हटाने से आमतौर पर कनेक्टिविटी लौट आती है। वह परिणाम नैदानिक है, अंतिम नहीं।

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