NAT или мостена VM мрежа: што го пренесува VPN сообраќајот?

NAT гостите го позајмуваат тунелот на домаќинот само кога клиентот тунелира по рута; мостените гости рутираат сами. Тестирајте го гостинот и потоа изберете го соодветниот режим.

Мостот и NAT не се два начина да се поврзе истиот гостин со вашиот VPN; тие одлучуваат чии се пакетите на гостинот пред воопшто да се појави тунел. Во NAT режим хипервизорот го препишува сообраќајот на гостинот и го испраќа од код на страната на домаќинот, па гостинот оди по рутата што домаќинот му ја дава на тој код. Во мостен режим гостинот добива сопствен идентитет на слојот за поврзување во физичкиот сегмент и избира сопствен стандарден портал, што го прави тунелот на домаќинот неважен за него, освен ако LAN рутерот е тој што тунелира. Престанав да го гледам VM како да е на 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 на домаќинот го фаќа без никогаш да знае дека постои VM. Поглавјето на Oracle за мрежи во VirtualBox ги наведува овие стандардни вредности ако сакате да ги потврдите адресите во вашата инсталација.

Стандардната мрежа на libvirt стигнува до истото место од 192.168.122.0/24, каде dnsmasq дели закуп и домаќинот го маскира подмрежјето, па пакетите на гостинот повторно пристигнуваат до одлуката за рутирање на домаќинот. Исклучок е клиент што избира сообраќај по процес, а не по рута. Ако списокот на поделен тунел содржи само вашиот прелистувач и ништо друго, NAT моторот не е на тој список, и гостинот ја напушта машината без тунел, додека прелистувачот на домаќинот уште изгледа покриен. Иста подмрежа, спротивен резултат.

Мостот му дава на гостинот сопствено место на физичкиот LAN

На мостен гостин му се дава виртуелна мрежна карта поврзана со вистински адаптер, добива сопствена MAC адреса и зема DHCP закуп од физичката мрежа. Неговиот стандарден портал е LAN рутерот, не хипервизорот, а неговите рамки излегуваат на кабелот преку тој адаптер. Рутите на тунелот на домаќинот живеат во табелата на домаќинот и никогаш не се прашуваат, бидејќи рамките на гостинот никогаш не влегуваат во IP стекот на домаќинот.

Тоа сече на двете страни. mDNS и прелистувањето SMB почнуваат да работат бидејќи гостинот го гледа емитуваниот сообраќај на LAN, и гостинот станува достапен од други машини во истиот сегмент без огнена ѕид на домаќинот помеѓу. Мостот исто така не е начин да се турка гостин низ постоечки тунел: поврзувањето на VM со интерфејсот 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 оди по друга рута, и така се добива страница што се вчитува и најава што никогаш не завршува.

Кој режим одговара на работата

Режимот е одлука за рутирање, затоа изберете го според барањето, а не според навиката:

RequirementMode that fits
Every guest flow must exit through the host tunnelNAT, with a host client that tunnels by route, verified from inside the guest
The guest needs its own VPN account or profileBridged, or NAT with a client running inside the guest, not both
The guest must serve SSH, SMB, or a dev server to the LANBridged; NAT needs a port forward, which does not change the outbound path
The guest must stay invisible to the LANNAT; a bridged guest is another host on the segment
The guest needs a real public IPv6 addressBridged; VirtualBox NAT mode has no IPv6 forwarding
Isolation from the LAN with access to the hostHost-only adapter, not NAT

Првиот ред е местото каде луѓето се фаќаат: NAT плус клиент со целосен тунел на домаќинот навистина покрива гостин, но само додека клиентот тунелира по рута и додека горниот слој на домаќинот е тој тунел. Преместете го клиентот на список за дозвола само за прелистувачот и покриеноста исчезнува без никаква грешка никаде. Четвртиот ред е обратната грешка: гостин мостен за удобност што тивко почнува да одговара на SMB или SSH на канцеларискиот LAN.

Дефекти што се префрлуваат на VPN

На Windows преводот на NAT се извршува во процесот на VM на VirtualBox, затоа клиентот по апликација треба да ја има токму таа слика на својот список наместо општо правило за виртуелни машини. Кога ажурирањето на клиентот го обновува списокот на процеси, NAT гостите први ја губат покриеноста, а извештајот се чита како VM што стигнува до LAN, но не до интернет, додека домаќинот е во ред.

Мостот на Wi-Fi е другата класика. Пристапните точки ретко препраќаат рамки со туѓа изворна MAC, па мостот на wlan0 или целосно не успева, или работи додека изолацијата на клиенти на AP не почне да го отфрла. VirtualBox сепак ќе го понуди безжичниот адаптер на својот список. Ако домаќинот е на Wi-Fi, а гостинот мора да биде мостен, планирајте да го тестирате наместо да претпоставите.

MTU е третиот. Мостениот гостин го задржува MTU од 1500 бајти на LAN, и ако води сопствен клиент WireGuard на 1420, големите TLS ракувања запираат додека малите барања успеваат. Под NAT MTU на тунелот на домаќинот е проблем на домаќинот, но гостинот уште верува во 1500, а UDP со поставен don't-fragment бит исчезнува на истиот начин.

Запишете го режимот и проверете повторно по секоја промена на адаптер

Запишете го режимот, интерфејсот на домаќинот што го користи мостот, стандардниот портал на гостинот, неговиот резолвер и неговите v4 и v6 излезни адреси. Токму тој запис го прави следниот дефект евтин: кога преносен компјутер се префрла од док на Wi-Fi, мостениот гостин го следи мостот на друг физички адаптер и може повторно да закупи во друга подмрежа, додека NAT гостинот ја задржува својата 10.0.2.x адреса и тивко наследува друга горна врска.

Пред да го затворите тикетот, потврдете го секој од овие:

  • Излезната адреса на гостинот се разликува од излезната адреса на домаќинот, па не е на тунелот на домаќинот.
  • Резолверот е проксито 10.0.2.3 или LAN сервер, и знаете кој одговори.
  • Во гостинот не постои глобална v6 адреса ако концептот на тунелот е само v4.
  • Со спуштен тунел на домаќинот гостинот престанува да прелистува, или сега знаете дека никогаш не зависел од него.
  • Гостинот не гледа емитуван сообраќај на LAN што не го засега.

Поврзани статии