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 रेकॉर्ड आणि तपशीलवार कनेक्शन चाचणीसह नाव आणि एक्झिट तपासण्या पुन्हा करा।
व्यवस्थापित मशीनवर शेअरिंगला अजिबात परवानगी आहे का ते खात्री करा, कारण दुसऱ्या उपकरणासाठी प्रवेश उघडणे ही सोयीची टॉगल नाही तर प्रशासकीय निर्णय आहे। कोणत्याही समर्थित बदलानंतर पुन्हा जोडणीच्या वेळी आणि नंतर व्यत्ययाच्या काळात तपासण्या पुन्हा करा। होस्ट स्वच्छपणे पुन्हा जोडला गेला तरी क्लायंटने कधीही समर्थन न दिलेला पुढे पाठवलेला मार्ग परत येत नाही।