Հյուրընկալողի VPN նստաշրջանը կիսել VMware հյուրի հետ

Ձեր վիրտուալ մեքենան չի հասնում ներքին համակարգին, որն անթերի աշխատում է հյուրընկալողում, և հյուրընկալողը միացված է հաճախորդի միջոցով, որը տիրապետում է երթուղավորման աղյուսակին։ Վիրտուալ ադապտերը թունելին կամրջելը ակնհայտ է թվում և ձախողվում է երկու առանձին պատճառով։ Աշխատում է թարգմանությունը այն հատվածում, որը պատկանում է երկու մեքենաներին։ Գինը իրական է՝ յուրաքանչյուր հյուր կորցնում է իր ինքնությունը կորպորատիվ ցանցում։

Երկու պատճառ, թե ինչու կամուրջը չի կարող աշխատել

Հաճախորդի ադապտերը սովորաբար կրում է մեկ հասցե, հաճախ /32, և հաճախորդը վերագրում է հյուրընկալողի երթուղիները, որպեսզի սովորական ելքային երթևեկությունը նախընտրի թունելը։ Հյուրընկալողի հավելվածները հնազանդվում են այդ աղյուսակին և հասնում մասնավոր համակարգին։ Կամրջված հյուրը բոլորովին չի կարդում աղյուսակը, որովհետև նրա կադրերը դուրս են գալիս IP շերտից ներքև գտնվող անջատիչով։

Թունելի ադապտերը կամուրջի մեջ դնելը տեսականորեն կլուծեր ուղին, և դրայվերը դա չի ընդունի։ Windows 10-ը նաև թույլ է տալիս միայն մեկ կամուրջ սարք և զրկում է այն երթուղավորման դերից, որը թույլ կտար աշխատանքային կայանին փոխանցել երկու ենթացանցերի միջև։ Մնում է աղբյուրի թարգմանությունը։ Ստեղծեք այնպես, որ հյուրի երթևեկությունը թվա որպես հյուրընկալողից եկող, և հյուրընկալողի իսկ որոշումները տանում են այն թունել, առանց որ հյուրն ունենա ուղի, որը չի կարող ունենալ։

Ստեղծեք հատված, որը տիրապետում է հյուրընկալողը

Վիրտուալ ցանցի խմբագրիչում ավելացրեք host-only ցանց, օրինակ VMnet3, նախածանցի վրա, որը այլ տեղ չեք երթուղավորում, օրինակ 172.28.90.0/24։ Հյուրընկալողը վերցնում է 172.28.90.1-ը այդ ադապտերի վրա, և հյուրը միանում է նույն անջատիչին։ Անջատեք հիպերվիզորի DHCP-ն այդ հատվածում, որպեսզի մեկ հասցեի ծառայություն տիրապետի այն։

Հաստատեք, որ Windows-ը տեսնում է ինտերֆեյսը նախքան դրա վրա որևէ բան կառուցելը, որովհետև ամբողջ ձևավորումը կախված է նրանից, որ այդ ադապտերը սովորական լինի՝

Get-NetAdapter | Format-Table Name, InterfaceDescription, Status
Get-NetIPAddress -AddressFamily IPv4 | Where-Object PrefixLength -eq 24

host-only ադապտերը այնտեղ հայտնվում է ինչպես ցանկացած ֆիզիկական։ Հենց դա է տարբերությունը թունելի ադապտերից, որը ոչ մի բանի չի կարող կցվել։

Թարգմանեք հյուրի նախածանցը

Բացեք բարձրացված նստաշրջան և թարգմանեք նախածանցը։ Սկզբում ստուգեք, թե ինչ արդեն գոյություն ունի, որովհետև կոնտեյներների գործարկման միջավայրերն ու հիպերվիզորները տեղադրում են իրենց թարգմանությունները, և սխալը ջնջելը կոտրում է մեկ այլ ապրանք։

Get-NetNat | Format-Table Name, InternalIPInterfaceAddressPrefix, Active
New-NetNat -Name "LabGuestEgress" -InternalIPInterfaceAddressPrefix 172.28.90.0/24

Այնուհետև կարգավորեք հյուրին այդ նախածանցում ստատիկ հասցեով, 172.28.90.1-ը՝ որպես նրա դարպաս, և լուծիչի հասցեներով, որոնք թունելը տալիս է հյուրընկալողին։ Թարգմանությունը փոխանցում է փաթեթները և հյուրին ոչինչ չի սովորեցնում DNS-ի մասին, ուստի տեղական երթուղիչին թողնված հյուրը լուծում է հանրային անունները և ձախողվում ամեն ներքինի վրա։

Ստուգեք առաջին ցատկը, ապա գինը

Փորձարկեք ամենամոտ սահմանը նախքան հավելվածը փորձարկելը։ Հյուրընկալողի դարպասի մոտ կանգ առնող հետքը նշանակում է, որ թարգմանություն տեղի չի ունենում, իսկ հյուրընկալողից այն կողմ կանգնողը՝ որ թունելն անջատված է կամ հեռավոր կողմը մերժել է թարգմանված հասցեն։

tracert -d 172.20.31.10
nslookup intranet.corp.example
Get-NetNatSession -NatName "LabGuestEgress"

Համեմատեք հյուրընկալողի սեփական հասանելիության հետ նույն նպատակակետին, քանի դեռ թունելը միացված է։ Եթե հյուրընկալողը հաջողում է, իսկ հյուրը՝ ոչ, ապա թերությունը թարգմանության մեջ է կամ հյուրի դարպասի կարգավորման մեջ, ոչ թե միացման։

Ապա ընդունեք այս փոխանակումը։ Կորպորատիվ համակարգերը հիմա տեսնում են մեկ հասցե յուրաքանչյուր հյուրի համար, ուստի սարքերի վկայագրերը և յուրաքանչյուր սարքի կարգավիճակի ստուգումները չեն կարող տարբերել նրանց, և որոշ քաղաքականություններ դա ուղղակիորեն արգելում են։ Որոշեք նաև ընկնելու վարքը, քանի որ թարգմանված երթևեկությունը կարող է ընկնել սովորական ինտերնետ ուղի, երբ թունելը ձախողվում է, եթե այդ նախածանցը չարգելափակեք հյուրընկալողի firewall-ում։