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 एन्कॅप्स्युलेशन विनिर्देश सध्याच्या प्रवाहांसाठी अनुवादाची समस्या सोडवतो; कॅरियर देत नाही तिथे तो आवक मार्ग तयार करत नाही।

म्हणून अंदाज न लावता नेटवर्कची तुलना करा। तेच उपकरण आणि प्रोफाइल दुसऱ्या परवानगी असलेल्या नेटवर्कवर न्या आणि तिथे कोणता टप्पा अपयशी होतो ते पहा। इतरत्र चालले तर फरक मार्गात आहे, आणि त्यामुळे शोध संपूर्ण कॉन्फिगरेशनऐवजी वरील तीन टप्प्यांपर्यंत मर्यादित होतो।