Połączono z OpenVPN, ale nic się nie ładuje: przejście od klienta na zewnątrz

Okno klienta pokazuje Connected, adres tunelu jest, a przeglądarka wciąż się kręci. Ta kombinacja jest normalna, bo udany handshake dowodzi tylko, że tunel został zbudowany; nie mówi nic o tym, czy serwer będzie przekazywał twoje pakiety, przepisywał ich źródło lub odpowiadał na twoje zapytania DNS. Błąd, który popełnia większość, to otwarcie najpierw konfiguracji serwera. Zamiast tego pracuj od klienta na zewnątrz, bo każdy krok poniżej mówi, czy następny w ogóle warto sprawdzać.

Zacznij od klienta i idź na zewnątrz

Wykonaj trzy testy w tej kolejności i zapisz, gdzie zawodzi pierwszy. Pingnij adres tunelu serwera, co dowodzi, że sam tunel przenosi ruch. Pingnij publiczny adres po numerze, co dowodzi przekazywania i tłumaczenia bez angażowania rozwiązywania nazw. Następnie spróbuj rozwiązać nazwę hosta, co jest jedynym testem, który używa DNS. Każdy wynik usuwa całą warstwę z podejrzeń.

Nie przeskakuj do trzeciego testu, bo przeglądarka wydaje się szybsza. Nieudane wczytanie strony obejmuje wszystkie trzy warstwy naraz, i właśnie od tego ludzie zaczynają, a potem odbudowują działający tunel. Strona, która zawodzi, nie mówi, która z trzech warstw się zepsuła.

Dwa przechwycenia pokazują, gdzie zatrzymują się pakiety

Gdy z klienta biegnie ping do publicznego adresu, zrób jedno przechwycenie na interfejsie tunelu, a drugie na łączu wyjściowym, które powinno dotrzeć do internetu. Uruchom oba jednocześnie, aby znaczniki czasu się zgadzały.

sudo tcpdump -ni tun0 -c 20 icmp
sudo tcpdump -ni enp1s0 -c 20 icmp

Jeśli żądania pojawiają się na tunelu i nigdy na łączu wyjściowym, serwer je odrzucił między tunelem a kablem, a przyczyną jest przekazywanie lub polityka zapory dla przekazywania, nie NAT. Jeśli pojawiają się na obu, serwer zrobił swoje, a odpowiedzi brakuje dalej, co wskazuje na tłumaczenie, filtr wyżej lub ograniczenie ze strony dostawcy.

Weź nazwę łącza wyjściowego z tabeli routingu, a nie z poradnika. Obrazy chmurowe i przemianowane adaptery rzadko pasują do przykładowego interfejsu z poradnika, a przechwycenie na złym urządzeniu wygląda dokładnie jak serwer, który nie przekazuje:

ip -4 route get 9.9.9.9

Pole dev w tym wyniku to nazwa, której reguła NAT będzie potrzebować później, więc ją zachowaj.

Przekazywanie to przełącznik w jądrze i polityka zapory

Jądro musi w ogóle zgodzić się przekazywać. Odczytaj bieżącą wartość, a następnie uczyń ustawienie trwałym, zamiast zapisywać je tylko w działającym jądrze:

sysctl net.ipv4.ip_forward
printf 'net.ipv4.ip_forward=1\n' > /etc/sysctl.d/70-vpn-forward.conf
sysctl --system

Przekazywanie to tylko połowa. Na hoście z UFW politykę przekazywania ustawia się w /etc/default/ufw i musi być ACCEPT, zanim przeładowanie zacznie działać. Domyślne odrzucanie na ścieżce przekazywania zostawia handshake całkowicie zdrowym, ale po cichu wyrzuca każdy pakiet, który próbuje wyjść przez tunel, i to jest dokładnie ten objaw, z którym zacząłeś.

Hosty zarządzające nftables bezpośrednio mają to samo pytanie w innej składni. Patrz na liczniki łańcucha przekazywania, gdy trwa test z klienta, bo łańcuch, do którego się odwołuje, i łańcuch, który odrzuca, wyglądają w pliku konfiguracji identycznie.

Nazwij rzeczywisty interfejs wyjściowy w regule NAT

Tłumaczenie źródła należy do interfejsu, który naprawdę opuszcza host, z pulą, którą serwer przydziela. Obie połowy tej reguły muszą opisywać rzeczywistość i żadna nie jest opcjonalna.

iptables -t nat -A POSTROUTING -s 10.44.0.0/24 -o enp1s0 -j MASQUERADE

Klasyczna porażka to reguła skopiowana z poradnika, która mówi -o eth0 na maszynie, której adapter nazywa się inaczej. Reguła instaluje się bez ostrzeżenia, do niczego nie pasuje, a klient nadal nie ma internetu. Pula to druga połowa tego samego błędu: jeśli serwer przydziela 10.44.0.0/24, a reguła obejmuje 10.8.0.0/24, nic nigdy nie będzie pasować.

Patrz na liczniki, zamiast wierzyć tekstowi reguły. Lista podaje pakiety na regułę, a reguła, która nigdy nie pasuje, pozostaje na zerze, choćby wyglądała najpoprawniej. Daj jej minutę prawdziwego ruchu klienta, zanim cokolwiek z tej liczby wyczytasz:

iptables -t nat -L POSTROUTING -v -n

Zerowy licznik pakietów po prawdziwym teście klienta oznacza, że dopasowanie jest błędne, a nie że tunel jest zepsuty. Gdy zacznie pasować, zapisz zestaw reguł, aby przetrwał restart; poprawka, która żyje tylko w historii twojej powłoki, znika przy pierwszym restarcie.

Jeśli serwer jest także instancją NAT w chmurze, platforma też ma głos. Instancja, która tłumaczy adresy, zwykle wymaga wyłączonego sprawdzania źródła i miejsca docelowego tam, gdzie dostawca oferuje takie ustawienie, a sam port VPN musi być osiągalny z zewnątrz.

DNS to druga awaria za pierwszą

Ping po adresie, który działa, gdy nazwy zawodzą, to problem resolvera, i ma własną przyczynę. Klient, który zachowuje swój lokalny resolver, wysyła te zapytania w pełny tunel i czeka na odpowiedź, która nigdy nie przychodzi, bo lokalny resolver jest teraz po niewłaściwej stronie trasy.

Wyślij resolver z serwera, aby klient wiedział, gdzie pytać. Dwa wpisy dają klientowi zapas, jeśli pierwszy jest nieosiągalny, i oba powinny być resolverami, które tunel rzeczywiście dopuszcza.

push "dhcp-option DNS 9.9.9.9"
push "dhcp-option DNS 149.112.112.112"

Klienci Windows mogą potem i tak wrócić do lokalnego resolvera, i właśnie temu block-outside-dns ma zapobiegać, kosztem utraty nazw, które potrafi rozwiązać tylko sieć lokalna. Klienci Linuksa z systemd-resolved często ignorują wysłany resolver, jeśli skrypt go nie zainstaluje, więc sprawdź resolvectl status dla urządzenia tunelu, zanim uznasz, że wysłanie zostało zignorowane.

Zakończ przejście tak, jak doświadcza go użytkownik. Wczytaj prawdziwą stronę z klienta, potwierdź adres, z którego wychodzi, zrestartuj serwer, połącz się ponownie i powtórz trzy testy. Tylko ten drugi przebieg dowodzi, że zapisane reguły, polityka zapory i wysłany resolver przetrwały wszystkie razem.