भर्चुअल मेसिनमा 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 लाई छुट्टै दर्ता गर्न भन्छ भने यहीँ रोक्नुहोस् र त्यसको सट्टा त्यही मोडेल प्रयोग गर्नुहोस्, किनकि साझा फर्वार्डिङ बिन्दुले पहुँच एकै गेस्टमा केन्द्रित गर्छ। जे भए पनि, ठेगाना र पोर्ट परिवर्तन अभिलेखमा राख्नुहोस्; अर्को व्यक्तिले ती फेरि पत्ता लगाउन चाहने छैन।