व्हर्च्युअल मशीनमध्ये VPN द्वारे खाजगी सेवेपर्यंत कसे पोहोचावे

पाहुणा आणि Mac यांना एका अरुंद दाराने जोडलेले दोन वेगळे नेटवर्क माना। व्हर्च्युअल मशीन तिचा VPN क्लायंट आणि स्वतःचा इंटरनेट मार्ग ठेवते; Mac फक्त-होस्ट अडॉप्टर आणि एकाच फॉरवर्ड केलेल्या पोर्टमधून नेमकी एका सेवेपर्यंत पोहोचतो। दुसरे काहीही पार जाऊ नये। पायऱ्या क्रमाने पाळा आणि एखादी अयशस्वी झाल्यास थांबा, कारण प्रत्येक पुढील पायरी आधीच्या टिकल्या आहेत असे गृहीत धरते।

काहीही बदलण्यापूर्वी दोन्ही मार्ग नोंदवा

पाहुण्यावर, ipconfig /all VPN वाहतूक वाहणारा अडॉप्टर आणि व्हर्च्युअल नेटवर्कच्या DHCP कडून मिळालेला पत्ता दाखवतो। Mac वर, हायपरव्हायझरने त्या विभागासाठी तयार केलेला व्हर्च्युअल इंटरफेस नोंदवा; VMware Fusion मध्ये फक्त-होस्ट उपकरण सहसा vmnet1 असते, आणि Parallels आपले नाव देते। तिथे कोण पत्ते वाटतो ते पहा, मग सर्व लिहून ठेवा, कारण व्हर्च्युअल नेटवर्क पुन्हा तयार झाल्यावर फक्त-होस्ट सबनेट अनेकदा पुन्हा वाटले जाते। व्हर्च्युअल मशीनचा नेटवर्क मोड हायपरव्हायझरमध्ये तपासा, तुमच्या स्मरणात नाही। इंटरनेटकडील अडॉप्टरसाठी सामायिक किंवा NAT मोड आणि Mac कडील अडॉप्टरसाठी फक्त-होस्ट मोड हीच या पायऱ्या गृहीत धरतात ती रचना।

दोन अडॉप्टर, दोन हेतू। एकच अडॉप्टर Mac आणि इंटरनेट दोन्हींना सेवा देईल अशा पद्धतीने ते मिसळणे हेच अरुंद दाराला राउट केलेला मार्ग बनवते।

प्रथम पाहुण्याचे स्वतःचे VPN सुनिश्चित करा

Windows च्या आत क्लायंट सुरू करा आणि तो संपतो याची खात्री करा, विक्रेता जो कोणताही चाचणी नोंदवतो ती वापरून। पाहुणा एकटाच खाजगी सेवेपर्यंत पोहोचेपर्यंत पुढे जाऊ नका, कारण तुटलेल्या टनेलवर थर चढलेल्या फॉरवर्डिंग समस्येला दोन कारणे असतात आणि कोणताही उपयुक्त त्रुटी संदेश मिळत नाही। सेवा पाहुण्याच्या आतून कोणत्या खाजगी पत्त्यावर सोडवली जाते ते नोंदवा। फॉरवर्डिंग नियमाने फक्त तोच पत्ता नमूद करावा।

क्लायंट पूर्ण टनेल ढकलत असेल, तर फक्त-होस्ट अडॉप्टर तरीही स्थानिक रहदारी वाहतो, पण खाजगी गंतव्य टनेलने त्याचा पत्ता बदलणाऱ्या पद्धतीने पकडले नाही याची खात्री करा। विभाजित टनेल प्रोफाइल हे सोपे करते आणि VPN च्या मालकाकडे ते मागणे योग्य आहे।

फक्त-होस्ट पायरी जोडा आणि ती एकटीच तपासा

पाहुण्याला फक्त-होस्ट अडॉप्टर जोडा, इतर काहीही वापरत नसलेल्या सबनेटवर त्याला स्थिर पत्ता द्या, आणि Mac त्याला ping करू शकतो याची खात्री करा। VPN जोडलेले आणि तुटलेले अशा दोन्ही स्थितीत तपासा, कारण पत्त्याला दोन्ही टिकून राहावे लागते। फक्त त्याचे टनेल वर असतानाच उत्तर देणाऱ्या पाहुण्याला अशी राउटिंग समस्या आहे जी तुम्हाला अजून सापडली नाही।

Windows नवीन अडॉप्टरला सार्वजनिक नेटवर्क म्हणून वर्गीकृत करू शकते, ज्यामुळे डीफॉल्टनुसार येणारी रहदारी अडवली जाते। इतर काहीही डीबग करण्यापूर्वी प्रोफाइल सेट करा।

एक पोर्ट फॉरवर्ड करा, सबनेट नाही

सामान्य IP फॉरवर्डिंगपेक्षा एक फॉरवर्ड केलेला पोर्ट पसंत करा। Windows netsh interface portproxy देतो, जो ऐकणारा पोर्ट गंतव्य होस्ट आणि पोर्टकडे फॉरवर्ड करतो, आणि त्यासाठी IP Helper सेवा सुरू असणे आवश्यक आहे।

listenaddress नेहमी फक्त-होस्ट पत्त्यावर सेट करा। तो वगळल्यास सर्व इंटरफेस बांधले जातात, ज्यामुळे सेवा व्हर्च्युअल मशीन ज्या नेटवर्कवर असेल त्या सर्वांसमोर उघडी होते। फक्त-होस्ट इंटरफेस आणि त्या एकाच पोर्टपुरता मर्यादित फायरवॉल नियम जोडा, जेणेकरून ऐकणारा आणि परवानगी जुळतील। प्रॉक्सी समजणारे अनुप्रयोग पाहुण्याच्या आत लहान प्रॉक्सी मागू शकतात, जे कनेक्शन संपवते आणि Mac कडे परतीचा मार्ग आवश्यक नसतो। प्रोटोकॉल परवानगी देत असेल तर प्रॉक्सी निवडा, कारण ती तिच्या रचनेमुळे बंद होऊन अयशस्वी होते।

तपासा, नंतर रोलबॅक लिहा

Mac वरून खाजगी नाव सोडवा, इच्छित क्रिया चालवा, नंतर पाहुण्याचे VPN थांबवा आणि क्रिया शांतपणे मागे न पडता अयशस्वी होते याची खात्री करा। तीच शेवटची तपासणी मार्ग तुम्ही बांधलेला आहे हे सिद्ध करते। गेटवे कोणती ओळख पाहतो आणि कोणाला फॉरवर्ड वापरण्याची परवानगी आहे ते नोंदवा।

रोलबॅक तीन पायऱ्यांत लिहा: portproxy नोंद काढा, फायरवॉल नियम काढा, फक्त-होस्ट अडॉप्टर वेगळा करा। नंतर तो गरजेपूर्वी एकदा चालवा आणि पाहुण्याचे स्वतःचे VPN त्यानंतरही चालते याची खात्री करा। तुमची संस्था प्रत्येक Mac ची स्वतंत्र नोंदणी मागत असेल, तर इथेच थांबा आणि त्याऐवजी तेच मॉडेल वापरा, कारण सामायिक फॉरवर्डिंग बिंदू प्रवेश एका पाहुण्यावर केंद्रित करतो। कोणत्याही परिस्थितीत पत्ते आणि पोर्ट बदल नोंदीत ठेवा; पुढच्या व्यक्तीला ते पुन्हा शोधायचे नसतील।