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 का रूपमा क्याप्चरमा देखिएमा, र भित्री सेवा र त्यसको फिर्ती मार्ग अझै चलेमा परिवर्तन स्वीकार गर्नुहोस्। यसभन्दा कम केही पनि फाइलमा ठीक देखिने कन्फिगरेसन हो।

सम्बन्धित लेखहरू