NAT супраць маставога рэжыму сеткі ВМ: што нясе трафік VPN?
Госці NAT пазычаюць тунель хоста, толькі калі кліент тунелюе па маршруце; маставыя госці маршрутызуюць сябе самі. Праверце госця, затым выберыце адпаведны рэжым.
Маставы рэжым і NAT — гэта не два спосабы падключыць аднаго госця да VPN; яны вырашаюць каму належаць пакеты госця яшчэ да таго, як задзейнічаны любы тунель . У рэжыме NAT гіпервізар перапісвае трафік госця і выпускае яго з кода на баку хоста, таму госць едзе па тым маршруце, які хост дае гэтаму коду. У маставым рэжыме госць атрымлівае ўласную ідэнтычнасць канальнага ўзроўню на фізічным сегменце і выбірае свой шлюз па змаўчанні, што робіць тунель хоста неістотным для яго, калі толькі тунель не будуе маршрутызатар LAN. Я перастаў лічыць ВМ часткай VPN і пачаў разглядаць гэта як пытанне пра тое, куды накіраваны маршрут госця па змаўчанні. Тэст ніжэй займае некалькі хвілін на рэжым і вырашае ўсё без здагадак.
NAT трымае госця за кодам гіпервізара, дзе дзейнічаюць маршруты хоста
У VirtualBox госць NAT сядзіць на 10.0.2.0/24 з віртуальным шлюзам 10.0.2.2, DNS-проксі 10.0.2.3 і без уласнага маршруту да фізічнай сеткі. Зыходныя пакеты бярэ механізм NAT, перапісвае іх так, каб крыніцай быў хост, і перадае ў IP-стэк хоста. Адтуль трафік госця — гэта паток хоста, а пошук маршруту ідзе па прызначэнні: кліент поўнага тунеля, які ўсталёўвае 0.0.0.0/1 і 128.0.0.0/1 на хосце, перахоплівае яго, нават не ведаючы, што ВМ існуе. Раздзел пра сетку VirtualBox ад Oracle пералічвае гэтыя значэнні па змаўчанні, калі вы хочаце пацвердзіць адрасы ў сваёй зборцы.
Стандартная сетка libvirt дасягае таго ж праз 192.168.122.0/24, дзе dnsmasq выдае арандаванні, а хост маскарадзіць падсетку, таму пакеты госця зноў прыходзяць да рашэння аб маршрутызацыі на хосце. Выключэнне — кліент, які выбірае трафік па працэсе, а не па маршруце. Калі спіс раздзеленага тунеля ўтрымлівае толькі ваш браўзер, механізму NAT у гэтым спісе няма, і госць пакідае машыну без тунеля, пакуль браўзер хоста выглядае ахопленым. Тая ж падсетка, процілеглы вынік.
Маставы рэжым дае госцю ўласнае месца ў фізічнай LAN
Маставому госцю даюць віртуальны NIC, падлучаны да рэальнага адаптара, ён атрымлівае ўласны MAC-адрас і бярэ арандаванне DHCP з фізічнай сеткі. Яго шлюз па змаўчанні — маршрутызатар LAN, а не гіпервізар, і яго кадры выходзяць у дрэт праз гэты адаптар. Маршруты тунеля хоста жывуць у табліцы хоста і ніколі не разглядаюцца, бо кадры госця ніколі не трапляюць у IP-стэк хоста.
Гэта рэжа ў абодва бакі. Прагляд mDNS і SMB пачынае працаваць, бо госць бачыць шырокавяшчальны трафік LAN, і госць становіцца даступным з іншых машын таго ж сегмента без міжвольнага фэрвола хоста. Мост таксама не спосаб прапхнуць госця праз існуючы тунель: падключыць ВМ да інтэрфейса WireGuard або OpenVPN хоста — гэта не тое, што VirtualBox ці libvirt зробіць за вас. Калі маставы госць мусіць быць у тунелі, тунель павінен скончыцца недзе ў гэтай LAN.
Тэст, які спыняе спрэчку
Правядзіце аднолькавыя праверкі ў абодвух рэжымах і запішыце адказы:
- На хосце
curl -s https://ifconfig.meдае публічны адрас v4. - У госці тая ж каманда, плюс
ip routeу Linux абоGet-NetRoute -DestinationPrefix 0.0.0.0/0у Windows для шлюза па змаўчанні. - Ідэнтычнасць рэзалвера:
resolvectl statusабоcat /etc/resolv.confу госці, каб убачыць, ці паказвае ён на 10.0.2.3, ці на сервер LAN. - Сямейства адрасоў:
ip -6 addr show scope globalі адзін запыт v6, бо тунель v4 нічога не кажа пра глабальны адрас v6, які можа мець госць.
Супадальныя публічныя адрасы азначаюць, што госць ідзе па шляху хоста. Адрас госця, які супадае са звычайным выхадам LAN, азначае, што не. Крок, які людзі прапускаюць, — гэта кантроль: адключыце тунель хоста і паўтарыце запыт госця. Калі госць працягвае праглядаць, ён ніколі не залежаў ад тунеля хоста, што б ні казала назва рэжыму. У рэжыме NAT госць павінен страціць інтэрнэт пры адключаным тунелі хоста, калі кліент не наладжаны дазваляць трафік па-за тунелем, што само па сабе варта ведаць.
Два сігналы хлусяць. Паспяховы ping даказвае дасяжнасць, а не шлях выхаду. І DNS можа адказваць праз проксі 10.0.2.3 праз рэзалвер хоста, пакуль TCP ідзе іншым маршрутам, — менавіта так атрымліваецца старонка, што загружаецца, і ўваход, які ніколі не завяршаецца.
Які рэжым падыходзіць для задачы
Рэжым — гэта рашэнне аб маршрутызацыі, таму выбірайце яго па патрабаванні, а не па звычцы:
| Requirement | Mode that fits |
|---|---|
| Every guest flow must exit through the host tunnel | NAT, with a host client that tunnels by route, verified from inside the guest |
| The guest needs its own VPN account or profile | Bridged, or NAT with a client running inside the guest, not both |
| The guest must serve SSH, SMB, or a dev server to the LAN | Bridged; NAT needs a port forward, which does not change the outbound path |
| The guest must stay invisible to the LAN | NAT; a bridged guest is another host on the segment |
| The guest needs a real public IPv6 address | Bridged; VirtualBox NAT mode has no IPv6 forwarding |
| Isolation from the LAN with access to the host | Host-only adapter, not NAT |
Першы радок — тое месца, дзе людзі трапляюцца: NAT плюс кліент поўнага тунеля на хосце сапраўды ахоплівае госця, але толькі пакуль кліент тунелюе па маршруце і вышэйшае звяно хоста — гэты тунель. Перанясіце кліент у спіс дазволу толькі для браўзера, і ахоп знікне без любой памылкі. Чацвёрты радок — зваротная памылка: госць, змаставаны для зручнасці, ціха пачынае адказваць на SMB або SSH у офіснай LAN.
Збоі, якія звальваюць на VPN
У Windows трансляцыя NAT выконваецца ўнутры працэсу VirtualBox VM, таму кліенту для кожнай праграмы патрэбны менавіта гэты вобраз у спісе, а не агульнае правіла для віртуальных машын. Калі абнаўленне кліента перабудоўвае спіс дазволеных працэсаў, госці NAT губляюць ахоп першымі, і справаздача чытаецца як ВМ, што дасягае LAN, але не інтэрнэт, пакуль хост у парадку.
Мост у Wi-Fi — іншая класіка. Кропкі доступу рэдка перасылаюць кадры з чужым зыходным MAC, таму мост на wlan0 або цалкам не ўдаецца, або працуе, пакуль ізаляцыя кліентаў на кропцы не пачне іх скідваць. VirtualBox усё роўна прапануе бесправадны адаптар у сваім спісе. Калі хост у Wi-Fi, а госць мусіць быць змаставаны, плануйце праверыць гэта, а не меркаваць.
MTU — трэці. Маставы госць захоўвае MTU LAN у 1500 байт, і калі ён запускае ўласны кліент WireGuard на 1420, вялікія TLS-рукапацішчы застойваюцца, а малыя запыты праходзяць. Пад NAT MTU тунеля хоста — праблема хоста, але госць усё яшчэ верыць у 1500, і UDP з устаноўленым бітам «не фрагментаваць» трапляе ў тую ж чорную дзірку.
Запішыце рэжым, затым пераправерце пасля любой змены адаптара
Запішыце рэжым, інтэрфейс хоста, які выкарыстоўвае мост, шлюз госця па змаўчанні, яго рэзалвер і яго адрасы выхаду v4 і v6. Менавіта гэты запіс робіць наступны збой танным: калі ноўтбук пераходзіць з дока ў Wi-Fi, маставы госць ідзе за мостам да іншага фізічнага адаптара і можа пераарандавацца ў іншую падсетку, а госць NAT захоўвае свой адрас 10.0.2.x і моўчкі атрымлівае іншае вышэйшае звяно.
Перад закрыццём заявкі пацвердзіце кожнае з гэтага:
- Адрас выхаду госця адрозніваецца ад адраса выхаду хоста, значыць ён не ў тунелі хоста.
- Рэзалвер — гэта проксі 10.0.2.3 або сервер LAN, і вы ведаеце, які з іх адказаў.
- У госці няма глабальнага адраса v6, калі дызайн тунеля толькі v4.
- Пры адключаным тунелі хоста госць перастае праглядаць, або вы цяпер ведаеце, што ён ніколі ад яго не залежаў.
- Госць не бачыць шырокавяшчальны трафік LAN, які яму не належыць бачыць.