VPN होस्ट पर चलाएँ या VM के भीतर? निर्णय मार्गदर्शिका
टनल का मालिक तय करता है कि क्या क्या ढकता है। होस्ट या अतिथि में स्थान चुनें, फिर अतिथि के भीतर रूट, DNS और निकास जाँच से उसकी पुष्टि करें।
अतिथि के भीतर टनल बनाना और उसे होस्ट पर बनाना—दोनों ब्राउज़र जो पता बताता है उसे बदल देते हैं, और समानता वहीं खत्म होती है। अतिथि के स्वामित्व वाली टनल अपनी कुंजियाँ, अपना डिफ़ॉल्ट रूट और अपना रिज़ॉल्वर अतिथि कर्नेल के भीतर रखती है, जबकि होस्ट एन्क्रिप्टेड पैकेट एक दूरस्थ पते पर भेजता है। होस्ट के स्वामित्व वाली टनल उसका दर्पण-चित्र है: होस्ट क्लाइंट सत्र रखता है और रूट तथा नीति लागू करता है, और अतिथि जो बाहर आता है उसे उधार लेता है। गलत मालिक चुनें और हर बाद का लक्षण आपको गलत मशीन पर भेजेगा। दो आदेश यह सवाल लगभग एक मिनट में तय कर देते हैं, और इस मार्गदर्शिका का बाकी हिस्सा यह है कि उत्तर के साथ क्या करें।
क्लाइंट को छूने से पहले मालिक तय करें
नियम इस बारे में है कि सिफ़रटेक्स्ट कहाँ बनता है, इस बारे में नहीं कि कौन-सी मशीन VPN आइकन दिखाती है। अगर अतिथि उसे बनाता है, तो अतिथि को VPN सर्वर तक काम करने वाला रूट चाहिए और होस्ट से और कुछ नहीं। अगर होस्ट उसे बनाता है, तो होस्ट क्लाइंट स्थानीय ट्रैफ़िक पर जो भी नीति थोपता है, अतिथि का होस्ट-मार्ग उसके बावजूद टिकना चाहिए।
तीन सवाल आमतौर पर आपके लिए स्थान चुन लेते हैं। क्या अतिथि के ट्रैफ़िक को होस्ट पर किसी कॉर्पोरेट क्लाइंट से बचना है? तो टनल अतिथि के भीतर है। क्या कई अतिथियों को एक क्रेडेंशियल और एक निकास पता चाहिए? तो वह होस्ट पर है, फ़ॉरवर्डिंग जानबूझकर सेट की गई। क्या अतिथि के ट्रैफ़िक को होस्ट के VPN से पूरी तरह बाहर रहना है? तो अतिथि-टनल ही वह एकमात्र व्यवस्था है जो यह रचना से ही देती है।
उत्तर को VM के नाम के बगल में एक पंक्ति में लिखें: guest-owned या host-owned। छह मशीनों की लैब में वह नोट नीचे के किसी भी कदम से अधिक समय बचाता है, क्योंकि यह आपको ऐसी टनल की समस्या खोजने से रोकता है जो उस मशीन में कभी थी ही नहीं जिसमें आपने लॉगिन किया।
WSL1 और WSL2 विपरीत मामले हैं
WSL1 वर्चुअल मशीन नहीं है, इसलिए स्थान का सवाल ज़्यादातर वाष्पित हो जाता है। इसकी लिनक्स बाइनरियाँ अनुवाद परत के ज़रिए Windows के नेटवर्क स्टैक के सामने चलती हैं, और लिनक्स VPN क्लाइंट के पास कॉन्फ़िगर करने के लिए कोई स्वतंत्र इंटरफ़ेस नहीं होता। जो व्यवस्था काम करती है वह Windows की ओर टनल है, जिसमें डिस्ट्रिब्यूशन बिना कुछ स्वामित्व के परिणाम का उपयोग करता है।
WSL2 इसका उल्टा है। यह Hyper-V वर्चुअल स्विच के पीछे एक हल्के यूटिलिटी VM में असली कर्नेल चलाता है, और उसका पता-स्थान होस्ट की ओर के एडाप्टर से NAT होता है। इसलिए डिस्ट्रिब्यूशन के भीतर का लिनक्स क्लाइंट वैसा ही व्यवहार करता है जैसा भौतिक लिनक्स बॉक्स पर करता: यह tun0 या wg0 बनाता है, अपने रूट लगाता है, और काम करता है। विफलता होस्ट की ओर रहती है। जब Windows VPN क्लाइंट ऐसी नीति के साथ जुड़ता है जो स्थानीय नेटवर्क पर ट्रैफ़िक रोकती है, तो वह WSL2 सबनेट को अविश्वसनीय स्थानीय नेटवर्क मानकर NAT मार्ग काट देता है। फिर डिस्ट्रिब्यूशन DNS और बाहरी पहुँच खो देता है जबकि उसकी अपनी टनल अभी स्वस्थ है: wg show हैंडशेक बताता है, ip route ठीक दिखता है, और curl अटक जाता है।
कौन-सा उपाय इस्तेमाल कर सकते हैं यह Windows बिल्ड पर निर्भर है। पुराना वाला WSL सबनेट के लिए होस्ट क्लाइंट में एक अपवाद है, जो क्लाइंट की स्थानीय-नेटवर्क या विभाजित-टनल सेटिंग्स के अंतर्गत जोड़ा जाता है। नया वाला, जो Windows 11 बिल्ड जहाँ इसे समर्थन देते हैं, मिरर नेटवर्किंग है: %UserProfile%\.wslconfig के [wsl2] खंड में networkingMode=mirrored रखें, wsl --shutdown चलाएँ, और डिस्ट्रिब्यूशन निजी NAT सबनेट के बजाय होस्ट के इंटरफ़ेस साझा करेगा। मिरर मोड localhost और आने वाले पोर्ट का व्यवहार भी बदलता है, इसलिए इसे टॉगल नहीं, माइग्रेशन मानें।
NAT, ब्रिज और होस्ट क्या देख सकता है
NAT के अंतर्गत अतिथि के टनल पैकेट VPN सर्वर के सार्वजनिक पते पर भेजे जाते हैं और एन्क्रिप्टेड UDP या TCP के रूप में होस्ट एडाप्टर से निकलते हैं। होस्ट एक प्रवाह और उसकी बाइट-गिनती देखता है, भीतर के गंतव्यों के बारे में कुछ नहीं। ब्रिज्ड एडाप्टर के अंतर्गत अतिथि की भौतिक LAN पर अपनी 2-स्तरीय पहचान होती है, वह अपना DHCP लीज़ लेता है, और MAC-आधारित किसी भी नीति के सामने दूसरे उपकरण जैसा दिखता है। कोई भी मोड होस्ट को टनल का पेलोड पढ़ने नहीं देता; ब्रिज्ड अतिथि बस अपने आसपास के नेटवर्क के लिए बहुत अधिक दृश्यमान है।
अलगाव की भी एक निचली सीमा है। अतिथि उस मशीन से छिप नहीं सकता जो उसकी मेमोरी की मालिक है, और जो होस्ट नियंत्रित करता है वह अतिथि की RAM से कुंजियाँ पढ़ सकता है। अतिथि-टनल आपको रूटिंग सीमा और मैलवेयर सीमा देती है, लैपटॉप थामे बैठे व्यक्ति से सुरक्षा नहीं। प्रलेखित एडाप्टर मोड चुनते समय खुले रखना उचित है, क्योंकि मोड होस्ट क्या देखता है और LAN क्या देखता है दोनों बदल देता है।
मार्गदर्शिका: रखें, कॉन्फ़िगर करें, सिद्ध करें
इन चार जाँचों को क्रम में एक नए अतिथि शेल में चलाएँ, और उस पहली जाँच पर रुकें जो आपके लिखे मालिक से मेल न खाए।
ip route get 1.1.1.1काtun0याwg0लौटाना अतिथि-स्वामित्व है, और निजी अगले हॉप के साथeth0लौटना होस्ट-स्वामित्व है।resolvectl query example.com, या जहाँ अतिथि कोई रिज़ॉल्वर सेवा नहीं चलाता वहाँ/etc/resolv.confपढ़ें। जो टनल ट्रैफ़िक ढोती है पर DNS नहीं, वही सबसे आम आधा-कॉन्फ़िगर किया गया राज्य है।- निकास की तुलना करें: अतिथि में
curl -4 -s https://ifconfig.meऔर होस्ट परcurl.exe -4 -s https://ifconfig.me। अलग पते का अर्थ है अतिथि टनल का मालिक है, और VPN पर होस्ट के साथ घर का ISP दिखाता अतिथि वह स्थिति है जिसमें कुछ भी विरासत में नहीं मिला। - दोनों को
-6के साथ दोहराएँ। केवल-v4 टनल v6 लीक करती है जब तक क्लाइंट उसे रोके या रूट न करे, और कई क्लाइंट डिफ़ॉल्ट रूप से v6 को भौतिक इंटरफ़ेस पर छोड़ देते हैं।
होस्ट-गेटवे डिज़ाइन में, जहाँ कई अतिथि एक टनल साझा करते हैं, होस्ट को फ़ॉरवर्ड और अनुवाद करना पड़ता है। Linux होस्ट पर वे तीन टुकड़े हैं, और इनमें से कोई भी न हो तो अतिथि चुपचाप अपने सामान्य रूट पर लौट जाता है:
sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -o wg0 -j MASQUERADE
iptables -A FORWARD -i virbr0 -o wg0 -j ACCEPT
iptables -A FORWARD -i wg0 -o virbr0 -m state --state RELATED,ESTABLISHED -j ACCEPTWireGuard की ओर होस्ट पीयर के AllowedIPs में अतिथि सबनेट शामिल होना चाहिए, जैसे 192.168.122.0/24, वरना वापसी पैकेट कभी नहीं पहुँचते और सेटअप फ़ायरवॉल समस्या जैसा दिखता है। Windows होस्ट Internet Connection Sharing या Hyper-V स्विच पर NAT नियम से वही परिणाम पाता है, और उसे भी वही वापसी-मार्ग जाँच चाहिए।
जब लेआउट अभी खुला है, यह तालिका सबसे आम व्यवस्थाओं को ढकती है:
| Situation | Owner | Check first |
|---|---|---|
| One VM, host also on a corporate VPN | Guest | Does the host client block local networks? |
| Six lab VMs, one exit address | Host plus forwarding | ip_forward, NAT rule, server AllowedIPs |
| Malware or research VM | Guest, NAT | Snapshot age and resolver state |
| Bridged VM on an office LAN | Guest | DHCP lease and port security |
दो टनल, दो अतिथि, और उनके बीच के टकराव
जब आपको एक साथ दो निकास चाहिए, तो टिकने वाला पैटर्न है प्रति अतिथि एक टनल। हर VM अपना डिफ़ॉल्ट रूट और रिज़ॉल्वर रखता है, होस्ट सामान्य नेटवर्क पर रहता है, और दोनों टनल कभी एक ही रूटिंग तालिका पर नहीं झगड़तीं। दो अतिथियों को ब्रिज से जोड़ना भी उनके रूट नहीं मिलाता: वर्चुअल नेटवर्क एक मार्ग देता है, और हर क्लाइंट को अब भी बताना पड़ता है कि यह स्थानीय ट्रैफ़िक टनल को बायपास कर सकता है।
होस्ट टनल और अतिथि टनल को साथ चलाना वैध है, और जानबूझकर नेस्टिंग कभी-कभी ठीक वही होती है जो आप चाहते हैं—अतिथि अपनी टनल से बाहर जाता है और वह टनल होस्ट की टनल से बाहर जाती है। इसे कटौती में बदल देता है यह कि किसी ने नहीं लिखा कि कौन-सा अंतिम बिंदु किस परत से पहुँचना है। गंतव्य और मालिक की दो-स्तंभ सूची रखें, और रूट टकराव एक दोपहर की खोज के बजाय एक खोज बन जाता है।
सत्यापित करें, फिर वसूली मालिक के पास रखें
अतिथि के भीतर से परीक्षण करें एक नई एप्लिकेशन प्रक्रिया के साथ: ट्रैफ़िक, नाम-समाधान, दोनों पता-परिवार, और टनल गिरने पर क्या होता है। होस्ट का VPN आइकन अतिथि के कवरेज के बारे में कुछ नहीं कहता, और इस पूरे क्षेत्र में यही सबसे आम झूठी पुष्टि है।
वसूली भी मालिक की है। अतिथि-स्वामित्व वाली टनल अतिथि के अपने क्लाइंट और उसके लिखे रूट से बहाल होती है। होस्ट-स्वामित्व वाला डिज़ाइन होस्ट के बूट-क्रम से बहाल होता है, और फ़ॉरवर्डिंग नियम रीबूट में नहीं टिकते जब तक कोई unit या स्टार्टअप कार्य उन्हें फिर से लागू न करे। बहाल किया गया स्नैपशॉट एक परिनियोजन है, पूर्ववत नहीं, क्योंकि वह डिस्क के साथ पुराने क्रेडेंशियल और पुराने रूट वापस लाता है। काम पूरा कहने से पहले पुष्टि करें कि मालिक अब भी आपकी लिखी पंक्ति से मेल खाता है, DNS और दोनों पता-परिवार अतिथि के भीतर हल होते हैं, मृत टनल काले छेद के बजाय उपयोगी नेटवर्क छोड़ती है, और रीबूट या स्नैपशॉट बहाली वही स्थिति दोबारा पैदा करती है।