Windows कनेक्शन साझा कर रहे हैं? उसके नीचे VPN का रास्ता बदल जाता है
साझा किया गया अडैप्टर कंप्यूटर को राउटर बना देता है, और आगे भेजा गया ट्रैफ़िक होस्ट ऐप्स से अलग रास्ता लेता है। क्लाइंट से जाँचें, होस्ट से नहीं।
एक लैपटॉप अपना Wi-Fi साझा करता है, होस्ट बिना किसी शिकायत के टनल से ब्राउज़ करता है, और उस साझेदारी पर रखा टैबलेट कहीं नहीं पहुँचता। जिस पल साझेदारी चालू हुई, होस्ट केवल क्लाइंट रहना बंद कर चुका था: अब वह राउटर है, और आगे भेजे गए पैकेट नियमों का अलग समूह पाते हैं। होस्ट पर जो चलता है, वह उसके पीछे के डिवाइस के बारे में कुछ नहीं कहता। जाँचें डाउनस्ट्रीम क्लाइंट से चलाएँ और यह अंतर सैद्धांतिक रहना बंद कर देता है।
होस्ट की सफलता कुछ साबित नहीं करती
कनेक्शन साझेदारी एक मशीन को चार काम सौंपती है: पते देना, आगे भेजना, अनुवाद और फ़िल्टरिंग। स्थानीय रूप से बने ट्रैफ़िक की रक्षा करने वाला VPN क्लाइंट आगे भेजे गए ट्रैफ़िक को अपने दायरे से बाहर मान सकता है, या उसे जानबूझकर लीक के रूप में रोक सकता है। दोनों में से कोई व्यवहार बग नहीं है, और दोनों में से कोई उस स्क्रीन पर लिखा नहीं है जहाँ साझेदारी चालू की गई थी। आपके पास कौन-सा है, यह केवल डाउनस्ट्रीम जाँच बताती है।
कई क्लाइंट केवल होस्ट का ट्रैफ़िक आगे भेजते हैं और कुछ नहीं, इसलिए टनल टैबलेट के लिए राउट करेगा यह मानने के बजाय क्लाइंट के दस्तावेज़ों में साझेदारी वाला हिस्सा देखें। दिखने वाला लक्षण वह डिवाइस है जो जुड़ता है, पता पाता है और फिर पहले अनुरोध पर विफल हो जाता है। आगे भेजने से इनकार करने वाला क्लाइंट होस्ट पर फिर भी पूरी तरह स्वस्थ दिखता है।
कौन-सा अडैप्टर साझा है, कौन-सा क्लाइंट की सेवा करता है
दोनों अडैप्टर दर्ज करें, क्योंकि वे अलग पते और अलग फ़िल्टर ले जाते हैं, और गलत अडैप्टर पर किया गया बदलाव कई उलझाने वाले नतीजे समझाता है। साझेदारी वाला होस्ट आम तौर पर डाउनस्ट्रीम तरफ़ एक स्थिर पता लेता है और वहाँ छोटी DHCP और DNS सेवा चलाता है। Windows आगे भेजना वैश्विक रूप से नहीं, हर अडैप्टर के हिसाब से रखता है, इसलिए स्थिति इंटरफ़ेस दर इंटरफ़ेस पढ़नी पड़ती है।
Get-NetAdapter | Where-Object Status -eq 'Up' | Select-Object Name,InterfaceIndex,LinkSpeed
Get-NetIPAddress -AddressFamily IPv4 | Select-Object InterfaceAlias,IPAddress,PrefixLength
Get-NetIPInterface | Select-Object InterfaceAlias,Forwarding,ConnectionState
Get-NetConnectionProfileअगर साझा अडैप्टर पर आगे भेजना अक्षम दिखता है, तो टनल चाहे कुछ भी करे, डाउनस्ट्रीम में कुछ नहीं चलेगा। इसे केवल उसी मशीन पर सक्षम करें जिसकी नीति उसे दूसरे डिवाइसों के लिए राउट करने देती है।
आगे भेजना, अनुवाद और फ़िल्टरिंग
आगे भेजे गए पैकेट को टनल तक पहुँचना है, ऐसी चीज़ में अनूदित होना है जिसे दूर का सिरा स्वीकार करे, और उसी अनुवाद से लौटना है। इन तीनों में से कोई भी चरण टूट सकता है, और हर टूटन ब्राउज़र का वही टाइमआउट पैदा करती है। पैकेट कैप्चर, रूट खोज और दूर के सिरे का लॉग साझेदारी संवाद की एक और समीक्षा से ज़्यादा मूल्यवान हैं। कौन-सा चरण विफल होता है, यही बताता है कि किसका बदलाव चाहिए।
दूर के सिरे को साझा सबनेट के लिए वापसी मार्ग की भी ज़रूरत हो सकती है, ऐसी श्रेणी जो VPN सर्वर ने कभी नहीं देखी। जहाँ क्लाइंट अनुवाद करता है, वहाँ सर्वर केवल टनल का पता देखता है और वापसी मार्ग की ज़रूरत नहीं होती। जहाँ वह अनुवाद नहीं करता, वहाँ गेटवे का मालिक उस मार्ग को जानबूझकर जोड़ता है, और यह क्लाइंट सेटिंग नहीं बल्कि बदलाव का अनुरोध है।
जाँचें क्लाइंट पर करें, होस्ट पर नहीं
हर जाँच उस क्लाइंट पर करें जो विफल हो रहा है, उस होस्ट पर नहीं जो चल रहा है। एग्रेस पता, रिज़ॉल्वर का उत्तर और ऐप्लिकेशन परीक्षण एक ही सत्र में रखें, क्योंकि एक घंटे के अंतर से जुटाए नतीजे तीनों के मिलने के तरीके के बारे में कुछ नहीं कहते।
Resolve-DnsName intranet.example.net -Type A
Resolve-DnsName intranet.example.net -Type AAAA
Invoke-RestMethod https://api.ipify.org
Test-NetConnection intranet.example.net -Port 443 -InformationLevel Detailedएग्रेस पते की तुलना होस्ट के अपने पते से करें और देखें कि दोनों मेल खाते हैं या नहीं। अलग उत्तर का मतलब है कि आगे भेजा गया रास्ता टनल को बायपास करता है, जो तेज़ सुधार नहीं बल्कि मालिक वाला नीति सवाल है। विफल ऐप्लिकेशन के साथ मेल खाता उत्तर काम को नाम हल करने या दूर के सिरे की नीति की ओर ले जाता है। केवल IPv4 नतीजे पर भी न रुकें: साझेदारी हर IPv4 जाँच पास कर सकती है जबकि IPv6 किसी दूसरे एग्ज़िट से बाहर जाता है, इसलिए AAAA रिकॉर्ड और विस्तृत कनेक्शन परीक्षण के साथ नाम और एग्रेस जाँच दोहराएँ।
प्रबंधित मशीन पर पुष्टि करें कि साझेदारी की अनुमति है ही, क्योंकि किसी दूसरे डिवाइस के लिए पहुँच खोलना सुविधा का टॉगल नहीं बल्कि प्रशासनिक फ़ैसला है। किसी भी समर्थित बदलाव के बाद दोबारा जुड़ने पर और फिर किसी रुकावट के दौरान जाँचें दोहराएँ। होस्ट का साफ़ दोबारा जुड़ना उस आगे भेजे गए मार्ग को बहाल नहीं करता जिसे क्लाइंट ने कभी समर्थन नहीं दिया।