VirtualBox NAT ці мост: дзе сканчаецца VPN віртуальнай машыны

Два розныя пытанні прыходзяць разам кожны раз, калі віртуальная машына запускае кліент VPN, і адказы на іх розныя. Першае — ці абараняе тунель унутры гасця хост, а другое — ці ахінае тунель на хосце гасця. Рэжым адаптара вырашае абодва, больш за само праграмнае забеспячэнне VPN. Адаптар NAT робіць хост бачным канцавым пунктам, а адаптар моста ставіць гасця ў сетку з яго ўласным адрасам.

Хто насамрэч завяршае шыфраваную сесію

Шыфраваная сесія належыць машыне, якая яе завяршае, а гэта госць, калі кліент працуе ўнутры ВМ. Праз гэты тунель ідзе толькі трафік, што трапляе на віртуальны адаптар гасця, і гіпервізар ніколі сам не накіроўвае іншую машыну праз гасця. Таму госць можа трымаць працоўны тунель, пакуль хост праглядае сетку адкрыта. Адваротнае не сіметрычнае, і менавіта гэтая асіметрыя — тое, што большасць кіраўніцтваў блытае.

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

NAT перапісвае гасця, пакуль той не пачне выглядаць як хост

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

# on the host: adapter mode and NAT DNS behaviour
VBoxManage showvminfo "lab-vm" | grep -i -E "nic|nat"
VBoxManage modifyvm "lab-vm" --natdnshostresolver1 on

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

Мост дае гасцю ўласную арэнду і ўласную экспазіцыю

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

Гэтую розніцу з выпадкам NAT варта сказаць проста, а не пакідаць як намёк. Госцю за мостам патрэбны ўласны кліент і ўласныя ўліковыя даныя кожны раз, калі яго трафік мусіць ісці праз тунель. Там, дзе госць павінен заставацца нябачным для лакальнай сеткі, NAT або сетка толькі для ўнутранага ўжытку з кантраляванай маршрутызацыяй — лепшы дызайн.

Чаму госць не можа быць шлюзам хоста

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

Практычныя замены — гэта перанакіраванні і проксі. Лакальнае перанакіраванне SSH дазваляе хосту падключыцца да ўласнага loopback, пакуль госць нясе паток у тунель, і гэта пакрывае службы TCP без усталявання другога кліента. Прымусіць уласны IP-трафік хоста ісці праз тунель гасця замест гэтага патрабуе маршрутызатара ўнутры гасця, а таксама яўнага маршруту і трансляцыі на хосце. Гэта невялікі сеткавы дызайн, а не сцяжок у наладах, і ён патрабуе плана зваротнага шляху. Калі госць існуе выключна дзеля запуску кліента, пастаўце кліент на хост і выдаліце лішні крок.

ssh -N -f -L 8080:internal-host.example:80 user@lab-vm

Рэзалверы і маршруты не перасякаюць мяжу

DNS ідзе за адаптарам, які атрымаў опцыю, таму госць не наследуе рэзалвер тунеля хоста, а хост ніколі не даведваецца пра сервер, перададзены гасцю. Перададзеныя значэнні dhcp-option DNS дзейнічаюць для інтэрфейса, які іх прыняў, і менавіта таму госць за мостам без кліента не можа развязаць унутраныя імёны. Госць NAT звычайна карыстаецца апрацоўкай DNS гіпервізара, і розніца бачная адной камандай у кожным асяроддзі.

# on the host
VBoxManage showvminfo "lab-vm" | grep -i -E "nic|nat"
# inside a Linux guest
ip -4 route
resolvectl status
# inside a Windows guest
Get-DnsClientServerAddress

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