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"

टनेल चालू असताना त्याच गंतव्याकडे होस्टच्या स्वतःच्या प्रवेशाशी तुलना करा। होस्ट यशस्वी होऊन अतिथी न झाल्यास, दोष भाषांतरात किंवा अतिथीच्या गेटवे सेटिंगमध्ये आहे, जोडणीत नाही।

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

संबंधित लेख