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 रेकर्ड र विस्तृत जडान परीक्षणसँग नाम र इग्रेस जाँच दोहोर्याउनुहोस्।

व्यवस्थित मेसिनमा साझेदारीलाई पटक्कै अनुमति छ कि भनी पुष्टि गर्नुहोस्, किनकि अर्को उपकरणमा पहुँच खोल्नु सुविधाको टगल होइन, प्रशासनिक निर्णय हो। कुनै पनि समर्थित परिवर्तनपछि जाँचहरू पुनः जोडिने बेला र फेरि अवरोधका क्रममा दोहोर्याउनुहोस्। होस्ट सफा रूपमा पुनः जोडिए पनि क्लाइन्टले कहिल्यै समर्थन नगरेको अगाडि पठाइएको मार्ग फर्कंदैन।