क्या Hyper-V वर्चुअल मशीन होस्ट का VPN इस्तेमाल करती है? यह स्विच पर निर्भर है

Hyper-V होस्ट पर VPN क्लाइंट स्थापित करें, वहाँ ब्राउज़र खोलें, और निर्गम पता बदल जाता है; वही पृष्ठ वर्चुअल मशीन के भीतर खोलें तो वह पुराना पता दिखा सकता है, या कुछ भी नहीं। सामान्य निष्कर्ष यह होता है कि वर्चुअल मशीन खराब है, या स्प्लिट टनलिंग चालू करनी होगी। इनमें से कोई भी नहीं निकलता। VPN क्लाइंट मशीन का गुण नहीं है; वह मार्गों का समूह, एक वर्चुअल एडाप्टर और अक्सर विशिष्ट इंटरफ़ेस से जुड़ा फ़िल्टर है। अतिथि यातायात कभी उस तंत्र से मिलेगा या नहीं, यह इस पर निर्भर है कि अतिथि कौन-सा वर्चुअल स्विच इस्तेमाल करता है।

मिथक, सीधे शब्दों में

मान्यता यह है कि होस्ट पर स्थापित VPN पूरी मशीन की रक्षा करता है, वर्चुअल मशीनों सहित, क्योंकि वर्चुअल मशीन उसी मशीन पर चलने वाली एक प्रक्रिया मात्र है। यह सुविधाजनक मान्यता है, क्योंकि एंटीवायरस और होस्ट फ़ायरवॉल आमतौर पर ऐसा ही व्यवहार करते हैं। नेटवर्क मार्ग नहीं।

अतिथि के फ़्रेम को होस्ट का VPN स्टैक तभी छूता है जब होस्ट उसे रूट या फ़िल्टर करता है। इस वाक्य को स्टिकी नोट पर लिख लें, क्योंकि नीचे का हर मामला उसी का रूपांतर है।

तीन प्रकार के स्विच, तीन मार्ग

बाहरी स्विच एक वर्चुअल एडाप्टर को भौतिक नेटवर्क कार्ड से जोड़ता है, और अतिथि अपने MAC पते के साथ उसी बंधन से फ़्रेम भेजता है। अतिथि भौतिक नेटवर्क पर समकक्ष बन जाता है, अपनी DHCP लीज़, गेटवे और DNS सर्वर के साथ। होस्ट का VPN डिफ़ॉल्ट मार्ग होस्ट स्टैक में रहता है और उन फ़्रेमों को नहीं हिलाता, क्योंकि वे होस्ट से रूट होने के बजाय ब्रिज होते हैं। इसीलिए Wi-Fi एडाप्टर पर बाहरी स्विच बुरा विचार है: अधिकांश वायरलेस ड्राइवर दूसरे MAC पते के लिए फ़्रेम नहीं ले जाते।

आंतरिक स्विच अतिथियों को होस्ट के वर्चुअल एडाप्टर से जोड़ता है। अकेला यह कोई इंटरनेट निर्गम नहीं देता; होस्ट पर NAT ऑब्जेक्ट अनुवाद देता है, जैसा कि Hyper-V NAT गाइड में वर्णित है। अब अतिथि के पैकेट वास्तव में होस्ट के रूटिंग और NAT मार्ग में प्रवेश करते हैं, इसलिए VPN क्लाइंट के मार्ग और फ़िल्टर फिर मायने रखते हैं। यही वह व्यवस्था है जिसमें वर्चुअल मशीन सचमुच होस्ट के VPN का अनुसरण करती है, और जिसमें किल स्विच अतिथि को पूरी तरह काट सकता है।

निजी स्विच में होस्ट एडाप्टर नहीं होता और कोई अपलिंक नहीं होता। अतिथि केवल एक-दूसरे से बात करते हैं और किसी और से नहीं, इसलिए यदि निजी स्विच पर वर्चुअल मशीन के पास इंटरनेट नहीं है, तो गायब राउटर कारण है और VPN अप्रासंगिक है।

डिफ़ॉल्ट स्विच अपनी अलग व्यवस्था है

Windows एक डिफ़ॉल्ट स्विच देता है जो आंतरिक स्विच को NAT और DNS प्रॉक्सी के साथ जोड़ता है। उसका सबनेट होस्ट चुनता है, रीस्टार्ट के बाद बदल सकता है, और वह आपके द्वारा बनाए गए NAT नेटवर्क जैसा वही ऑब्जेक्ट नहीं है। उसे प्रयोगशाला नेटवर्क मानकर फिर से बनाना ही वह तरीका है जिससे लोग दो NAT और अब भी मार्ग-रहित अतिथि तक पहुँचते हैं।

यदि वर्चुअल मशीन डिफ़ॉल्ट स्विच पर है, तो अतिथि को मिला पता पढ़ें और VPN क्लाइंट को छूने से पहले उसकी तुलना होस्ट की NAT तालिका से करें। अतिथि के गेटवे और NAT प्रीफ़िक्स के बीच असंगति किसी भी क्लाइंट सेटिंग से अधिक विफलताएँ समझाती है।

प्रश्न तय करने वाले चार तथ्य

कुछ भी बदलने से पहले ये जुटाएँ: स्विच का प्रकार और उसका अपलिंक, वर्चुअल मशीन से जुड़ा एडाप्टर, अतिथि का अपना पता, गेटवे और DNS, और होस्ट की NAT तथा डिफ़ॉल्ट मार्ग की स्थिति। केवल पढ़ने वाले कमांड हैं Get-VMSwitch, Get-VMNetworkAdapter -VMName "TestVM", Get-NetNat, और Get-NetRoute -DestinationPrefix 0.0.0.0/0; और अतिथि के भीतर ipconfig /all बाकी देता है।

फिर तय करें कि अतिथि को क्या करना चाहिए। यदि उसे VPN के बाहर रहना है, तो ठीक उसी मार्ग के लिए प्रदाता की समर्थित छूट लें, क्योंकि होस्ट की एक्ज़ीक्यूटेबल फ़ाइल को छोड़ने से अग्रेषित वर्चुअल मशीन यातायात छूट नहीं पाता। यदि उसे VPN इस्तेमाल करना है, तो यह मानने के बजाय कि होस्ट ब्राउज़र का परीक्षण इसे ढक लेता है, क्लाइंट के दस्तावेज़ीकृत वर्चुअल मशीन यातायात व्यवहार की पुष्टि करें।

अतिथि के भीतर का परीक्षण ही एकमात्र सबूत है जो मायने रखता है। अतिथि से निर्गम पता जाँचें, कोई आंतरिक नाम हल करें, VPN फिर से जोड़ें और दोहराएँ। होस्ट के ब्राउज़र का नतीजा इनमें से किसी का विकल्प नहीं है।

मिथक की कीमत

लोग सिर्फ़ परीक्षण पास कराने के लिए किल स्विच बंद करते हैं, स्थिर मार्ग जोड़ते हैं, या स्विच मिटाकर फिर बनाते हैं। हर शॉर्टकट विफलता का तरीका बदल देता है: अतिथि ऐसे मार्ग से इंटरनेट तक पहुँच सकता है जिसकी किसी ने योजना नहीं बनाई, या बाहरी स्विच के अपना भौतिक कार्ड फिर से जोड़ने पर होस्ट कनेक्टिविटी खो सकता है।

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

टिकाऊ उत्तर इन्वेंटरी में हर वर्चुअल मशीन के लिए एक पंक्ति है: वह कौन-सा स्विच इस्तेमाल करती है और उसका गेटवे कौन-सा घटक देता है। यह लिख लेने के बाद अगला VPN बदलाव दोपहर भर के अनुमान के बजाय एक नज़र डालना है।