strongSwan ESP-in-UDP: जब खोजने के लिए कोई NAT न हो

NAT पहचान पता अनुवाद ढूँढती है, फ़ायरवॉल नीति नहीं। NAT के बिना एक साइट कनेक्शन को फिर भी स्पष्ट ESP-in-UDP चुनाव की ज़रूरत हो सकती है।

NAT पहचान एक ही सवाल का जवाब देती है: क्या रास्ते में पते या पोर्ट बदले? यह नहीं बताती कि कोई फ़ायरवॉल IP प्रोटोकॉल 50 को अनुमति देता है या नहीं। बिना किसी अनुवाद वाले साइट गेटवे अब भी ऐसी नीति के पीछे हो सकते हैं जो native ESP को गिरा देती है, और वह आवश्यकता खोजी नहीं, कॉन्फ़िगर की जानी चाहिए। तंत्र ESP-in-UDP है, और यह एक निर्णय है, अपने आप आने वाला विकल्प नहीं।

पहचान पतों पर अंकगणित है, फ़ायरवॉल प्रोब नहीं

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

व्यावहारिक परिणाम सीधे कहना उचित है। native ESP के साथ चलने वाली सुरंग नई प्रतिबंधक फ़ायरवॉल को अपने आप नहीं खोजेगी, और IKE के सफल होते रहने पर भी उसका अगला प्रयास डेटा चरण में विफल हो जाएगा। आप स्थापित IKE सुरक्षा संबंध देखेंगे और कोई संरक्षित ट्रैफ़िक नहीं, जो तार पर कैप्चर करने तक राउटिंग दोष जैसा लगता है।

इसलिए एनकैप्सुलेशन उस कनेक्शन का गुण है जिसे आप कॉन्फ़िगर करते हैं, न कि वह परिणाम जिस पर पक्ष नेटवर्क के व्यवहार से बातचीत करते हैं।

encap आदान-प्रदान को कैसे बदलता है

आधुनिक strongSwan परिनियोजन में, जो swanctl.conf के माध्यम से प्रबंधित होता है, कनेक्शन पर encap = yes सेटिंग NAT-पहचान आदान-प्रदान को प्रभावित करती है ताकि दोनों पक्ष ESP के लिए UDP एनकैप्सुलेशन उपयोग करें। संरक्षित पैकेट फिर UDP के भीतर, आमतौर पर पोर्ट 4500 पर यात्रा करते हैं, और दोनों सिरों को इस व्यवस्था पर सहमत होना चाहिए।

connections {
    site {
        encap = yes
        # existing approved peer, authentication and child settings
    }
}

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

strongSwan की NAT-traversal मार्गदर्शिका इस व्यवहार का वर्णन करती है, जिसमें MOBIKE उपयोग होने पर पोर्ट फ़्लोटिंग के साथ अंतःक्रिया शामिल है।

वह सेटिंग उपयोग करें जो आपके बैकएंड की है

strongSwan में दो कॉन्फ़िगरेशन बैकएंड हैं, और कुंजी उनके बीच भिन्न है। एक swanctl.conf कनेक्शन encap लेता है, जबकि पुराना ipsec.conf कनेक्शन forceencaps लेता है। एक बैकएंड का कीवर्ड दूसरे में डालने से ऐसा कॉन्फ़िगरेशन बनता है जो बिना शिकायत लोड होता है और कुछ नहीं बदलता, जो त्रुटि से भी बुरा है।

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

कनेक्शन के स्वामी के माध्यम से बदलाव लागू करें और नियंत्रित विंडो में संबंध फिर से स्थापित करें। पहले से स्थापित child प्रतिस्थापित होने तक अपना वर्तमान एनकैप्सुलेशन रखता है, इसलिए केवल फ़ाइल संपादन यह सिद्ध नहीं करता कि नई व्यवस्था उपयोग में है।

लपेटे गए डेटा की जाँच करें, केवल पोर्ट की नहीं

संरक्षित ट्रैफ़िक बहते समय गेटवे पर कैप्चर करें, फिर उसकी तुलना strongSwan के अपने दृश्य से करें:

$ sudo tcpdump -ni eth0 'udp port 4500' -c 20
$ sudo swanctl --list-sas --ike site
$ sudo ip xfrm state list

native ESP IP प्रोटोकॉल 50 के रूप में दिखता है और UDP जैसा बिलकुल नहीं लगता। लपेटा गया ESP 4500 पर UDP डेटाग्राम के रूप में दिखता है जिनका पेलोड IKE नहीं है। उसी पोर्ट पर IKE ट्रैफ़िक एनकैप्सुलेशन का प्रमाण नहीं है, क्योंकि MOBIKE IKE को वहाँ ले जा सकता है जबकि डेटा पथ native रहता है, इसलिए पोर्ट संख्या नहीं, पेलोड पढ़ें।

पथ MTU को भी ध्यान में रखें। आवरण अतिरिक्त ओवरहेड जोड़ता है, और native ESP ले जाने वाले पथ को पैकेट बढ़ने पर समायोजन की ज़रूरत हो सकती है। आवश्यक ICMP प्रबंधन पहले से डिज़ाइन का हिस्सा होना चाहिए; एनकैप्सुलेशन उस निर्भरता को नहीं हटाता।

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

संबंधित लेख