जे फायरवॉल IKE आणि ESP ला परवानगी देतात पण UDP 1701 ला नाही, ते L2TP कनेक्शन्स अशा प्रकारे तोडतात जे क्रेडेन्शियलच्या समस्येसारखे दिसते। कारण म्हणजे L2TP हा पहिल्याच्या आत प्रवास करणारा दुसरा प्रोटोकॉल आहे। IPsec हे देवघेव वाहून नेते आणि प्रमाणित करते, आणि L2TP UDP 1701 वर स्वतःची बोगदा चालवते, जी स्थानिक स्टॅकला अजूनही पोहोचवावी लागते। प्रत्येक हेडर कुठे दिसतो हे जाणून घेतल्यास कोणत्या उपकरणाला कोणता नियम हवा हे समजते।

दोन प्रोटोकॉल, दोन पोर्ट संच

L2TP/IPsec कनेक्शन UDP 500 वर IKE, अनुवाद असलेल्या ठिकाणी UDP 4500 वर NAT ट्रॅव्हर्सल, आणि नसलेल्या ठिकाणी IP प्रोटोकॉल 50 म्हणून ESP वापरते। L2TP स्वतः UDP 1701 वरचा बोगदा प्रोटोकॉल आहे, आणि IPsec ने प्रतिस्पर्ध्याची प्रमाणित केल्यानंतर तो चालतो। दोन्ही अर्धे वेगळ्या प्रकारे अपयशी होतात, आणि त्यांची नोंद करणाऱ्या लॉग ओळी वेगळ्या घटकांतून येतात। फक्त पहिले अर्धे व्यापणारा नियम संच असा कनेक्शन तयार करतो जो बोलणी करतो आणि नंतर बोगदा टप्प्यात मरतो।

पोर्ट क्रमांक वाहतुकीचे टोक बिंदू वर्णन करतात, आणि ESP पोर्टच नाही। म्हणूनच फक्त TCP आणि UDP नियम देणारा फायरवॉल इंटरफेस पूर्ण IPsec धोरण व्यक्त करू शकत नाही। प्रोटोकॉल 50 ला प्रोटोकॉल म्हणून परवानगी द्यावी लागते, आणि फक्त UDP चा उल्लेख करणारा नियम त्याच्याशी कधीही जुळणार नाही।

आवरणच पोर्टची माहिती देतो

तारेवर, L2TP/IPsec कनेक्शन सामान्यतः 500 वर IKE आणि 4500 वर गुंडाळलेले ESP दाखवते। UDP 1701 हेडर संरक्षित पेलोडच्या आत बसते, त्यामुळे बाहेरील इंटरफेसवरील कॅप्चर ते दाखवत नाही। स्थानिक होस्टला तो डेटाग्राम L2TP डेमनपर्यंत अजूनही पोहोचवावा लागतो, आणि पोहोचवणे डीकॅप्स्युलेशननंतर होते। म्हणून 1701 नियम एंडपॉइंटच्याच फायरवॉलशी संबंधित आहे, जेव्हा कोणताही मध्यस्थ बॉक्स तो पोर्ट कधीही पाहत नाही तेव्हाही।

प्रक्रियेचा क्रम बहुतेक गोंधळ समजावून सांगतो। जर स्टॅक होस्ट फिल्टरपूर्वी IPsec धोरण लागू करत असेल, तर डीकॅप्स्युलेटेड L2TP पॅकेट UDP 1701 म्हणून जुळवले जाते; क्रम उलटा असेल तर नियम संचाला बाहेरील पोर्ट दिसतात। दोन्ही वर्तन प्रत्यक्षात आहेत, म्हणूनच तोच नियम संच एका प्लॅटफॉर्मवर चालतो आणि दुसऱ्यावर अपयशी होतो असे दिसते।

क्रमाने मार्ग तपासा

प्रथम बाहेरील इंटरफेसवर कॅप्चर करा आणि IKE आणि गुंडाळलेले ESP दोन्ही दिशांनी हलत असल्याची खात्री करा। नंतर डीकॅप्स्युलेटेड ट्रॅफिकसाठी स्थानिक फायरवॉल काउंटर तपासा। क्रम महत्त्वाचा आहे, कारण काहीच न दाखवणारे कॅप्चर म्हणजे समस्या होस्टच्या वर आहे।

sudo tcpdump -ni eth0 'udp port 500 or udp port 4500'
sudo nft list ruleset | grep -i -A2 1701
sudo ss -lunp | grep 1701

कॅप्चर देवघेवीचे पहिले अर्धे प्रमाणित करते आणि प्रतिस्पर्धी उत्तर देत आहे का हे दाखवते। नियम सूची 1701 नियम आहे का आणि कोणत्याही ड्रॉप धोरणाच्या तुलनेत तो कुठे बसतो हे दाखवते। सॉकेट सूची L2TP डेमन बांधलेला असून ऐकत असल्याची खात्री देते, ज्यामुळे कधीही सुरू न झालेली सेवा वगळली जाते। नियम बदलण्यापूर्वी तीनही वाचा, कारण अनुपस्थित श्रोता आणि फिल्टर केलेला पोर्ट वापरकर्त्याकडून तीच तक्रार उभी करतात।

पोर्ट स्कॅन काय दाखवू शकत नाही

योग्यरीत्या संरचित सर्व्हरविरुद्ध UDP 1701 चा बाह्य स्कॅन सामान्यतः काहीही नोंदवत नाही, आणि तोच अपेक्षित निकाल आहे। पोर्ट इंटरनेटवर उघडा नाही; IPsec ने प्रतिस्पर्धी प्रमाणित केल्यानंतरच त्याच्यापर्यंत पोहोचता येते। बंद निकालाला दोष मानल्यास बंद राहिला पाहिजे असलेला पोर्ट उघडला जातो। स्कॅन बोगद्याच्या आत एवढेच पाहू शकत नाही, जेवढे ते ॲप्लिकेशन ट्रॅफिक पाहू शकत नाही।

त्याऐवजी खऱ्या क्लायंटसह चाचणी करा, आणि ते कोणत्या टप्प्यापर्यंत पोहोचते ते वाचा। जर कनेक्शन बोलणी करून नंतर अडकले, तर L2TP डेमन किंवा स्थानिक फिल्टर संशयित आहे; जर ते कधीच बोलणी करत नसेल, तर बाहेरील पोर्ट जबाबदार आहेत। तो एकच विभाजन कोणता नियम जोडावा याबद्दलचे बहुतेक अंदाज दूर करते, आणि प्रोटोकॉलचे स्तर रहस्यमयाऐवजी अंदाजण्यायोग्य बनवतात।

संबंधित लेख