आपका 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 को किसी आंतरिक और किसी सार्वजनिक होस्ट के विरुद्ध चलाएँ। पहला हॉप अलग होना चाहिए, और अगर नहीं है, तो क्लाइंट जो भी रिपोर्ट करे, विभाजन लागू नहीं है। फिर एक बार दोबारा कनेक्ट करें और दोहराएँ, क्योंकि धकेले गए रूट हर सत्र के साथ लौटते हैं।