VMware अतिथिसँग होस्टको VPN सत्र साझा गर्ने

टनेल एडाप्टर पुलमा जोडिँदैन, र Windows 10 सबनेटबीच रुट गर्दैन। NAT सहितको host-only खण्डले अतिथिलाई बोक्छ।

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

पुलले काम गर्न नसक्ने दुई कारण

क्लाइन्टको एडाप्टरले सामान्यतया एउटा ठेगाना बोक्छ, प्रायः /32, र क्लाइन्टले होस्टका रुट पुनःलेखन गर्छ ताकि सामान्य बाहिरी ट्राफिकले टनेललाई प्राथमिकता दिन्छ। होस्टका अनुप्रयोगहरू त्यो तालिका मान्छन् र निजी प्रणालीमा पुग्छन्। पुल गरिएको अतिथिले तालिका पढ्दै पढ्दैन, किनकि उसका फ्रेम IP तहको तलको स्विचबाट बाहिर जान्छन्।

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

होस्टको स्वामित्वको खण्ड बनाउनुहोस्

भर्चुअल नेटवर्क सम्पादकमा, तपाईंले अन्यत्र कतै रुट नगर्ने प्रिफिक्समा, उदाहरणका लागि 172.28.90.0/24, VMnet3 जस्तो host-only नेटवर्क थप्नुहोस्। होस्टले त्यो एडाप्टरमा 172.28.90.1 लिन्छ र अतिथि त्यही स्विचमा जोडिन्छ। त्यो खण्डमा हाइपरभाइजरको DHCP बन्द गर्नुहोस् ताकि एउटै ठेगाना सेवाले त्यसको स्वामित्व लिन्छ।

त्यसमाथि केही बनाउनु अघि Windows ले इन्टरफेस देख्छ भनी पुष्टि गर्नुहोस्, किनकि सम्पूर्ण डिजाइन त्यो एडाप्टर सामान्य हुनुमा निर्भर छ:

Get-NetAdapter | Format-Table Name, InterfaceDescription, Status
Get-NetIPAddress -AddressFamily IPv4 | Where-Object PrefixLength -eq 24

host-only एडाप्टर त्यहाँ कुनै पनि भौतिक एडाप्टरजस्तै देखिन्छ। कुनैमा पनि जोड्न नसकिने टनेल एडाप्टरसँग ठ्याक्कै यही भिन्नता हो।

अतिथिको प्रिफिक्स अनुवाद गर्नुहोस्

उन्नत सत्र खोलेर प्रिफिक्सको अनुवाद गर्नुहोस्। पहिले के छ त्यो जाँच्नुहोस्, किनकि कन्टेनर रनटाइम र हाइपरभाइजरहरूले आफ्नै अनुवाद स्थापना गर्छन् र गलत हटाउँदा अर्को उत्पादन बिग्रन्छ।

Get-NetNat | Format-Table Name, InternalIPInterfaceAddressPrefix, Active
New-NetNat -Name "LabGuestEgress" -InternalIPInterfaceAddressPrefix 172.28.90.0/24

त्यसपछि अतिथिलाई त्यो प्रिफिक्समा स्थिर ठेगाना, गेटवेको रूपमा 172.28.90.1 र टनेलले होस्टलाई दिने रिजोल्भर ठेगानाहरूसँग कन्फिगर गर्नुहोस्। अनुवादले प्याकेट अगाडि पठाउँछ र अतिथिलाई DNS बारे केही सिकाउँदैन, त्यसैले स्थानीय राउटरमा छाडिएको अतिथिले सार्वजनिक नाम समाधान गर्छ र हरेक आन्तरिक नाममा असफल हुन्छ।

पहिलो हप जाँच्नुहोस्, त्यसपछि मूल्य

नजिकको सीमा परीक्षण गर्नुहोस् अनुप्रयोग परीक्षण गर्नु अघि। होस्टको गेटवेमा रोकिने ट्रेसले अनुवाद भइरहेको छैन भन्ने देखाउँछ, जबकि होस्टभन्दा पर रोकिनेले टनेल बन्द छ वा विपक्षीले अनुवादित ठेगाना अस्वीकार गर्यो भन्ने देखाउँछ।

tracert -d 172.20.31.10
nslookup intranet.corp.example
Get-NetNatSession -NatName "LabGuestEgress"

टनेल चालु हुँदा त्यही गन्तव्यमा होस्टको आफ्नै पहुँचसँग तुलना गर्नुहोस्। होस्ट सफल भएर अतिथि नभए, दोष अनुवादमा वा अतिथिको गेटवे सेटिङमा छ, जडानमा होइन।

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

सम्बन्धित लेखहरू