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

पहिल्या कॅप्चरने बाहेरील संभाषण तुम्ही इच्छित असलेल्या इंटरफेसच्या बाहेर अपेक्षित स्रोत पत्त्यासह जाताना दाखवले पाहिजे। दुसऱ्याने अंतर्गत संभाषण एकदाच, पुनरावृत्तीशिवाय, क्लायंट पत्ता स्रोत आणि ॲप्लिकेशन सर्व्हर गंतव्य म्हणून दाखवले पाहिजे। मार्ग शोध राउटर त्या स्रोत-गंतव्य जोडीसाठी कोणती तक्ता वापरेल हे निश्चित करतो, आणि तिथेच धोरणातील चूक सहसा दिसते। जर कोणतेही कॅप्चर दिसले नाही, तर निर्णय बिंदू नियम जोडलेल्या ठिकाणी नाही तर इतरत्र आहे, आणि सुधारणा व्यापक जुळणीत नाही तर तिथेच हवी।