Windows वर स्प्लिट टनेल: गेटवे बॉक्स आणि गायब उपसर्ग
Windows सर्व काही टनेलमधून पाठवते, एक चेकबॉक्स रिकामा करेपर्यंत, आणि नंतर सबनेट जोडेपर्यंत खूप कमी पाठवते। दोन्ही एकाच बदलाचे भाग आहेत।
टनेल जोडलेले असल्याचे सांगते आणि विकी अजूनही लोड होते। मग एक डाउनलोड अडकतो आणि शेल्फवरील शेअर उत्तर देणे थांबवते। टनेलने आपले काम केले, आणि प्रोफाइलने फक्त प्रत्येक गंतव्याचा दावा केला।
Windows VPN कनेक्शनला राउटिंग निर्णय मानते। तो निर्णय अरुंद होईपर्यंत, मशीन कार्यालयात गेल्यासारखे वागते।
चालू टनेलही खंडासारखा का वाटतो
दूरच्या गेटवेचा वापर करण्यास परवानगी असलेले प्रोफाइल टनेलमधून डीफॉल्ट राउट स्थापित करते। मग स्थानिक लिंकवर नसलेले प्रत्येक गंतव्य कार्यालयाच्या फायरवॉलमधून बाहेर पडते। स्थानिक शेअर उत्तर देणे थांबवतात, कारण त्यांचा रहदारी आता दुसर्या खंडात जाऊन परत येतो। क्लायंटच्या स्थितीत काहीही ते प्रतिबिंबित करत नाही।
लक्षणे जाणूनबुजून गोंधळात टाकणारी आहेत। शेअरची वेळ संपत असताना नाव निराकरण अजूनही चालू असू शकते, किंवा उलटही। वापरकर्ता सांगतो VPN तुटलेला आहे, क्लायंट स्वतःला ठीक सांगतो, आणि दोन्ही विधाने अचूक आहेत।
IPv4 संवादात लपलेला चेकबॉक्स
सेटिंग अनेक संवाद खोल आहे। ncpa.cpl उघडा, कनेक्शनवर उजवे-क्लिक करा, नंतर IPv4 गुणधर्म, नंतर प्रगत, आणि कनेक्शनला दूरचे डीफॉल्ट गेटवे होऊ देणारा पर्याय काढून टाका। तोच एक बॉक्स प्रोफाइल पूर्ण टनेल आहे की नाही हे ठरवतो। प्रोफाइलमधील बाकी सर्व अजूनही लागू आहे।
पुन्हा जोडण्यापूर्वी आणि नंतर route print -4 ची तुलना करा। पूर्वी टनेलकडे निर्देश करणारी 0.0.0.0 नोंद गेली पाहिजे, आणि कॉर्पोरेट उपसर्ग अजूनही तिथे असावेत।
route print -4 | findstr /c:"0.0.0.0"
Get-VpnConnection -Name 'Work VPN' | Select-Object Name, SplitTunneling, Routes
इंटरफेस मेट्रिक बदलणे हा त्याचा पर्याय नाही। मेट्रिक फक्त दोन स्पर्धक डीफॉल्ट राउटमध्ये निर्णय घेते, आणि प्रत्येक कनेक्शनला स्वतःचा डीफॉल्ट राउट पुन्हा स्थापित करणारा क्लायंट कोणतीही संख्या सेट केली तरी ती स्पर्धा जिंकतो।
ज्याची कोणीही यादी केली नाही तो उपसर्ग
स्प्लिट टनेलिंग प्रोफाइलमध्ये नोंदवलेले उपसर्गच उघड करते। प्रोफाइल लिहिल्यानंतर जोडलेले कार्यालय सबनेट टनेल पूर्णपणे निरोगी असतानाही पोहोचण्यायोग्य नसते। मग अहवाल तुटलेल्या VPN ऐवजी एका तुटलेल्या सर्व्हरप्रमाणे येतो।
हाताने जोडलेला राउट गेटवे पत्ता बदलण्यापर्यंत अंतर भरतो। उपसर्ग कनेक्शनमध्ये नोंदवणे अधिक टिकाऊ आहे, कारण मग उपसर्ग अंदाजलेल्या पत्त्याऐवजी कनेक्शनचे अनुसरण करतो।
route -p add 172.20.8.0 mask 255.255.255.0 10.8.0.1
Add-VpnConnectionRoute -ConnectionName 'Work VPN' -DestinationPrefix 172.20.8.0/24
Get-VpnConnection -Name 'Work VPN' | Select-Object -ExpandProperty Routes
साठवलेली यादी आणि जिवंत तक्ता एकत्र वाचा। साठवलेला उपसर्ग असू शकतो पण कनेक्शन वर आल्यानंतर व्यवस्थापन एजंटने राउट गाळल्यावर तक्त्याला तो कधीच मिळत नाही। उलटेही होते, रजिस्ट्री राउट बंद असलेल्या ॲडॉप्टरकडे निर्देश करतो। दोन्हींपैकी एक दृश्य एकटे पूर्ण कथा सांगत नाही।
रीबूटनंतर निकाल सिद्ध करणे
दोन्ही दिशांनी ट्रेस करा आणि नावाने सोडवा। सार्वजनिक ट्रेस प्रदात्यामार्फत बाहेर पडावा, अंतर्गत ट्रेस टनेलमध्ये प्रवेश करावा, आणि अंतर्गत होस्टने केवळ पत्त्याने नव्हे तर नावानेही उत्तर द्यावे।
tracert -4 www.example.com
tracert -4 wiki.corp.example
ping -4 fileserver.corp.example
ping -4 172.20.8.20
डिस्कनेक्ट, पुन्हा कनेक्ट आणि एक रीबूटनंतर पुन्हा करा। जो उपसर्ग मॅन्युअल पुन्हा कनेक्ट टिकून राहतो आणि रीस्टार्टनंतर गायब होतो तो कधीही प्रोफाइलमध्ये साठवला गेला नव्हता।
प्रिंटर आणि NAS देखील चाचणीत ठेवा, कारण लॅपटॉपजवळील उपकरणे कापणारी स्प्लिट टनेलने एक समस्या लहान आणि अधिक त्रासदायक समस्या निर्माण करून सोडवली आहे। तुमच्या मॉड्यूल आवृत्तीशी पॅरामीटर्सचे स्पेलिंग तपासण्याची जागा Microsoft चा Add-VpnConnectionRoute संदर्भ आहे।