NAT ट्राभर्सलले ESP लाई UDP भित्र कसरी बेर्छ

एउटै राउटर पछाडिका दुई ग्राहकहरू एउटै IPsec गेटवेसँग कुरा गर्छन्, र एउटा लगातार खस्छ जबकि अर्को जोडिएको रहन्छ। मूल ESP पोर्ट नभएको 50 नम्बरको IP प्रोटोकल हो, त्यसैले धेरै ग्राहकहरूले एउटै ठेगाना साझा गर्दा अनुवादकसँग म्यापिङका लागि समात्ने कुनै कुरा हुँदैन। NAT ट्राभर्सलले 4500 मा ESP लाई UDP भित्र बेरेर त्यो खाली ठाउँ भर्छ, र त्यो हेडरले पछिका अधिकांश लक्षणहरू व्याख्या गर्छ। यसले बदल्नुपर्ने यन्त्र पनि देखाउँछ।

डेटा तल 4500 पोर्टमा किन जान्छ

सेटअपको क्रममा IKEv2 ले प्रत्येक पक्षले प्रयोग गरिरहेको ठान्ने ठेगाना र पोर्टहरूलाई आफ्ना NAT पहिचान सूचनाहरूमा ह्यास आदानप्रदान गरेर तुलना गर्छ। ह्यास नमिल्दा मार्गको कतै अनुवादक बसेको हुन्छ, र दुवै पक्षले संरक्षित ट्राफिकलाई UDP इन्क्याप्सुलेसनमा सार्छन्। त्यसैले अनुवादकसँग भेटेको सत्र नभेटेको सत्रभन्दा फरक देखिन्छ।

बेर्ने काम एउटा खाम हो, प्रोटोकलको परिवर्तन होइन: ESP ले आफ्नो हेडर, अखण्डता जाँच र इन्क्रिप्सन कायम राख्छ, र UDP ले अनुवादकलाई चाहिने पोर्टहरू मात्र दिन्छ। पोर्ट 500 ले IKE आदानप्रदान बोक्छ; 4500 ले पहिचानपछिको बेरिएको डेटा, र प्रायः पछिका IKE सन्देशहरू पनि बोक्छ। कुनै पनि पोर्टले प्रवाहलाई TCP जडान बनाउँदैन, यही अनुमानले क्याप्चर पढ्ने अधिकांश मानिसहरूलाई भ्रममा पार्छ।

दुई चरणहरू क्रममा जाँच्नुहोस्

पहिले नियन्त्रण आदानप्रदान प्रमाणित गर्नुहोस्, त्यसपछि डेटा मार्ग, र दुवैलाई आफ्ना टिप्पणीहरूमा अलग राख्नुहोस्। 500 मा ट्राफिक देखाउने तर 4500 मा कहिल्यै नदेखाउने क्याप्चरले सामान्यतया डेटा मार्ग फिल्टर भइरहेको अर्थ दिन्छ, त्यसैले सुधार ग्राहकमा होइन, फायरवाल नियममा गर्नुपर्छ।

tcpdump -ni any 'udp port 500 or udp port 4500' प्रयोग गरेर दुवै पोर्ट हेर्नुहोस्, र सत्र सक्रिय हुँदा राउटरमा रहेको अनुवाद तालिका पढ्नुहोस्। त्यो तालिकाले गेटवेले वास्तवमै देख्ने स्रोत पोर्ट देखाउँछ, र ल्यापटपमा गरिएको क्याप्चर डिजाइनअनुसारै त्यससँग मिल्दैन: ल्यापटपले 500 ठान्छ जबकि गेटवेले अनुवादित स्रोत पोर्टसहित 4500 देख्छ, र दुवै सही छन्। त्यही प्रवाह, अनुवादअघि र पछि:

client 192.0.2.10:500 -> router 203.0.113.7:62000 -> gateway 198.51.100.9:4500

बेर्ने कामले व्याख्या गर्ने लक्षणहरू, र नगर्ने दुई

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

एकै पटक दुई ग्राहकका लागि म्यापिङ तालिका पढ्नुहोस्: यदि दुवैले एउटै अनुवादित पोर्ट देखाउँछन् भने यन्त्रले गेटवेले चाहेजस्तै उनीहरूलाई अलग गर्दैन। एउटा होस्टलाई मात्र मूल ESP दिने पासथ्रु मोडले धेरै अनुवादित ग्राहकहरूलाई सेवा दिनेसँग बराबर हुँदैन, यद्यपि विक्रेताहरूले दुवैलाई IPsec-मैत्री भन्छन्। दोहोरो NAT ले म्यापिङ तह र अर्को म्याद सकिने बिन्दु थप्छ, तर बाहिर जाने जडानहरू स्वतः तोड्दैन।

जीवित राख्ने ट्राफिकले सञ्चालन निर्देशिकामा आफ्नै लाइन पाउनुपर्छ, किनकि निष्क्रिय अवधिहरूमा जवाफको मार्ग खुला राख्ने काम त्यसैले गर्छ। विक्रेताले दस्तावेज गरेको ठाउँमा यसलाई सक्षम गर्नुहोस्, र सत्र पहिलो प्रयोगमा होइन, केही मिनेटको मौनतापछि मरेमा पहिले त्यही जाँच्नुहोस्।

म्यापिङको मालिक बदल्नुहोस्, त्यसपछि फेरि परीक्षण गर्नुहोस्

पोर्ट अनुमान गर्नुको सट्टा दुवै पक्षमा समर्थित NAT ट्राभर्सल सेटिङहरू पालना गर्नुहोस्। एउटा ग्राहकमा स्थानीय स्रोत पोर्ट सम्पादन गर्दा अर्को छेउमा सुनिरहेको सेवा बदल्न सकिँदैन, र सामान्यतया पहिले नै बनेको म्यापिङ तोड्छ। यदि ग्राहक तपाईंले नियन्त्रण नगर्ने यन्त्रको पछाडि छ भने, परिवर्तन त्यसको मालिकको हो।

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