Абагульванне VPN-сесіі хоста з госцем VMware

Тунэльны адаптар не ўваходзіць у мост, а Windows 10 не маршрутызуе паміж падсеткамі. Замест гэтага госця нясе host-only сегмент з NAT.

Ваша віртуальная машына не можа дабрацца да ўнутранай сістэмы, якая бездакорна працуе на хосце, а хост падключаны праз кліент, які валодае табліцай маршрутызацыі. Злучэнне віртуальнага адаптара з тунэлем праз мост выглядае відавочным і правальваецца з дзвюх асобных прычын. Працуе пераўтварэнне на сегменце, якім валодаюць абедзве машыны. Кошт рэальны: кожны госць страчвае ўласную ідэнтычнасць у карпаратыўнай сетцы.

Дзве прычыны, чаму мост не можа працаваць

Адаптар кліента звычайна нясе адзін адрас, часта /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"

Параўнайце з уласным доступам хоста да той жа мэты, пакуль тунэль працуе. Калі хост дасягае поспеху, а госць не, няспраўнасць у пераўтварэнні або ў наладах шлюза госця, а не ў злучэнні.

Затым прымеце гэты абмен. Карпаратыўныя сістэмы цяпер бачаць адзін адрас для кожнага госця, таму сертыфікаты прылад і праверкі стану асобных прылад не могуць іх адрозніць, а некаторыя палітыкі наогул гэта забараняюць. Вызначце і паводзіны пры скідзе, бо пераўтвораны трафік можа праваліцца на звычайны інтэрнэт-шлях, калі тунэль адмовіць, пакуль вы не заблакуеце гэты прэфікс у файрволе хоста.

Падобныя артыкулы