तुमचा Windows VPN स्थानिक प्रिंटर कसा मारतो आणि ते कसे थांबवायचे

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

आधी रूट तक्ता वाचा

काहीही बदलण्यापूर्वी, IPv4 तक्ता यासह घ्या: route print -4 आणि आउटपुट ठेवा। कनेक्ट करा, पुन्हा घ्या आणि 0.0.0.0 ओळींची तुलना करा: सक्रिय डीफॉल्ट रूट एक इंटरफेस नाव देते, आणि तो इंटरफेस टनेल असेल तर स्थानिक प्रिंटिंग आणि ब्राउझिंग आधी ऑफिसला पाठवले जाते।

दुसऱ्या स्तंभातील इंटरफेस क्रमांक हा कायमस्वरूपी रूटला नंतर संदर्भ द्यावा लागणारा मूल्य आहे, म्हणून टनेल सुरू असताना तो नोंदवा। अडॅप्टर पुन्हा तयार झाल्यावर बदलणारे मूल्यही तेच आहे, त्यामुळे त्याला पिन केलेले रूट शांतपणे त्यांच्या उपयुक्ततेपुढे टिकू शकतात।

डीफॉल्ट रूट काढा, तीन मार्गांनी

अंगभूत Windows प्रोफाइलमध्ये नियंत्रण एक चेकबॉक्स आहे। कनेक्शनचे गुणधर्म उघडा, IPv4, नंतर प्रगत, आणि Use default gateway on remote network काढून टाका; नवीन सेटिंग्ज अॅप तोच संवाद एक थर खोलवर लपवते। उन्नत प्रॉम्प्टमधून तोच बदल एक cmdlet आहे:

Set-VpnConnection -Name "Corp" -SplitTunneling $true

एक OpenVPN प्रोफाइल वेगळ्या पद्धतीने काम करते, त्यामुळे त्याचे वर्तन चेकबॉक्स अपेक्षिणाऱ्यांना गोंधळात टाकते। त्याचे redirect-gateway def1 निर्देश डीफॉल्ट रूट अजिबात बदलत नाहीत; ते अर्ध्या-श्रेणीचे दोन रूट बसवते, 0.0.0.0/1 आणि 128.0.0.0/1, जे मिळून डीफॉल्ट न हटवता त्यावर मात करतात। मूळ डीफॉल्ट टिकत असल्याने, net_gateway कडे निर्देशित प्रीफिक्स जोडल्यास फक्त तोच प्रीफिक्स स्थानिक राउटरकडे परत जातो। def1 प्रोफाइलसाठीचा उपाय हा कोणालाही न सापडणारा चेकबॉक्स नसून प्रीफिक्स रूट का आहे हे तेच तपशील स्पष्ट करते।

फक्त कामाचे असलेले परत जोडा

डीफॉल्ट रूट गेल्यावर टनेल काहीही वाहून नेते, म्हणून कामाचे प्रीफिक्स स्पष्टपणे नाव देऊन सांगावे लागतात। प्रीफिक्स कनेक्शनशी बांधणारा cmdlet कायमस्वरूपी रूटपेक्षा सुरक्षित आहे, कारण तो ते कनेक्शन सुरू असतानाच बसवला जातो आणि इंटरफेस क्रमांकावर अवलंबून नसतो:

Add-VpnConnectionRoute -ConnectionName "Corp" -DestinationPrefix 172.20.0.0/16

जुनी पद्धत अजूनही चालते आणि अजूनही प्रत्येक तपासणी यादीत आहे: route -p add 172.20.0.0 mask 255.255.0.0 172.20.0.1 if 14, टनेलच्या स्वतःच्या इंटरफेस इंडेक्स आणि गेटवे पत्त्यासह। ते रीबूटमधून टिकते, हाच उद्देश आणि हाच धोकाही, कारण पुढच्या बूटला इंडेक्स दुसऱ्या कशाचा असू शकतो।

बाकीचे मेट्रिक ठरवतात। भौतिक आणि टनेल अडॅप्टर दोन्ही एकाच प्रीफिक्ससाठी रूटचा दावा करत असतील तर कमी मेट्रिक जिंकते, आणि टनेलचे मेट्रिक वाढवणे हे हॅक नसून क्लायंट-बाजूचे कायदेशीर नियंत्रण आहे।

जेव्हा सर्व्हर तुमच्यावतीने ठरवतो

तुमच्या चेकबॉक्सकडे दुर्लक्ष करणारा क्लायंट सहसा एखाद्या धोरणाचे पालन करत असतो। Cisco प्रोफाइलमध्ये Allow Local LAN Access सेटिंग असते, आणि headend क्लायंटला आवडेल ते सर्व रद्द करणारे tunnel-all धोरण ढकलू शकतो; सक्तीच्या-टनेल तैनातीत बदलण्यासाठी स्थानिक स्विच नसतो। तोच संवाद पुन्हा तपासण्याऐवजी ढकललेल्या रूट आणि धोरण ओळींसाठी क्लायंट लॉग वाचा।

नंतर नाव-निराकरण पाहा, जे राउटिंगपासून वेगळे स्विच आहे। विभाजित टनेलला अजूनही अंतर्गत resolver आणि शोध सफिक्स मिळू शकते, त्यामुळे स्थानिक उपकरण पत्त्याने पोहोचण्यायोग्य आहे आणि DNS बाजूही दुरुस्त होईपर्यंत नावाने सापडत नाही।

ओव्हरलॅप ही वेगळी समस्या आहे

घरचे LAN आणि ऑफिसचे LAN 192.168.0.0/24 सारखे प्रीफिक्स सामायिक करत असतील, तर कोणतेही रूट त्यांना वेगळे करू शकत नाही। त्या श्रेणीतील प्रत्येक पॅकेटला एकच शोध-निकाल असतो, आणि उपाय म्हणजे एक बाजू पुन्हा क्रमांकित करणे किंवा पूलमधून अनुवादित पत्त्याने ऑफिस गाठणे। अधिक विशिष्ट रूट जोडल्याने नेटवर्कचा कोणता अर्धा भाग तुटतो एवढेच सरकते।

पाचऐवजी एका पडताळणीने संपवा: कनेक्ट करा, नंतर tracert अंतर्गत आणि सार्वजनिक होस्टविरुद्ध चालवा। पहिले हॉप वेगळे असायला हवे, आणि नसेल तर क्लायंट काहीही अहवाल देत असला तरी विभाजन लागू नाही। नंतर एकदा पुन्हा कनेक्ट करा आणि पुन्हा करा, कारण ढकललेले रूट प्रत्येक सत्रासह परत येतात।