होस्टको VPN जोडिँदा Hyper-V पाहुना DNS गुमाउँछ
पाहुना VM होस्टको सुरुङलाई वंशानुगत रूपमा पाउँदैन। स्विच वा NAT मोड पत्ता लगाउनुहोस्, जहाँ प्रस्ताव गरिन्छ त्यहाँ VPN एडाप्टर साझा गर्नुहोस्, र जहाँ गरिँदैन त्यहाँ पोर्टहरू अगाडि बढाउनुहोस्।
पाहुना आज बिहान ठीक थियो। त्यसपछि होस्टले Cisco AnyConnect सुरु गर्यो र VM ले DNS, डोमेन विश्वास र साझा फोल्डर गुमायो, भित्र केही नबदलेको अवस्थामा। होस्ट सुरुङ र पाहुना सञ्जाल छुट्टाछुट्टै बाटा हुन्, र एउटा जोड्दा अर्को सर्दैन। पाहुनाको भित्रबाट बाहिर काम गर्नुहोस्, र केही परिवर्तन गर्नुअघि देखेको कुरा लेख्नुहोस्।
पाहुनाले अझै के देख्न सक्छ
VM मा ठेगाना, पूर्वनिर्धारित गेटवे र रिजोल्भर होस्ट जोडिनुअघि एक पटक र त्यसपछि एक पटक रेकर्ड गर्नुहोस्। ठेगाना राखेर नाम विश्लेषण मात्र गुमाएको पाहुनालाई रिजोल्भर समस्या हुन्छ। कहिल्यै मार्ग नभएको पाहुनालाई बाटो समस्या हुन्छ, र दुवैलाई फरक काम चाहिन्छ। होस्टबाट तपाईं तिनलाई छुट्याउन सक्नुहुन्न, त्यसैले पढाइ भित्रबाटै आउनुपर्छ।
ती तीन पढाइ, दुई पटक लिइएका, तपाईंको आधाररेखा हुन्। त्यसपछिको सबै तिनैसँग मापन गरिन्छ।
पाहुनाले कुन निकास प्रयोग गर्दैछ
Hyper-V ले यसलाई दुई आदेशले जवाफ दिन्छ: Get-VMSwitch स्विचहरू सूचीबद्ध गर्छ, र Get-VMNetworkAdapter -VMName TestVM पाहुना जुनसँग जोडिएको छ त्यो देखाउँछ। Default Switch Windows ले व्यवस्थापन गर्ने NAT सञ्जाल हो; बाह्य स्विचले ट्राफिक भौतिक एडाप्टरलाई दिन्छ; आन्तरिक स्विचले कसैले NAT वा राउटर नथपेसम्म केही बोक्दैन। VirtualBox ले ती तीनै अवधारणा NAT, NAT Network र bridged को रूपमा प्रस्तुत गर्छ।
होस्ट सुरुङलाई सामान्यतः महत्व हुन सक्छ कि भन्ने मोडले निर्धारण गर्छ। NAT पाहुनालाई WinNAT ले अनुवाद गर्छ र त्यसपछि होस्ट स्ट्याकले अगाडि बढाउँछ, त्यसैले यो होस्टको मार्ग तालिका पछ्याउँछ; पूर्ण सुरुङ क्लाइन्टसँग यसको ट्राफिक VPN एडाप्टरमा प्रवेश गर्ने ट्राफिक नै हो, र क्लाइन्टले स्थानीय सबनेट अवरुद्ध गर्दा त्यो खारेज गरिन्छ। बाह्य स्विचमा ब्रिज गरिएको पाहुना होस्ट राउटिङसम्म कहिल्यै पुग्दैन: यसका फ्रेमहरू भौतिक NIC बाट सिधै निस्कन्छन्, त्यसैले यो सुरुङ र क्लाइन्टको स्थानीय-LAN नीति दुवैलाई बाइपास गर्छ।
होस्ट सुरुङ Hyper-V सँग साझा गर्ने
पाहुनालाई सुरुङ चाहिएको छ र आफ्नै क्लाइन्ट चलाउन सक्दैन भने, Windows ले VPN जडान साझा गर्न सक्छ। VPN एडाप्टरको गुणहरू खोल्नुहोस्, साझेदारीमा जानुहोस्, र अन्य सञ्जाल प्रयोगकर्ताहरूलाई यसबाट जोडिन अनुमति दिनुहोस्। गृह सञ्जाल जडानलाई Hyper-V एडाप्टरतिर देखाउनुहोस्, vEthernet (Default Switch), त्यसपछि पाहुनाको भित्रबाट नयाँ अनुरोध परीक्षण गर्नुहोस्।
यो व्यवस्थालाई प्रयोगशाला समाधान मान्नुहोस्, किनभने यो त्यसै गरी व्यवहार गर्छ। डिस्कनेक्ट, पुनः जडान वा होस्ट रिबुटपछि यसलाई फेरि लागू गर्नुपर्छ। केही Windows 11 बिल्डमा एडाप्टर ड्रप-डाउनबाट पूर्ण रूपमा हराउँछ, र तब यो बाटो बन्द हुन्छ।
Hyper-V सुविधा पुनः स्थापना गर्दा केही जिद्दी पाहुनाहरू बचे। त्यो अन्त्यका लागि राख्नुहोस्, र पहिले पाहुनाको अवस्था लेख्नुहोस्।
सबनेट फिल्टर हुँदा पोर्ट अगाडि बढाउने
पाहुनाको NAT सबनेट फिल्टर गर्ने होस्ट VPN ले नाम विश्लेषण होइन, सिधा पहुँच तोड्छ। VM चलिरहेको छ, तैपनि ssh [email protected] अड्किन्छ, जबकि हाइपरभाइजरको अनुवाद अझै काम गरिरहेको छ। कामलाई चाहिने पोर्टहरू अगाडि बढाउनुहोस् र त्यसको सट्टा होस्ट ठेगानामा जोडिनुहोस्। तलका Vagrantfile लाइनहरूले SSH र एउटा HTTPS सेवा समेट्छन्; दुवै रिलोडअघि थपिन्छन्।
config.vm.network "forwarded_port", guest: 22, host: 22
config.vm.network "forwarded_port", guest: 3443, host: 3443नाम विश्लेषण छुट्टै निर्णय हो र यसले आफ्नै सुधारको योग्यता राख्छ। त्यो NAT एडाप्टरका लागि होस्ट रिजोल्भर सुविधा खोल्नुहोस्, वा पाहुनाको भित्र आन्तरिक DNS सर्भर हातले कन्फिगर गर्नुहोस्। पाहुनालाई सार्वजनिक रिजोल्भरतिर देखाउँदा ब्राउजिङ चल्छ र हरेक आन्तरिक नाम टुट्छ, जुन अवरोधभन्दा पनि खराब हो किनभने यो सफलता जस्तो देखिन्छ। आन्तरिक रिजोल्भरलाई मात्र थाहा हुने नाम परीक्षण गर्नुहोस्।
यो चल्यो भनी बताउने जाँच
यीमध्ये कुनै पनि परिवर्तनपछि, होस्ट VPN जोडिएको अवस्थामा पाहुनाको भित्रबाट नयाँ अनुरोध चलाउनुहोस्, त्यसअघि होइन। पुनः जडानपछि र रिबुटपछि साझेदारी फेरि जाँच्नुहोस्, किनभने तीमध्ये एउटा मात्र टिक्ने सुधार सुधार होइन। पाहुनाको रिजोल्भर सूची उसको ट्राफिकले वास्तवमै प्रयोग गर्ने सञ्जालसँग मिल्छ भनी पुष्टि गर्नुहोस्। त्यसपछि होस्ट ठेगानाबाट पोर्ट अगाडि बढाउने परीक्षण गर्नुहोस्, किनभने पाहुनाबाट परीक्षण गर्दा केही प्रमाणित हुँदैन। पाहुनाको भित्रबाट, दुई PowerShell जाँचले रिजोल्भर र अगाडि बढाइएको पोर्ट समेट्छन्:
Resolve-DnsName intranet.corp
Test-NetConnection 192.0.2.10 -Port 22हरेक स्विच वा ड्राइभर परिवर्तनलाई यसको पूर्ववत् कदमसँगै रेकर्ड गर्नुहोस्। Microsoft को Hyper-V NAT मार्गदर्शिका ले Default Switch वास्तवमा के हो भन्ने व्याख्या गर्छ, र यससँग बाझिने दोस्रो NAT सञ्जाल बनाउनुअघि यो पढ्न लायक छ।