Routing ruchu VM w sieci host-only przez serwer TUN OpenVPN

Adaptery host-only tworzą lokalną sieć wirtualną, a rutowane tunele TUN przenoszą pakiety IP między adresami. Żaden z nich nie jest mostem do drugiego, dlatego działająca konfiguracja musi powiedzieć, kto przekazuje i do kogo należy trasa powrotna. Pomylenie tych dwóch przypisań sprawia, że gość odpowiada tunelowi źródłem, o które klient tunelu nigdy nie prosił. Poniższy projekt utrzymuje oba prefiksy osobno i czyni trasę powrotną jawną.

Dwie sieci, dwa prefiksy

Nadaj puli tunelu i sieci host-only różne prefiksy i nigdy nie używaj jednego zamiast drugiego. W tym przykładzie pula VPN to 10.44.0.0/24, a sieć host-only to 192.168.99.0/24, host jest pod 192.168.99.1, a gość pod 192.168.99.20. Przydzielenie tego samego prefiksu zarówno urządzeniu TUN, jak i adapterowi host-only nie łączy ich. Tworzy dwa roszczenia do jednego zakresu adresów, a tabela routingu odpowiada potem za to roszczenie, które przypadkiem zachowała.

Adapter host-only istnieje na hoście i wewnątrz gościa, i sam z siebie nie ma drogi poza maszynę. Połączenia mostkowe i NAT mają inną ekspozycję, a przejście w tryb mostka nie jest warunkiem dotarcia do jednej usługi gościa.

Host już ma tę drogę

Zobacz, co istnieje, zanim coś dodasz. Host ma interfejs w sieci host-only i trasę dla tego prefiksu, oba utworzone przy podnoszeniu adaptera.

ip -br addr show
ip route show 192.168.99.0/24
sysctl net.ipv4.ip_forward

Trzecia linia to mechanizm, który czyni hosta przeskokiem. Bez niej pakiet przychodzący z tunelu jest adresowany do sieci, do której host dotrze, ale której nie przekieruje. Przekazywanie jest konieczne i niewystarczające. Polityka filtrowania nadal decyduje, czy konkretny przepływ między interfejsem tunelu a interfejsem host-only jest dozwolony, a ta decyzja należy do zapisu, a nie do domyślnej polityki, której nikt nie przeczytał.

Wypchnij trasę, a potem filtruj to, co osiąga

Serwer może dostarczyć prefiks host-only klientom, którzy akceptują wypchnięte trasy, co jest tym samym mechanizmem, który stosuje się do każdej innej podsieci za tunelem.

push "route 192.168.99.0 255.255.255.0"
iptables -A FORWARD -i tun0 -o vboxnet0 -d 192.168.99.20 -p tcp --dport 5432 -j ACCEPT
iptables -A FORWARD -i vboxnet0 -o tun0 -s 192.168.99.20 -p tcp --sport 5432 -m conntrack --ctstate ESTABLISHED -j ACCEPT

Te dwie reguły zezwalają na jedną usługę w jednym kierunku i jej odpowiedzi. Trasa sięgająca całego prefiksu i filtr zezwalający na jeden port to zamierzona kombinacja; trasa plus bezwarunkowa akceptacja to sposób, w jaki usługa laboratoryjna staje się usługą wystawioną. Wypchnięta trasa również nie jest autoryzacją. Klient ją akceptuje, host ją przekazuje, a zapora gościa i sama usługa nadal mają głos.

Gość potrzebuje drogi powrotnej

Gość osiągany z 10.44.0.x musi wysyłać swoje odpowiedzi na adres host-only hosta albo host musi tłumaczyć źródło. Otrzymanie adresu z DHCP VirtualBox nie mówi nic o żadnym z tych dwóch układów.

ip route add 10.44.0.0/24 via 192.168.99.1 dev enp0s8
ip route get 10.44.0.15

Dodanie tej trasy wewnątrz gościa zachowuje pierwotne źródło, co utrzymuje sensowną politykę i logi na klienta. Ograniczone tłumaczenie źródła na hoście jest alternatywą i działa, ale za cenę ukrycia, który klient się połączył. Nakładanie się jest drugim trybem awarii. Zdalny klient, którego domowa sieć LAN już używa 192.168.99.0/24, odczyta wypchniętą trasę jako własną sieć, a żadna zmiana po stronie serwera nie naprawi tej niejednoznaczności. Ponumeruj jedną stronę albo wybierz prefiks, który raczej się nie zderzy.

Urządzenie TUN przenosi pakiety IP, więc dodanie domyślnej bramy wewnątrz gościa nie czyni tunelu segmentem Ethernet z adapterem host-only. Most TAP to inny projekt z własnym wsparciem klientów i własnością adresów, a mieszanie obu opisów prowadzi do konfiguracji, które nigdy się nie zbiegają.

Zweryfikuj, a potem spraw, by przetrwało restart

Przetestuj jedną nieszkodliwą usługę ze zwykłego zdalnego klienta, sprawdź trasę powrotną gościa i potwierdź, że usługa, której nie zezwoliłeś, jest odrzucana, a nie wolna.

ss -lntp '( sport = :5432 )'
conntrack -L | grep 192.168.99.20

Następnie zrestartuj usługę VPN i sieć maszyny wirtualnej i powtórz te same trzy kontrole. Trasa dodana ręcznie przetrwa do następnego restartu, a konfiguracja działająca tylko w ciepłej sesji nie jest projektem. Zapisz razem oba prefiksy, politykę przekazywania i trasę gościa. Kto doda następną maszynę wirtualną, będzie potrzebował wszystkich trzech i inaczej odkryje je od nowa przy każdym nieudanym połączeniu.