Laboratorium VPN w VirtualBox: VM bramy kontra sieć tylko dla hosta

Musisz zdecydować, ile maszynerii zasługuje Twoje laboratorium VPN. Rutowana VM bramy między dwoma segmentami VirtualBox odtwarza translację adresów, ścieżkę powrotną i pozycję zapory, za którą siedzi prawdziwy klient. Jeden segment tylko dla hosta daje jedną kontrolowaną bramę i nic więcej. Wersja z bramą kosztuje trzy goście i tablicę routingu, którą utrzymujesz; wersja tylko dla hosta kosztuje jednego gościa i jedną politykę. Trzy pytania je rozdzielają, a trzecie decyduje, czy twój test może w ogóle przejść.

Odpowiedz na trzy pytania, zanim cokolwiek sklonujesz

Zacznij od tego, co musi obserwować serwer VPN. Jeśli serwer ma widzieć adres źródłowy, który nie należy do gościa testowego, coś musi tłumaczyć między nimi, a tym czymś musi być router, który kontrolujesz. Sieć tylko dla hosta daje hostowi adapter w segmencie gościa, a nie tłumacza. Kiedy gość musi potem dotrzeć do czegoś na zewnątrz, podłączasz adapter NAT, a własny silnik NAT VirtualBox przepisuje źródło, nie pytając cię.

Następnie zapytaj, czy gość może dotrzeć do czegokolwiek inaczej niż przez tunel. Ta odpowiedź wybiera wewnętrzną albo tylko dla hosta, i to jest pytanie, które większość opisów laboratoriów pomija. Na koniec zapytaj, co musi się stać, gdy tunel padnie, bo to decyduje o polityce, a nie o topologii, a laboratorium, które dowodzi tylko szczęśliwej ścieżki, nie sprawdziło prawie niczego.

Połącz trzy role sieciami wewnętrznymi

Użyj trzech gości i dwóch nazwanych segmentów, a brama ma być jedyną maszyną z adapterem na obu:

VBoxManage modifyvm lab-client --nic1 intnet --intnet1 WAN
VBoxManage modifyvm lab-server --nic1 intnet --intnet1 LAN
VBoxManage modifyvm lab-gw --nic1 intnet --intnet1 WAN --nic2 intnet --intnet2 LAN

Nie ma osobnego kroku tworzenia sieci wewnętrznej. Ciąg w --intnet1 jest segmentem: dwie maszyny dzielą go tylko wtedy, gdy nazwa zgadza się dokładnie, i nic na hoście nie jest do niego podłączone. Właśnie ta ostatnia właściwość jest powodem, dla którego laboratorium powtarza się czysto, ponieważ trasy hosta, jego własny klient VPN i jego zapora nie mogą przypadkowo dotrzeć do gości. Segment wewnętrzny nie ma też serwera DHCP, chyba że go dodasz, więc adresy statyczne są najkrótszą drogą.

Daj klientowi tylko jego adres WAN, a brama domyślna ma wskazywać adres WAN bramy. Serwer dostaje adres LAN i używa adresu LAN bramy jako swojej bramy domyślnej. Gość, który trzyma dwa adresy w jednym segmencie albo ma zabłąkaną trasę do drugiego segmentu, ma ścieżkę wokół routera, a testy poniżej będą cię okłamywać.

Trzymam plik tekstowy obok nazw VM z czterema adresami i dwiema nazwami segmentów i wklejam go do każdej powłoki. Tygodnie później, gdy zmiana profilu coś psuje, ten plik jest różnicą między debugowaniem profilu a debugowaniem własnej pamięci.

Wybierz wewnętrzny albo tylko dla hosta dla segmentu, który nie może przeciekać

Tryb tylko dla hosta tworzy wirtualny adapter na samym hoście, zwykle vboxnet0, i daje hostowi adres w segmencie gościa. To wygodne w administracji i zgubne dla testu izolacji, ponieważ host może teraz dotrzeć do gościa bezpośrednio, a każda usługa po stronie hosta staje się możliwą ścieżką. Tryb wewnętrzny nie ma w ogóle adaptera hosta. Dwa tryby łatwo pomylić w panelu ustawień sieci, więc sprawdź udokumentowaną różnicę, a nie etykietę (zobacz stronę szczegóły sieci VirtualBox).

Dla gościa, który musi korzystać z tunelu, wewnętrzny jest bezpieczniejszym ustawieniem domyślnym, a brama jedynym wyjściem. Jeśli zostawiasz tylko dla hosta, traktuj adapter hosta jako ścieżkę zarządzania i powiedz to głośno: host może dotrzeć do gościa, a gość nie może używać hosta jako wyjścia.

VBoxManage modifyvm lab-client --nic1 hostonly --hostonlyadapter1 vboxnet0

Izolacja, którą możesz udowodnić, to izolacja, którą skonfigurowałeś. Gość z jednym wewnętrznym adapterem, trasą domyślną na bramie i bez adaptera NAT nie ma ścieżki omijającej bramę. Gość z adapterem tylko dla hosta i adapterem NAT ma dwie ścieżki, i tylko jedna z nich jest tą, którą chciałeś przetestować.

Rutuj i tłumacz na bramie, a potem spraw, by zawiodła zamknięta

VirtualBox nie przekazuje między segmentami; robi to gość. Gdy VM serwera VPN stoi za bramą, włącz przekazywanie i tłumacz ruch klienta, gdy wychodzi w stronę serwera:

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE

Z tą regułą serwer widzi adres LAN bramy zamiast adresu klienta, i właśnie tak wygląda prawdziwy klient za NAT-em operatora z punktu widzenia głowicy sieci. Zapisz wartość sysctl w /etc/sysctl.d/, a regułę w tej usłudze zapory, której używa dystrybucja, inaczej restart po cichu przywróci laboratorium do stanu rutowanego, ale nieprzetłumaczonego.

Przekazywanie nie jest autoryzacją. W ramach domyślnej polityki FORWARD o wartości ACCEPT gość, którego trasa domyślna wskazuje bramę, wychodzi przez interfejs wybrany przez tablicę routingu, z tunelem lub bez. Jeśli brama ma też adapter NAT do instalacji pakietów, ten adapter jest działającym niezaszyfrowanym wyjściem w chwili, gdy tunel padnie, a twój test tylko-VPN nigdy nie był testem tylko-VPN.

Gdy serwer jest zdalny, a tunel kończy sama brama, ta sama decyzja wskazuje interfejs tunelu, a nie kartę sieciową, która dociera do internetu:

iptables -P FORWARD DROP
iptables -A FORWARD -i eth0 -o tun0 -j ACCEPT
iptables -A FORWARD -i tun0 -o eth0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Trzymaj własny zewnętrzny transport tunelu i trasę zarządzania poza pasmem oddzielnie od przekazywanego ruchu. Jeśli jedynym sposobem naprawy bramy jest przejście przez tunel, który debugujesz, laboratorium staje się ćwiczeniem z zablokowania. Konsola szeregowa, adapter zarządzania tylko dla hosta albo migawka znanego dobrego stanu są tańsze niż ręczne odzyskiwanie zepsutego routera.

Weryfikuj ścieżkę z gościa, a nie z hosta

Pracuj na zewnątrz. Potwierdź, że klient dociera do adresu WAN bramy, potem do serwera przez bramę, a potem że połączenie do portu VPN wychodzi i wraca. Przechwycenie na obu interfejsach bramy pokazuje, czy odpowiedź dociera i czy jest odrzucana na ścieżce powrotnej, czego przechwycenie tylko na kliencie nie rozróżni:

tcpdump -ni eth0 udp port 1194
tcpdump -ni tun0 udp port 1194

Potem udowodnij wyjście. Zapytaj z gościa usługę odbicia adresów, jaki widzi adres źródłowy, i porównaj to z własnym adresem wyjścia bramy; jeśli odpowiedź zgadza się z adresem hosta, istnieje ścieżka wokół tunelu. Sprawdź, którego resolvera gość naprawdę używa, i sprawdź IPv6 osobno, bo segment, w którym IPv6 jest włączone, a tunel niesie tylko IPv4, przecieka z założenia, a nie przypadkiem.

Na koniec zepsuj to celowo. Zatrzymaj tunel albo zablokuj jego port zewnętrzny i otwórz nowe połączenie z gościa. Musi się nie udać, a powód musi być taki, który potrafisz nazwać: brak trasy, reguła odrzucania albo martwy resolver. Uruchom tunel ponownie i potwierdź, że gość wraca do zdrowia bez przebudowy sieci. Jeśli mesh VPN, taki jak Hamachi albo ZeroTier, dzieli laboratorium, pamiętaj, że mostkowany adapter podąża za nazwą adaptera, a nie za meshem, więc most trzeba przekierować po tym, jak klient zainstaluje własny wirtualny adapter.

VBoxManage list bridgedifs
VBoxManage modifyvm lab-client --bridgeadapter1 <mesh-adapter-name>

Współdzielenie tunelu gościa z hostem odzwierciedla problem. Skierowanie trasy domyślnej hosta na gościa działa, podobnie jak proxy w gościu; NAT przez hosta nie niesie tunelu gościa dla ruchu, który rozpoczął host. Zapisz nazwy segmentów i reguły zapory w jednym miejscu, zrób migawkę działającego stanu i zanotuj adres źródłowy, który zaobserwował serwer. Następna zmiana profilu kosztuje wtedy jedno uruchomienie skryptu zamiast przebudowanego laboratorium.