Udostępnij jedno połączenie VPN wszystkim urządzeniom w sieci LAN

Jeden laptop utrzymuje tunel, reszta domu chce tego samego dostępu, a pierwsza próba polega na skierowaniu wszystkiego do podłączonej maszyny. To zawodzi z powodów, które nie mają nic wspólnego z VPN: host odbierający musi przekazać pakiet dalej, przepisać jego źródło i dopilnować, aby odpowiedzi znalazły drogę powrotną. Pominięcie któregokolwiek z trzech elementów sprawia, że podłączony laptop nadal działa, a każde inne urządzenie kończy się przekroczeniem czasu. Rozwiązaniem jest projekt routingu, a nie ustawienie klienta.

Dlaczego kierowanie urządzeń na host zawodzi

Host, który odbiera pakiet zaadresowany do sieci zdalnej, staje się na ten moment routerem, niezależnie od tego, czy ktoś skonfigurował go w ten sposób. Przekazywanie jest domyślnie wyłączone w systemie Linux i Windows, chyba że włączy je jakaś funkcja. Tłumaczenie adresów ma znaczenie, ponieważ strona zdalna musi wiedzieć, gdzie wysłać odpowiedzi, a prywatny adres LAN nic dla niej nie znaczy. Trasa powrotna to trzeci element i to właśnie o nim ludzie zapominają, gdy pierwszy ping wydaje się udany.

Diagnozuj w tej kolejności, zamiast losowo przełączać ustawienia. Każdy brakujący element daje nieco inny objaw.

Włącz przekazywanie i tłumaczenie adresów na hoście

Dwie zmiany na podłączonym hoście obejmują pierwsze dwa elementy: włącz przekazywanie IPv4 i przetłumacz ruch LAN na interfejs tunelu.

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

Zapisz wartość sysctl w pliku w katalogu /etc/sysctl.d i po ponownym uruchomieniu sprawdź ponownie regułę masquerade, ponieważ frontendy zapory mogą czyścić niestandardowe łańcuchy. W systemie Windows funkcja udostępniania wykonuje oba kroki, ale także ponownie adresuje adapter LAN na stałą podsieć i usuwa jego bramę, co psuje statyczne adresowanie i przekazywanie portów. Przywróć trasę routera do hosta pod jego nowym adresem, zanim uznasz, że udostępnianie się nie udało. Następnie obserwuj, jak liczniki reguły rosną, gdy drugie urządzenie wysyła ruch.

Daj sieci LAN trasę, która przetrwa restarty

Pozostałe urządzenia potrzebują trasy do zdalnego prefiksu, a dwa sposoby jej zapewnienia różnią się zasięgiem skutków.

ip route add 10.8.0.0/24 via 192.168.1.20 dev eth0

Skierowanie domyślnej bramy klienta na host wysyła cały jego ruch przez host, w tym lokalne drukowanie i udostępnianie plików, więc niepowiązane rzeczy zatrzymują się, gdy host zasypia. Dodanie konkretnej trasy na routerze dla zdalnego prefiksu jest węższe: tylko miejsca docelowe za tunelem trafiają do podłączonej maszyny, a reszta sieci LAN działa dalej. Podsieci powyżej to przykłady, więc zastąp je własnymi zakresami LAN i tunelu. Tak czy inaczej, przetestuj z drugiego urządzenia przy włączonym, a potem wyłączonym tunelu.

Uważaj na MTU, zanim obwinisz tunel

Tunele zmniejszają użyteczny rozmiar pakietu, a drugie urządzenie nie ma o tym pojęcia. Duże transfery i uzgadnianie TLS zatrzymują się, podczas gdy małe żądania kończą się sukcesem.

ping -M do -s 1400 10.8.0.5

Odpowiedź dowodzi, że taki rozmiar przechodzi przez ścieżkę bez fragmentacji; przekroczenie czasu oznacza, że narzut enkapsulacji wypchnął pakiet poza MTU tunelu. Zmniejsz MTU na interfejsie udostępniania albo ogranicz maksymalny rozmiar segmentu na przekazującym urządzeniu, a następnie powtórz tę samą próbę. Najpierw sprawdź ten sam rozmiar po stronie LAN, ponieważ lokalna awaria wskazuje na sieć LAN, a nie na tunel. Zapisz działający rozmiar, ponieważ późniejsza zmiana dostawcy lub tunelu może go przesunąć.

Dla jednego dodatkowego urządzenia wystarczy udostępnianie z hosta. Dla całego domu umieść trasę na routerze. Gdy dostęp musi przetrwać wyjazd laptopa razem z tobą, sam tunel powinien znajdować się na dedykowanej bramie.