NAT czy sieć VM w trybie mostu: co przenosi ruch VPN?

Goście NAT pożyczają tunel hosta tylko wtedy, gdy klient tuneluje według trasy; goście w trybie mostu trasują sami. Przetestuj gościa, a potem wybierz odpowiedni tryb.

Most i NAT nie są dwoma sposobami podłączenia tego samego gościa do twojego VPN; decydują do kogo należą pakiety gościa, zanim w ogóle pojawi się tunel. W trybie NAT hiperwizor przepisuje ruch gościa i wysyła go z kodu po stronie hosta, więc gość jedzie trasą, którą host daje temu kodowi. W trybie mostu gość dostaje własną tożsamość w warstwie łącza w segmencie fizycznym i sam wybiera swoją bramę domyślną, co czyni tunel hosta nieistotnym dla niego, chyba że to router LAN tuneluje. Przestałem traktować VM jako będącą na VPN i zacząłem traktować to jako pytanie, dokąd wskazuje trasa domyślna tego gościa. Test poniżej zajmuje kilka minut na tryb i rozstrzyga sprawę bez zgadywania.

NAT trzyma gościa za kodem hiperwizora, gdzie obowiązują trasy hosta

W VirtualBox gość NAT siedzi na 10.0.2.0/24 z wirtualną bramą na 10.0.2.2, proxy DNS na 10.0.2.3 i bez własnej trasy do sieci fizycznej. Pakiety wychodzące przejmuje silnik NAT, przepisuje je tak, by źródłem był host, i przekazuje stosowi IP hosta. Od tego miejsca ruch gościa jest przepływem hosta, a wyszukiwanie trasy odbywa się według miejsca docelowego: klient z pełnym tunelem, który instaluje 0.0.0.0/1 i 128.0.0.0/1 na hoście, przechwytuje go, nie wiedząc nigdy, że istnieje VM. Rozdział Oracle o sieciach VirtualBox wymienia te wartości domyślne, jeśli chcesz potwierdzić adresy w swojej instalacji.

Domyślna sieć libvirt dociera w to samo miejsce z 192.168.122.0/24, gdzie dnsmasq rozdaje dzierżawy, a host maskuje podsieć, więc pakiety gościa znowu trafiają do decyzji routingu hosta. Wyjątkiem jest klient, który wybiera ruch według procesu, a nie według trasy. Jeśli lista tunelu dzielonego zawiera tylko twoją przeglądarkę i nic więcej, silnika NAT nie ma na tej liście, a gość opuszcza maszynę bez tunelu, podczas gdy przeglądarka na hoście wciąż wygląda na objętą. Ta sama podsieć, przeciwny wynik.

Most daje gościowi własne miejsce w fizycznym LAN

Gość w trybie mostu dostaje wirtualną kartę sieciową podpiętą do prawdziwego adaptera, otrzymuje własny adres MAC i bierze dzierżawę DHCP z sieci fizycznej. Jego bramą domyślną jest router LAN, nie hiperwizor, a jego ramki wychodzą na kabel przez ten adapter. Trasy tunelu hosta żyją w tablicy hosta i nigdy nie są pytane, ponieważ ramki gościa nigdy nie wchodzą do stosu IP hosta.

Tnie to w obie strony. mDNS i przeglądanie SMB zaczynają działać, bo gość widzi ruch rozgłoszeniowy LAN, a gość staje się osiągalny z innych maszyn w tym samym segmencie bez zapory hosta pomiędzy. Most nie jest też sposobem na przepchnięcie gościa przez istniejący tunel: podpięcie VM do interfejsu WireGuard lub OpenVPN hosta nie jest czymś, co VirtualBox lub libvirt zrobią za ciebie. Jeśli gość w trybie mostu musi przejść przez tunel, tunel musi kończyć się gdzieś w tym LAN.

Test, który kończy spór

Uruchom te same sprawdzenia w obu trybach i zapisz odpowiedzi:

  • Na hoście curl -s https://ifconfig.me podaje publiczny adres v4.
  • W gościu to samo polecenie plus ip route w Linuksie lub Get-NetRoute -DestinationPrefix 0.0.0.0/0 w Windows dla bramy domyślnej.
  • Tożsamość resolvera: resolvectl status lub cat /etc/resolv.conf w gościu, by zobaczyć, czy wskazuje na 10.0.2.3, czy na serwer w LAN.
  • Rodzina adresów: ip -6 addr show scope global i jedno żądanie v6, bo tunel v4 nic nie mówi o globalnym adresie v6, który gość może mieć.

Zgodne publiczne adresy oznaczają, że gość jest na ścieżce hosta. Adres gościa zgodny ze zwykłym wyjściem LAN oznacza, że nie jest. Krokiem, który ludzie pomijają, jest kontrola: wyłącz tunel hosta i powtórz żądanie z gościa. Jeśli gość nadal przegląda, nigdy nie zależał od tunelu hosta, cokolwiek sugeruje nazwa trybu. W trybie NAT gość powinien stracić internet przy wyłączonym tunelu hosta, chyba że klient jest skonfigurowany tak, by pozwalać na ruch bez tunelu, co samo w sobie warto wiedzieć.

Dwa sygnały kłamią. Udany ping dowodzi osiągalności, nie ścieżki wyjścia. A DNS może być obsłużony przez proxy 10.0.2.3 przez resolver hosta, podczas gdy TCP idzie inną trasą, i tak powstaje strona, która się wczytuje, oraz logowanie, które nigdy się nie kończy.

Który tryb pasuje do zadania

Tryb jest decyzją o routingu, więc wybieraj go z wymagania, a nie z przyzwyczajenia:

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

Pierwszy wiersz to miejsce, w którym ludzie się łapią: NAT plus klient hosta z pełnym tunelem rzeczywiście obejmuje gościa, ale tylko dopóki klient tuneluje według trasy i dopóki łącze nadrzędne hosta to ten tunel. Przenieś klienta na listę dozwolonych tylko dla przeglądarki, a objęcie znika bez żadnego błędu nigdzie. Czwarty wiersz to odwrotny błąd: gość podpięty mostem dla wygody, który po cichu zaczyna odpowiadać na SMB lub SSH w LAN-ie biura.

Awarie, które zwala się na VPN

W Windows tłumaczenie NAT działa w procesie VM VirtualBox, więc klient per aplikacja potrzebuje dokładnie tego obrazu na swojej liście, a nie ogólnej reguły dla maszyn wirtualnych. Gdy aktualizacja klienta odbuduje listę procesów, goście NAT jako pierwsi tracą objęcie, a raport brzmi jak VM, która dociera do LAN, ale nie do internetu, podczas gdy host jest w porządku.

Most na Wi-Fi to drugi klasyk. Punkty dostępu rzadko przekazują ramki z obcym źródłowym MAC, więc most na wlan0 albo całkiem zawodzi, albo działa, dopóki izolacja klientów na AP nie zacznie go odrzucać. VirtualBox i tak zaproponuje kartę bezprzewodową na swojej liście. Jeśli host jest w Wi-Fi, a gościa trzeba podpiąć mostem, zaplanuj test zamiast założenia.

MTU jest trzeci. Gość w trybie mostu zachowuje MTU 1500 bajtów z LAN, a jeśli uruchamia własnego klienta WireGuard na 1420, duże uściski dłoni TLS się zatrzymują, podczas gdy małe żądania przechodzą. Pod NAT MTU tunelu hosta jest problemem hosta, ale gość nadal wierzy w 1500, a UDP z ustawionym bitem don't-fragment znika w ten sam sposób.

Zapisz tryb i sprawdź ponownie po każdej zmianie adaptera

Zapisz tryb, interfejs hosta używany przez most, bramę domyślną gościa, jego resolver oraz jego adresy wyjściowe v4 i v6. Właśnie ten zapis czyni następną awarię tanią: gdy laptop przenosi się z doku na Wi-Fi, gość w trybie mostu podąża za mostem na inny adapter fizyczny i może odnowić dzierżawę w innej podsieci, podczas gdy gość NAT zachowuje swój adres 10.0.2.x i po cichu dziedziczy inne łącze nadrzędne.

Przed zamknięciem zgłoszenia potwierdź każdy z tych punktów:

  • Adres wyjściowy gościa różni się od adresu wyjściowego hosta, więc gość nie jest na tunelu hosta.
  • Resolver to proxy 10.0.2.3 lub serwer w LAN, i wiesz, który odpowiedział.
  • W gościu nie ma globalnego adresu v6, jeśli projekt tunelu jest tylko v4.
  • Przy wyłączonym tunelu hosta gość przestaje przeglądać, albo wiesz już, że nigdy od niego nie zależał.
  • Gość nie widzi ruchu rozgłoszeniowego LAN, który go nie dotyczy.

Powiązane artykuły