L2TP/IPsec लाई IPsec सँगै UDP 1701 किन चाहिन्छ

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 डिमन वा स्थानीय फिल्टर शंकास्पद छ; यदि यो कहिल्यै वार्ता गर्दैन भने, बाहिरी पोर्टहरू जिम्मेवार छन्। त्यो एउटै विभाजनले कुन नियम थप्ने भन्ने अनुमानको धेरैजसो हटाउँछ, र प्रोटोकलको तहले यसलाई रहस्यमय नभई अनुमानयोग्य बनाउँछ।