VPN होस्टमा चलाउने कि VM भित्र? निर्णय निर्देशिका
टनेलको मालिकले के के ढाक्छ भनेर निर्णय गर्छ। होस्ट वा अतिथिमा स्थान छान्नुहोस्, त्यसपछि अतिथिभित्र मार्ग, DNS र निकास जाँचद्वारा पुष्टि गर्नुहोस्।
अतिथिभित्र टनेल बनाउनु र त्यसलाई होस्टमा बनाउनु—दुवैले ब्राउजरले जानकारी दिने ठेगाना बदल्छन्, र समानता त्यहीँ सकिन्छ। अतिथिको स्वामित्वको टनेलले आफ्ना कुञ्जी, आफ्नो पूर्वनिर्धारित मार्ग र आफ्नो समाधानकर्ता अतिथिको कर्नेलभित्र राख्छ, जबकि होस्टले इन्क्रिप्ट गरिएका प्याकेट एक दूरको ठेगानामा पठाउँछ। होस्टको स्वामित्वको टनेल त्यसको उल्टो चित्र हो: होस्ट क्लाइन्टले सत्र राख्छ र मार्ग तथा नीति लागू गर्छ, र अतिथिले बाहिर आउने कुरा ऋण लिन्छ। गलत मालिक छान्नुभयो भने पछिको हरेक लक्षणले तपाईंलाई गलत मेसिनमा पुर्याउँछ। दुई आदेशले यो प्रश्न करिब एक मिनेटमा टुंग्याउँछन्, र यो निर्देशिकाको बाँकी भाग उत्तरसँग के गर्ने भन्ने हो।
क्लाइन्ट छुनुअघि मालिक निर्धारण गर्नुहोस्
नियम साइफरटेक्स्ट कहाँ उत्पादन हुन्छ भन्नेबारे हो, कुन मेसिनले VPN आइकन देखाउँछ भन्नेबारे होइन। अतिथिले त्यो उत्पादन गर्छ भने अतिथिलाई VPN सर्भरसम्म काम गर्ने मार्ग चाहिन्छ र होस्टबाट अरू केही चाहिँदैन। होस्टले त्यो उत्पादन गर्छ भने होस्ट क्लाइन्टले स्थानीय ट्राफिकमा लाद्ने जुनसुकै नीतिको बाबजुद अतिथिको होस्ट-मार्ग टिक्नुपर्छ।
सामान्यतया तीन प्रश्नले तपाईंका लागि स्थान छान्छन्। अतिथिको ट्राफिकले होस्टमा रहेको कर्पोरेट क्लाइन्ट पार गर्नुपर्छ? त्यसो भए टनेल अतिथिभित्र छ। धेरै अतिथिलाई एउटै प्रमाणपत्र र एउटै निकास ठेगाना चाहिन्छ? त्यसो भए त्यो होस्टमा छ, फर्वार्डिङ जानाजान मिलाइएको। अतिथिको ट्राफिक होस्टको VPN बाहिरै रहनुपर्छ? त्यसो भए अतिथिभित्रको टनेल मात्र त्यस्तो व्यवस्था हो जसले यो बनावटैले दिन्छ।
उत्तर VM को नामको छेउमा एक हरफमा लेख्नुहोस्: guest-owned वा host-owned। छ मेसिनको प्रयोगशालामा त्यो टिप्पणीले तलका कुनै पनि चरणभन्दा बढी समय बचाउँछ, किनकि तपाईंले लगइन गरेको मेसिनमा कहिल्यै नभएको टनेल जाँच्नबाट यसले रोक्छ।
WSL1 र WSL2 विपरीत केस हुन्
WSL1 भर्चुअल मेसिन होइन, त्यसैले स्थानको प्रश्न धेरै हदसम्म हराउँछ। यसका Linux बाइनरीहरू अनुवाद तहमार्फत Windows को नेटवर्क स्ट्याकविरुद्ध चल्छन्, र Linux VPN क्लाइन्टसँग मिलाउन स्वतन्त्र इन्टरफेस हुँदैन। काम गर्ने व्यवस्था Windows पट्टिको टनेल हो, र वितरणले केही पनि स्वामित्व नलिई नतिजा प्रयोग गर्छ।
WSL2 यसको उल्टो हो। यसले Hyper-V भर्चुअल स्विचको पछाडि हल्का युटिलिटी VM मा साँचो कर्नेल चलाउँछ, र यसको ठेगाना-स्थान होस्ट पट्टिको एडाप्टरमार्फत NAT हुन्छ। त्यसैले वितरणभित्रको Linux क्लाइन्ट भौतिक Linux बाकसमा जस्तै व्यवहार गर्छ: यसले 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 र दुवै ठेगाना-परिवार अतिथिभित्र समाधान हुन्छन्, मृत टनेलले कालो प्वालको सट्टा प्रयोगयोग्य नेटवर्क छोड्छ, र रिबुट वा स्न्यापसट पुनर्स्थापनाले त्यही अवस्था पुनः उत्पादन गर्छ।