दुई WAN भएको VPN नीतिले कुन प्याकेटसँग मिल्नुपर्छ?

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

दुई कुराकानीलाई नाम दिनुहोस्

कार्यालय गेटवेमा जोडिएको टाढाको कर्मचारीले आन्तरिक एप्लिकेसन सर्भरतर्फ HTTPS खोलेको कल्पना गर्नुहोस्। तारमा दुई स्वतन्त्र कुराकानी छन्, र प्रत्येक टुप्पोमा तिनका ठेगाना फरक छन्। बाहिरी कुराकानी दुई VPN टुप्पोबीच चल्छ: गेटवे ठेगानाबाट पियर ठेगानासम्म, परिनियोजनले सहमति गरेको प्रोटोकल र पोर्टमा। भित्री कुराकानी क्लाइन्टलाई दिइएको ठेगानाबाट 443 पोर्टमा एप्लिकेसन सर्भरको ठेगानासम्म चल्छ।

एप्लिकेसनको गन्तव्य पोर्ट VPN को यातायात पोर्ट होइन, र TCP 443 मा जति पनि नीति भए पनि टनेल सर्दैन। त्यस्तै, पियरको यातायात ठेगाना पुनर्निर्देशन गर्ने नियमले त्यो प्रयोगकर्ताको HTTP अनुरोध डिक्रिप्सनपछि कहाँ जान्छ भन्नेबारे केही भन्दैन। नियम छुनुअघि दुवै कुराकानी तिनका वास्तविक ठेगानासहित लेख्नुहोस्, किनकि यस क्षेत्रका अधिकांश भ्रम एउटालाई नाम दिएर अर्कोलाई कन्फिगर गर्नबाट आउँछ।

तपाईंको नीतिले प्याकेट वास्तवमै कहाँ देख्न सक्छ पत्ता लगाउनुहोस्

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

त्यही भएर एउटै कन्फिगरेसन टुक्रा दुई प्लेटफर्ममा फरक व्यवहार गर्छ: जोडिने बिन्दु फरक छन्, र विक्रेताको नीति हुक इन्क्रिप्सन चरणअघि वा पछि हुन सक्छ। अर्को विक्रेताको रेखाचित्रबाट क्रम अनुमान गर्नुको सट्टा त्यो विशिष्ट उत्पादनका लागि प्याकेट मार्ग पढ्नुहोस्।

तपाईंले सहमति गरेको यातायात पुष्टि गर्नुहोस्

UDP मा इन्क्याप्सुलेटेड IPsec का लागि, RFC 3948 ले ESP लाई UDP भित्र राख्छ र साझा पोर्टमा IKE छुट्याउन सकिने बनाउन गैर-ESP चिन्ह प्रयोग गर्छ। सादा ESP एउटा IP प्रोटोकल हो, TCP वा UDP पोर्ट होइन, त्यसैले पोर्ट नम्बरमा लेखिएको फायरवाल नियमले यसलाई बिल्कुलै मिलाउँदैन। यही भिन्नताले तपाईंको WAN नीतिलाई UDP नियम, प्रोटोकल नियम वा दुवै चाहिन्छ कि भन्ने निर्धारण गर्छ।

सहमति भएका मानहरू सम्झिएका मानभन्दा बलियो हुन्छन्। उपकरणबाट एसोसिएसनका हालका पोर्ट र ठेगाना पढ्नुहोस्, सावधानीका लागि TCP 4500 वा पुरानो विक्रेता पोर्ट थप्नुको सट्टा, जसले असम्बन्धित ट्राफिक समात्छ र वास्तविक वर्गीकरण समस्या लुकाउँछ।

प्रतिबद्ध हुनुअघि फर्कने मार्ग जाँच्नुहोस्

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

नेटवर्क ठेगाना अनुवादको अवस्था WAN परिवर्तनको सामान्य शिकार हो। छानिएको अपलिंक, अपेक्षित बाहिरी स्रोत ठेगाना, प्रयोगमा रहेको अनुवाद र पियरको त्यहाँसम्मको पहुँच रेकर्ड गर्नुहोस्, त्यसपछि यातायातलाई यसले बोक्ने टनेलमा नपठाई पहुँचयोग्य राख्नुहोस्।

दुई क्याप्चरले दुवै तह जाँच्नुहोस्

WAN इन्टरफेसमा एउटा क्याप्चर र टनेलभित्र एउटा क्याप्चरले कुनै पनि कन्फिगरेसन तुलनाभन्दा छिटो प्रश्न टुंग्याउँछन्। स्वीकृत क्लाइन्टले एउटा मात्र अनुरोध गर्दा ती गेटवेबाट चलाउनुहोस्, र दुवै फाइल राख्नुहोस्।

sudo tcpdump -ni wan1 'udp port 4500' -c 20
sudo tcpdump -ni tun0 'tcp port 443 and host 203.0.113.10' -c 20
ip route get 203.0.113.10 from 10.8.0.6

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