Klienci VPN łączą się, ale nie ma internetu: trzy brakujące elementy

Klient dostaje adres, serwer odpowiada na ping, a każda strona i tak kończy się przekroczeniem czasu. Większość ludzi zaczyna w tym miejscu edytować profil klienta, co zwykle jest stratą czasu: gdy tunel jest podniesiony, serwer musi zachowywać się jak router. Trzy warunki muszą być spełnione jednocześnie, zanim pakiet wyjdzie i wróci odpowiedź, a objaw jest taki sam, którego by nie brakowało.

Dlaczego działający tunel nadal nie ma drogi na zewnątrz

Jądro musi przekazywać pakiety między interfejsami, co w większości dystrybucji Linux jest domyślnie wyłączone. Ruch musi być tłumaczony na adres, na który świat zewnętrzny może odpowiedzieć, chyba że każdy router nadrzędny zna już trasę powrotną do podsieci tunelu. Ścieżka przekazywania zapory musi zezwalać na ruch w obu kierunkach, łącznie z odpowiedziami.

Każdy z tych elementów można naprawić osobno i właśnie w tym tkwi pułapka. Włączenie przekazywania bez reguły tłumaczenia sprawia, że pakiety wychodzą z prywatnym źródłem i bez drogi powrotnej. Dodanie tłumaczenia bez reguły przekazywania sprawia, że jądro odrzuca pakiet o krok później.

Dlatego testuj trzy warstwy, a nie klienta, i zmieniaj po jednej, żeby wynik coś znaczył.

Przekazywanie to przełącznik jądra, który trzeba utrwalić

Sprawdź bieżącą wartość przed zmianą, następnie ją ustaw i potwierdź, że zmiana weszła w życie.

sysctl net.ipv4.ip_forward
sysctl -w net.ipv4.ip_forward=1
sysctl net.ipv4.ip_forward

Pierwsze polecenie zgłasza bieżącą wartość, drugie ustawia ją w czasie działania, a trzecie dowodzi, że zapis zadziałał. Wartość czasu działania znika przy następnym rozruchu, dlatego działająca sesja może się zepsuć po konserwacji bez żadnej zmiany konfiguracji.

Utrwal ją w pliku pod /etc/sysctl.d/, a następnie zastosuj ten plik zamiast restartu, żeby się dowiedzieć. W FreeBSD odpowiednikiem jest net.inet.ip.forwarding, a dla trwałości gateway_enable=YES w rc.conf. Urządzenie, które zgłasza wyłączone przekazywanie, wyjaśnia całą klasę zgłoszeń „pakiety przychodzą i nic nie wraca”. Sprawdzaj ustawienie także po każdej aktualizacji, bo przebudowane jądro lub wymieniony obraz urządzenia mogą je zresetować, nie mówiąc nikomu.

Wybierz masquerade albo jeden stały adres tłumaczenia

Przy dynamicznym adresie zewnętrznym masquerading jest najprostszą poprawną formą. Wskaż podsieć tunelu jako źródło, a interfejs zewnętrzny jako wyjście.

iptables -t nat -A POSTROUTING -s 10.9.0.0/24 -o eth0 -j MASQUERADE

Przy statycznym adresie publicznym tłumaczenie źródła na dokładnie ten adres jest bardziej przewidywalne i łatwiejsze do audytu.

iptables -t nat -A POSTROUTING -s 10.9.0.0/24 -j SNAT --to-source 198.51.100.10

Druga forma niesie pułapkę konserwacyjną: zaszyty na stałe adres, który później się zmienia, utrzymuje tunel w działaniu, podczas gdy dostęp do internetu po cichu się zatrzymuje. Albo używaj masquerade, albo aktualizuj regułę za każdym razem, gdy dostawca cię przenosi. Interfejs też ma znaczenie, ponieważ router współdzielący własny tunel nadrzędny musi tłumaczyć przez ten tunel, a nie przez fizyczny WAN.

Tabela filtrów to trzecia brama

Przekazywanie i tłumaczenie mogą być oba poprawne, a pakiet i tak ginie w tabeli filtrów. ufw jest częstym winowajcą: jego polityka przekazywania jest dostarczana jako DROP, a reszta konfiguracji może wyglądać całkowicie poprawnie, podczas gdy to jedno ustawienie zabija ruch. Podniesienie jej to świadoma decyzja o bezpieczeństwie, a nie pole wyboru.

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

Pierwsza reguła pozwala na nowy ruch z tunelu na zewnątrz, a druga tylko na odpowiedzi z powrotem. Zawęź obie do podsieci tunelu i zamierzonego celu, ponieważ ogólne zezwolenie na interfejsie tunelu zamienia VPN w otwarty punkt wyjścia dla każdego, kto potrafi się uwierzytelnić.

Tunel mostkowany wymaga innej odpowiedzi. Adres należy do mostu, a nie do portu fizycznego, więc podporządkowanie interfejsu usuwa adres, który miał wcześniej, i host wygląda na nieosiągalny, dopóki sam most nie otrzyma adresu, co może zapewnić dhclient br0. Ta awaria wygląda jak problem VPN, a jest problemem drugiej warstwy. Sprawdź własny adres mostu, zanim dotkniesz zapory, ponieważ zmiana filtra nie naprawi hosta, który nie ma już adresu, z którego mógłby wysyłać.

Gdzie patrzeć, gdy strona nigdy się nie ładuje

Pingnij adres tunelu serwera, aby udowodnić, że tunel istnieje. Następnie uruchom traceroute z klienta do adresu publicznego i odczytaj, gdzie się zatrzymuje: na serwerze pakiet dociera, ale nie jest przekazywany ani tłumaczony; za serwerem problem jest powyżej i poza twoimi rękami.

ping -c 3 10.9.0.1
traceroute -n 198.51.100.10

Pierwsze polecenie dowodzi, że tunel niesie ruch do samego serwera, a drugie pokazuje, jak daleko pakiet dociera na zewnątrz. Ślad kończący się na adresie tunelu wskazuje na przekazywanie lub tłumaczenie na serwerze, natomiast ślad zatrzymujący się o jeden skok dalej wskazuje na dostawcę lub trasę powrotną routera nadrzędnego.

Na serwerze obserwuj interfejs zewnętrzny, gdy klient ładuje stronę. Ruch wychodzący z prywatnym adresem źródłowym oznacza brak tłumaczenia, a całkowity brak odpowiedzi oznacza, że ścieżka przekazywania lub trasa powrotna powyżej go odrzuca.

Jeśli klienci zdalni muszą też docierać do hostów w sieci LAN serwera, pamiętaj, że LAN potrzebuje trasy powrotnej do podsieci tunelu. To routing, a nie tłumaczenie, i to krok najczęściej zapominany, gdy droga do internetu w końcu działa.