ஹோஸ்ட் VPN இணையும்போது Hyper-V விருந்தினர் DNS இழக்கிறது

விருந்தினர் இன்று காலை நன்றாக இருந்தது. பின்னர் ஹோஸ்ட் 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 நெட்வொர்க்கை உருவாக்கும் முன் அதைப் படிப்பது மதிப்புள்ளது.