दो 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

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