NAT मार्फत L2TP/IPsec: वास्तवमा के बिग्रन्छ र किन

NAT ले L2TP/IPsec बिगार्छ भन्ने दाबी आधा सत्य छ र त्यसैले बेकार छ। ठेगाना अनुवाद सामान्य हो, NAT ट्राभर्सल ठ्याक्कै त्यसैबाट जोगिनका लागि छ, र दैनिक लाखौं क्लाइन्ट राउटरको पछाडिबाट जोडिन्छन्। बिग्रने कुरा एउटा निश्चित आदानप्रदानको एउटा निश्चित चरण हो: IKE ले कहिल्यै जवाफ पाउँदैन, एउटा मात्र प्रोटोकललाई अनुमति दिने नीतिले इन्क्याप्सुलेटेड टनेल फालिदिन्छ, वा टनेल निष्क्रिय हुँदा म्यापिङ सकिन्छ। तपाईं कुन चरणमा हुनुहुन्छ थाहा भएपछि, समाधान सामान्यतया एउटा नियम वा keepalive हुन्छ, नयाँ VPN डिजाइन होइन।

मिथक नै गलत प्रश्न हो

उपयोगी प्रश्न “NAT ले यो बिगार्छ कि” होइन, तर “आदानप्रदानको कुन भाग अनुवाद हुन्छ, र अनुवाद गर्ने उपकरणले त्यसको के गर्छ” हो। L2TP/IPsec तहगत प्रोटोकल हो: IKE वार्ता गर्छ, ESP सुरक्षा दिन्छ, र L2TP त्यो सुरक्षाभित्र PPP बोक्छ। ठेगाना अनुवादले प्रत्येक तहमा फरक असर गर्छ, र त्रुटि संवादको सट्टा वार्ताको चरण हेर्नुभयो भने असफलताका लक्षण छुट्याउन सकिन्छ।

सफलतापूर्वक वेब ब्राउज गर्ने राउटरले स्रोत पोर्ट अनुवादसहित TCP काम गर्छ भन्ने मात्र प्रमाणित गर्छ। यसले UDP 500, UDP 4500 वा प्रोटोकल 50 बारे केही भन्दैन, र यो परिनियोजन यी तीनवटैमा निर्भर छ।

चरण 1: IKE ले जवाफ त पाउनैपर्छ

पहिलो आदानप्रदान UDP 500 मा उत्तरदातातर्फ जान्छ। कुनै जवाफ फर्किएन भने अरु केही महत्त्वपूर्ण छैन: पूर्व-साझा कुञ्जी, प्रस्ताव र प्रमाणहरू पढ्नै नपाई रहन्छन्। क्लाइन्टको टाइमआउटबाट अनुमान नगरी अनुरोध र जवाफ हेर्नुहोस्:

sudo tcpdump -n -i any 'udp port 500 or udp port 4500 or proto 50'
swanctl --list-sas

जवाफ नभएको अनुरोध सामान्यतया फायरवाल वा माथिल्लो क्यारियरले प्याकेट फालिरहेको अर्थ हुन्छ, सर्भरले अस्वीकार गरेको होइन। प्रस्ताव वा प्रमाणपत्र समस्याको नाम लिने सूचना-पेलोडसहितको जवाफ भनेको प्याकेट पुगे र वार्ता सामग्रीमा असफल भयो भन्ने हो, जुन पूर्ण रूपमा फरक मर्मत हो।

दुवै पक्ष अनुवादको पछाडि छन् भने सुरु गर्नेले उत्तरदातासम्म पुग्नु मात्र पर्छ, त्यसैले अधिकांश क्लाइन्ट-पक्षीय परिनियोजन चरण 1 बाटै चल्छन्। सर्भर-पक्षीय होस्टिङ भनेको आगमन समस्या सुरु हुने ठाउँ हो, र त्यसैले यी दुई अवस्थालाई कहिल्यै एउटै मानेर छलफल गर्नु हुँदैन।

चरण 2: इन्क्याप्सुलेशनले फायरवालले देख्ने कुरा बदल्छ

ESP एउटा IP प्रोटोकल हो, TCP वा UDP पोर्ट होइन, र सामान्य पोर्ट ठेगाना अनुवादमा पुनः लेख्न पोर्ट फिल्ड हुँदैन। त्यसैले NAT ट्राभर्सलले सुरक्षित पेलोडलाई UDP 4500 मा सार्छ: इन्क्याप्सुलेशनले अनुवाद गर्ने उपकरणलाई अनुवाद गर्न जान्ने कुरा दिन्छ। त्यसो भएपछि, UDP 500 का लागि मात्र लेखिएको फायरवाल नियमले वार्तालाई अनुमति दिन्छ र टनेल फाल्छ, जसले लगमा सफल चरण 1 र कुनै ट्राफिक नभएको देखिने अन्योलपूर्ण नतिजा दिन्छ।

NAT पत्ता लागेपछि IKE आदानप्रदान आफैं पनि UDP 4500 मा जान सक्छ, जसले 500 मात्र अनुमति दिनेहरूलाई अचम्मित बनाउँछ। बाटोमा दुवै पोर्टलाई दुवै दिशामा अनुमति दिनुहोस्, र स्टेटफुल फायरवालले ट्राफिक देखेसम्म मात्र प्रवाह राख्छ भन्ने सम्झनुहोस्।

प्रोटोकल 50 अनुवाद नभएका बाटोहरूमा र बीचको बक्सले अनुमति दिन कन्फिगर गरिएका बाटोहरूमा अझै महत्त्वपूर्ण छ। यदि तपाईं हटाएर निदान गर्दै हुनुहुन्छ भने, नियमहरू थुपारेर थप्नुको सट्टा परिकल्पना बन्द गर्नुहोस्: 500, 4500 र ESP लाई अनुमति दिनुहोस्, टनेल उठेको पुष्टि गर्नुहोस्, त्यसपछि अनावश्यक ठहरिएको हटाउनुहोस्। जो नियम कसैले बुझाउन सक्दैन, त्यो अर्को अवरोधको कारण बनेपछि कसैले नहटाउने नियम हो। साँघुरो बनाइएको कुरा परिवर्तन-अभिलेखमा सुधारेको चरणसँगै लेख्नुहोस्, ताकि अर्को इन्जिनियरले त्यही औंला-नियमबाट होइन, तपाईंको प्रमाणबाट सुरु गरोस्।

चरण 3: म्यापिङ सकिन्छ र टनेल मर्छ

अनुवाद गर्ने उपकरणले अगाडि पठाउने प्रवाहहरूका लागि स्थिति राख्छ, र त्यो स्थितिको आयु हुन्छ। कसैले प्रयोग नगर्दा L2TP/IPsec टनेलले थोरै ट्राफिक बोक्छ, त्यसैले निष्क्रिय टनेल आफ्नो म्यापिङभन्दा लामो बाँच्न सक्छ र फर्किने ट्राफिक लिन बन्द गर्न सक्छ। क्लाइन्ट जोडिएको छु भनी विश्वस्त रहन्छ, सर्भरले केही देख्दैन, र पहिलो लक्षण सामान्यतया VPN त्रुटि होइन, एप्लिकेसनको टाइमआउट हो।

मृत साथीको पहिचान र NAT keepalive यसैका लागि छन्, र दुवै छेउ ती पठाउन तयार हुनुपर्छ। यदि तपाईंको सर्भर अनुवादको पछाडि छ भने, Windows पक्षको आवश्यकता भनेको सर्भरले आफ्नै बाहिर जाने प्याकेटका लागि UDP इन्क्याप्सुलेशन मान्न बाध्य पार्ने अभिलेखित रजिस्ट्री सेटिङ हो; त्यो बिना उत्तरदाताले ESP पठाउँछ जसलाई अनुवाद गर्ने उपकरणले फर्काएर म्याप गर्न सक्दैन। यो सर्भर कन्फिगरेसनको विषय हो, क्लाइन्टको होइन।

WAN ठेगाना बदलिँदा अर्को दिशाबाट उही नतिजा आउँछ: म्यापिङ नयाँ ठेगानाको वरिपरि पुनः बनाइन्छ, र पुरानो सुरक्षा संगठन अब नभएको टपलतर्फ सङ्केत गर्छ। पुनः जडानको व्यवहार क्लाइन्ट कार्यान्वयनको हो, र त्यसैले “राउटर रिबुटपछि फेरि जोडिनु” एउटा क्लाइन्टमा काम गर्छ र अर्कोमा हातले टगल चाहिन्छ।

क्यारियर-ग्रेड NAT पछाडि होस्टिङ फरक समस्या हो

यदि तपाईं घरमा L2TP/IPsec सर्भर होस्ट गरी बाहिरबाट पुग्न चाहनुहुन्छ भने, आवश्यकता नमागिएको आगमन पहुँच हो, र NAT ट्राभर्सलले त्यो दिँदैन। तपाईंको राउटरअगाडि क्यारियर-ग्रेड NAT हुनुको अर्थ सार्वजनिक ठेगाना साझा भएको र म्यापिङ बाहिर जाने मात्र भएको हुँदा तपाईंलाई पुग्नयोग्य बनाउने फर्वार्ड गर्न सकिने पोर्ट छैन।

कुनै IPsec पास-थ्रु चेकबक्सले यो बदल्दैन, र कुनै क्लाइन्ट कन्फिगरेसनले यसको भरपाई गर्दैन। समर्थित उत्तरहरू वास्तवमै पुग्नयोग्य ठेगाना, होस्ट गरिएको अन्तिम बिन्दु, वा प्रत्येक सहभागीले बाहिर जाने जडान गर्ने संरचना हुन्। UDP इन्क्याप्सुलेशन विशिष्टता ले विद्यमान प्रवाहहरूका लागि अनुवादको समस्या समाधान गर्छ; क्यारियरले नदिने ठाउँमा यसले आगमन मार्ग सिर्जना गर्दैन।

त्यसैले अनुमान नगरी सञ्जालहरू तुलना गर्नुहोस्। त्यही उपकरण र प्रोफाइल अर्को अनुमति प्राप्त सञ्जालमा लगेर त्यहाँ कुन चरण असफल हुन्छ हेर्नुहोस्। यदि अन्यत्र काम गर्छ भने फरक बाटोमा छ, र यसले खोजीलाई सम्पूर्ण कन्फिगरेसनको सट्टा माथिका तीन चरणसम्म सीमित गर्छ।