Hyper-V հյուրը կորցնում է DNS-ը, երբ միանում է հոսթի VPN-ը
Հյուր VM-ը չի ժառանգում հոսթի թունելը։ Գտեք անջատիչի կամ NAT-ի ռեժիմը, կիսվեք VPN ադապտերով, որտեղ դա առաջարկվում է, և փոխանցեք պորտերը, որտեղ չէ։
Հյուրը լավ էր այս առավոտ։ Հետո հոսթը միացրեց Cisco AnyConnect-ը, և VM-ը կորցրեց DNS-ը, դոմենի վստահությունը և ընդհանուր պանակը, մինչդեռ ներսում ոչինչ չէր փոխվել։ Հոսթի թունելը և հյուրի ցանցը առանձին ուղիներ են, և մեկը միացնելը չի տեղափոխում մյուսը։ Աշխատեք հյուրի ներսից դուրս և գրի առեք այն, ինչ տեսնում եք, նախքան որևէ բան փոխելը։
Ինչ դեռ կարող է տեսնել հյուրը
Գրանցեք հասցեն, լռելյայն դարպասը և լուծիչը VM-ում՝ մեկ անգամ նախքան հոսթի միանալը և մեկ անգամ դրանից հետո։ Հյուրը, որը պահպանել է հասցեն և կորցրել միայն անունների լուծումը, ունի լուծիչի խնդիր։ Հյուրը, որը երբեք երթուղի չի ունեցել, ունի ուղու խնդիր, և երկուսն էլ տարբեր աշխատանք են պահանջում։ Հոսթից չեք կարող տարբերել դրանք, դրա համար էլ ընթերցումը պետք է գա ներսից։
Այդ երեք ընթերցումները, երկու անգամ վերցված, ձեր ելակետն են։ Ամեն հաջորդ բան չափվում է դրանց դեմ։
Որ ելքն է օգտագործում հյուրը
Hyper-V-ը պատասխանում է սրան երկու հրամանով՝ Get-VMSwitch թվարկում է անջատիչները, և Get-VMNetworkAdapter -VMName TestVM ցույց է տալիս այն, որին միացված է հյուրը։ Default Switch-ը NAT ցանց է, որը կառավարում է Windows-ը, արտաքին անջատիչը երթևեկությունը հանձնում է ֆիզիկական ադապտերին, իսկ ներքին անջատիչը ոչինչ չի կրում, քանի դեռ ինչ-որ մեկը չի ավելացրել NAT կամ երթուղիչ։ VirtualBox-ը ներկայացնում է նույն երեք գաղափարները որպես NAT, NAT Network և bridged։
Ռեժիմը որոշում է՝ արդյոք հոսթի թունելը կարող է ընդհանրապես նշանակություն ունենալ։ NAT հյուրը թարգմանվում է WinNAT-ի կողմից, ապա փոխանցվում հոսթի ստեկով, ուստի այն հետևում է հոսթի երթուղային աղյուսակին, իսկ ամբողջական թունելի հաճախորդի դեպքում նրա երթևեկությունը այն երթևեկությունն է, որը մտնում է VPN ադապտեր, և այն դեն է նետվում, երբ հաճախորդը արգելափակում է տեղական ենթացանցը։ Արտաքին անջատիչի վրա կամրջված հյուրը երբեք չի հասնում հոսթի երթուղավորմանը, քանի որ նրա կադրերը ուղղակիորեն դուրս են գալիս ֆիզիկական NIC-ից, ուստի այն շրջանցում է և՛ թունելը, և՛ հաճախորդի տեղական ցանցի քաղաքականությունը։
Հոսթի թունելի կիսումը Hyper-V-ի հետ
Եթե հյուրին պետք է թունելը և նա չի կարող գործարկել իր սեփական հաճախորդը, Windows-ը կարող է կիսել VPN կապը։ Բացեք VPN ադապտերի հատկությունները, անցեք Կիսում և թույլ տվեք այլ ցանցային օգտատերերին միանալ դրա միջով։ Ուղղեք տնային ցանցի կապը Hyper-V ադապտերին՝ vEthernet (Default Switch), ապա ստուգեք նոր հարցում հյուրի ներսից։
Վերաբերվեք այս դասավորությանը որպես լաբորատոր լուծում, որովհետև այն այդպես է իրեն պահում։ Այն պետք է նորից կիրառվի անջատումից, վերամիացումից կամ հոսթի վերագործարկումից հետո։ Որոշ Windows 11 կառուցվածքներում ադապտերը բացակայում է ցանկից ամբողջությամբ, և այդ ժամանակ այս ուղին փակ է։
Hyper-V հատկության վերատեղադրումը փրկել է մի քանի համառ հյուրերի։ Պահեք դա վերջին, և նախ գրանցեք հյուրի վիճակը։
Պորտերի փոխանցում, երբ ենթացանցը զտված է
Հոսթի VPN-ը, որը զտում է հյուրի NAT ենթացանցը, կոտրում է ուղիղ հասանելիությունը, ոչ թե անունների լուծումը։ 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 ցանց ստեղծելը, որը հակասում է դրան։