strongSwan में पूर्ण टनल के लिए दोनों ओर 0.0.0.0/0 चाहिए

एक निजी सबनेट के लिए काम करने वाला strongSwan कनेक्शन केवल इसलिए इंटरनेट ट्रैफ़िक नहीं ले जाएगा कि किसी ने एक पंक्ति संपादित कर दी। पूर्ण टनल दो पक्षों के बीच यह समझौता है कि child SA किन पतों की रक्षा करता है, और हर पक्ष दूसरे पक्ष को अपने सापेक्ष नाम देता है। एक ओर सही और दूसरी ओर ग़लत करें, तो child SA या तो ऊपर नहीं आएगा या इरादे से अधिक संकीर्ण आएगा। नीचे दी गई पाँच जाँचें उसी समझौते का क्लाइंट से गेटवे होते हुए इंटरनेट तक अनुसरण करती हैं।

पहले क्लाइंट का सिलेक्टर जाँचें

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

children {
    net {
        local_ts  = dynamic
        remote_ts = 0.0.0.0/0
    }
}

यह अंश पूरा कनेक्शन फ़ाइल नहीं है, और यह मानता है कि प्रमाणीकरण, पहचान और वर्चुअल पता-समूह पहले से कॉन्फ़िगर हैं। क्लाइंट का स्रोत सिलेक्टर और सर्वर द्वारा आवंटित पता अभी भी मेल खाना चाहिए, वरना child SA ऐसे दायरे के साथ आएगा जिसकी किसी पक्ष ने अपेक्षा नहीं की। इसे swanctl --load-all से लोड करें और सफलता मानने से पहले आउटपुट पढ़ें। जो फ़ाइल पार्स होती है वह अभी भी ऐसे सिलेक्टर के कारण अस्वीकार हो सकती है जो दूसरे पक्ष के प्रस्ताव से मेल नहीं खाता।

गेटवे का सिलेक्टर उसकी अपनी ओर जाँचें

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

children {
    rw {
        local_ts  = 0.0.0.0/0
        remote_ts = 10.77.0.0/24
    }
}

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

पुराना ipsec.conf अलग-अलग कुंजियों के साथ बाएँ और दाएँ भूमिकाएँ उपयोग करता है, और rightsubnet पंक्ति swanctl मान का सीधा विकल्प नहीं है। दोनों सिंटैक्स अलग फ़ाइलों में रखें, एक को दूसरे में चिपकाने के बजाय। दोनों को एक ही निर्देशिका में मिलाना ही वह तरीका है जिससे काम करने वाला कनेक्शन रीबूट के बाद चुपचाप पीछे हट जाता है।

फ़ाइल नहीं, बातचीत किया गया child SA जाँचें

सहेजा गया कॉन्फ़िगरेशन मंशा साबित करता है और बस इतना ही। दूसरा पक्ष माँगे गए दायरे को सीमित कर सकता है, और मौजूदा child SA केवल इसलिए नहीं बदला जाता कि उसके नीचे की फ़ाइल बदल गई। कुछ और बदलने से पहले पुष्टि करें कि वास्तव में क्या स्थापित है।

swanctl --list-conns
swanctl --list-sas
ip xfrm policy list

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

नीति सूची में दोनों दिशाएँ पढ़ें, क्योंकि एक दिशा स्थापित करने और दूसरी न करने वाला टनल कॉन्फ़िगरेशन के वेश में रूटिंग समस्या है। आगे और वापसी नीतियों को वही सिलेक्टर जोड़ी दर्पण रूप में नाम देना चाहिए, और गायब दर्पण सिलेक्टर टेक्स्ट में नहीं बल्कि डीमन या प्रस्ताव में दोष है।

फ़ॉरवर्डिंग और वापसी मार्ग जाँचें

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

sysctl net.ipv4.ip_forward
iptables -t nat -S | grep -i masq
ip route get 1.1.1.1

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

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

जाँचें कि टनल अभी भी क्या कवर नहीं करता

सिलेक्टर जोड़ी IPv4 कवर करती है और कुछ नहीं। IPv6, DNS और कोई भी अनुप्रयोग-स्तरीय नीति अलग निर्णय हैं जिन्हें चौड़ा IPv4 सिलेक्टर चुपचाप अनदेखा करता है। हर IPv4 पैकेट ले जाने वाला टनल अभी भी हर नाम खोज लीक कर सकता है।

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

resolvectl query intranet.example.internal
traceroute -n 1.1.1.1

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