Windows VPN ला कनेक्ट करा आणि रूट टेबल उघडा, दोन नोंदी लगेच लक्षात येतात: 0.0.0.0/1 आणि 128.0.0.0/1. या टायपिंगच्या चुका नाहीत आणि त्या डीफॉल्ट रूटची जागा घेत नाहीत. त्या दिसतात की नाही हे एका प्रोफाइल पर्यायावर अवलंबून असते, आणि ही जोडी पूर्ण टनेल तयार करण्याची पद्धत आहे, स्प्लिट-टनेल वैशिष्ट्य नाही. एकही ओळ बदलण्यापूर्वी पर्याय, प्रीफिक्स आणि इंटरफेस एकत्र वाचा.

डीफॉल्ट-गेटवे पर्याय काय इन्स्टॉल करतो

सर्व काही टनेलमधून पाठवणारा प्रोफाइल पर्याय ते दोन प्रीफिक्स जोडून काम करतो. पर्याय काढला तर ते अदृश्य होतात आणि टनेल अडॅप्टरला दिलेले सबनेटच कव्हर करणारा रूट शिल्लक राहतो. चेकबॉक्स जोडी नियंत्रित करतो; तो एकमेव डीफॉल्ट रूट पुन्हा लिहीत नाही. म्हणून टिक काढल्यानंतर टेबल डिलीट केल्यासारखे न दिसता अर्धवट पुनर्लेखनासारखे दिसते.

0.0.0.0/1 IPv4 जागेचा खालचा अर्धा भाग आणि 128.0.0.0/1 वरचा अर्धा भाग व्यापतो, म्हणून एकत्र ते प्रत्येक युनिकास्ट पत्ता व्यापतात. प्रत्येक डीफॉल्ट 0.0.0.0/0 पेक्षा अधिक विशिष्ट आहे, म्हणजे सर्वात लांब प्रीफिक्सची जुळणी सामान्य रहदारी टनेलमध्ये पाठवते तर भौतिक डीफॉल्ट रूट जिथे होता तिथेच राहतो. तो डीफॉल्ट ठेवणे दिखाऊ नाही: एन्क्रिप्टेड पेलोड गुंडाळणारे पॅकेट सर्व्हरच्या सार्वजनिक पत्त्यावर पाठवले जातात आणि त्यांना भौतिक अडॅप्टरमधून बाहेर पडावे लागते. डीफॉल्ट विभाजित करण्याऐवजी बदला, आणि टनेलचे स्वतःचे वाहतूक टनेलमध्ये शिरण्याचा प्रयत्न करेल, जे कनेक्शन नाही तर लूप आहे.

म्हणून VPN अडॅप्टरकडे निर्देश करणारा शब्दशः 0.0.0.0/0 आढळल्यास थांबणे योग्य आहे. नेटिव्ह क्लायंट सहसा असा लिहीत नाही, त्यामुळे मॅन्युअल रूट किंवा दुसऱ्या क्लायंटच्या कॉन्फिगरेशनने तुमच्या पाठीमागे टेबल बदलले आहे. खाली काहीही डीबग करण्यापूर्वी तो शोधा.

गेटवे वाचवण्यापेक्षा टियरडाउन स्वस्त आहे

एकाऐवजी दोन नोंदींचा व्यावहारिक युक्तिवाद टियरडाउन आहे. कनेक्टेड असताना क्लायंटकडे नेमके दोन रूट असतात आणि डिस्कनेक्ट होताना ते हटवतो, त्या क्षणी भौतिक अडॅप्टरकडे जे आहे ते सोडून देतो. ज्या क्लायंटने एकमेव डीफॉल्ट बदलले असेल त्याला मागील गेटवे लक्षात ठेवावा लागेल, आणि DHCP लीज बदलल्यानंतर आता नसलेला गेटवे पुनर्संचयित करू शकेल. दोन स्वतःच्या नोंदी अशी स्थिती बाळगत नाहीत.

इतर क्लायंटही याच रचनेपर्यंत पोहोचतात. redirect-gateway def1 असलेले OpenVPN प्रोफाइल डीफॉल्ट हटवण्याऐवजी ते दोन प्रीफिक्स इन्स्टॉल करते, आणि Windows क्लायंट त्याच राउटिंग कारणासाठी हा नमुना अनुसरतो.

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

कोणत्याही मेट्रिकपूर्वी सर्वात लांब प्रीफिक्स जिंकतो

प्रीफिक्सची लांबी इतर कोणत्याही फील्डपूर्वी शोध ठरवते. मेट्रिक फक्त समान प्रीफिक्स असलेल्या रूटमधील बरोबरी मोडतो, त्यामुळे /1 नोंद मेट्रिक वाईट असली तरी /0 डीफॉल्टला हरवते. इंटरफेस बाइंडिंग दोन रूट एक प्रीफिक्स सामायिक करतात आणि Windows ला कोणता अडॅप्टर पॅकेट पाठवेल हे निवडायचे असताना काय उरते ते ठरवते.

route print -4
Get-NetRoute -AddressFamily IPv4 | Sort-Object DestinationPrefix
Find-NetRoute -RemoteIPAddress 10.50.5.20

स्प्लिट-टनेल टेबलमध्ये भौतिक डीफॉल्ट, दोन अर्ध-डीफॉल्ट, टनेल सबनेटचा रूट आणि तुम्ही जोडलेला कोणताही ऑफिस प्रीफिक्स असतो. क्लायंट आणि प्रोफाइलनुसार भौतिक डीफॉल्ट कमी किंवा जास्त मेट्रिकवर असू शकतो, आणि /1 जोडी असेपर्यंत तो फरक काहीही बदलत नाही. जोडी काढली की तो सर्व बदलतो, तेव्हाच जुना गेटवे किंवा चुकीचा इंटरफेस समोर येतो. तुम्ही बदलण्याची अपेक्षा केलेली एक ओळ नाही, संपूर्ण टेबल वाचा.

ऑफिस प्रीफिक्ससाठी एक मालक निवडा

स्प्लिट टनेलसाठी VPN वापरावे लागणारे प्रीफिक्सच नाव द्या, आणि त्याच्या मालकीचा एक मार्ग निवडा. रूट नेमून दिलेल्या टनेल पत्त्याकडे वळवणे तो पत्ता बदलेपर्यंत काम करते, तर इंटरफेसला बांधणे पत्ता बदलणे सहन करते पण प्रोफाइल पुन्हा तयार झाल्यावर इंडेक्स पुन्हा नेमला की तुटते. प्रोफाइल-बाउंड cmdlet दोन्ही समस्या टाळते, पण प्रोफाइल लागते.

route -p add 10.50.0.0 mask 255.255.0.0 172.16.8.1
route -p add 10.50.0.0 mask 255.255.0.0 0.0.0.0 IF 31
Add-VpnConnectionRoute -ConnectionName Office -DestinationPrefix 10.50.0.0/16

cmdlet प्रीफिक्स नामांकित प्रोफाइलला बांधते, त्यामुळे रूट कनेक्शनसोबत दिसतो आणि त्यासोबत जातो, जे व्यवस्थापित लॅपटॉपला हवे असते. कायमस्वरूपी रूट रीबूटनंतरही टिकतो आणि ज्या प्रोफाइलने तो घडवला त्यानंतरही टिकतो, अशा रीतीने निवृत्त VPN वर्षानुवर्षे नोंदी मागे सोडतो. प्रत्येक प्रीफिक्ससाठी एक पद्धत निवडा आणि निवड नोंदवा, कारण एकाच प्रीफिक्ससाठी कायमस्वरूपी रूट आणि प्रोफाइल रूट मिळून टियरडाउनच्या वेळी सोडवणे कठीण अशी डुप्लिकेट तयार होतात. तुम्ही काहीही निवडा, मालकी केवळ मशीनवर नाही तर तिकिटातही दिसली पाहिजे.

मालकी हा या विभागाचा उत्तर असलेला प्रश्न आहे, वाक्यरचना नाही. एका प्रीफिक्ससाठी दोन मालक ही टाळण्यासारखी अयशस्वी पद्धत आहे।

वेबसाइटने नाही, गंतव्याने पडताळा

टनेल ओलांडावे लागणारे गंतव्य तपासा, एक्झिट पत्ता सांगणारी वेबसाइट नाही. Find-NetRoute निवडलेला रूट आणि स्रोत पत्ता परत करते, त्यामुळे ऑफिस प्रीफिक्स जिंकला की भौतिक डीफॉल्ट हे दिसते, आणि नंतर शेअर स्वतः उघडता.

Find-NetRoute -RemoteIPAddress 10.50.5.20
Get-VpnConnection -Name Office

एक्झिट पत्त्याची वेबसाइट कमकुवत तपासणी आहे, कारण DNS, IPv6 आणि ब्राउझर प्रॉक्सी प्रत्येकजण ती विनंती वेगळ्या मार्गाने पाठवू शकतो. IPv4 आणि IPv6 ला त्याच संवादात स्वतंत्र सेटिंग्जही असतात, आणि एक बॉक्स रिकामा केल्यास दुसरे कुटुंब अस्पर्श राहते, त्यामुळे ड्युअल-स्टॅक मशीन IPv4 स्प्लिट रूट अनुसरत असताना IPv6 टनेलमधून नेऊ शकते. प्रोफाइलला स्प्लिट म्हणण्यापूर्वी दोन्ही कुटुंबे तपासा. रूट बरोबर असूनही सेवा अयशस्वी झाल्यास उरलेला थर राउटिंग नाही, फिल्टरिंग आहे.

क्लायंट-व्यवस्थापित फायरवॉल परिपूर्ण रूट टेबल असतानाही ऑफिस सबनेट ब्लॉक करू शकतो. ते धोरण प्रोफाइल पाठवणाऱ्याचे आहे, रूट संपादणाऱ्याचे नाही.

संबंधित लेख