Spraw, by przekazywanie IPv4 przetrwało restart bramy VPN

Ping do bramy działa, a dotarcie do czegokolwiek za nią nie, i to jest kształt problemu z przekazywaniem, a nie problemu z tunelem. Lokalne dostarczenie do bramy dowodzi, że tunel wstał i że przypisanie adresu zadziałało; nie mówi nic o tym, czy jądro przepuści pakiet z jednego interfejsu do drugiego. Zanim dotkniesz jakiegokolwiek sysctl, potwierdź, że maszyna ma routować ten ruch i zlokalizuj kontekst sieciowy, który trzyma interfejs skierowany do klienta. Potem odczytaj wartość tam, a nie tam, gdzie przypadkiem spojrzał ostatni przeczytany przewodnik.

Dotarcie do bramy to nie to samo co przekazywanie

W jądrze zapadają dwie odrębne decyzje. Dostarczenie na adres lokalny kończy podróż pakietu; przekazywanie wysyła go ponownie przez inny interfejs, a ta druga decyzja jest regulowana dla każdej przestrzeni nazw sieci. Brama może być doskonale osiągalna, gdy przekazywanie jest wyłączone, a z poziomu ping oba błędy wyglądają identycznie.

Zapisz, którym interfejsem pakiet klienta przychodzi i którym interfejsem wychodzi dalsza droga. Oba należą do jednej przestrzeni nazw, a to ta przestrzeń nazw trzyma ustawienie, które ma znaczenie.

Odczytaj wartość tam, gdzie pakiety naprawdę są

Na bramie, która routuje w przestrzeni nazw hosta, jedno polecenie odpowiada na pytanie: sysctl net.ipv4.ip_forward. Gdy droga wejściowa i dalsza żyją w nazwanej przestrzeni nazw, zapytaj tę przestrzeń: ip netns exec vpn-gw sysctl net.ipv4.ip_forward. Wartość hosta nie zastępuje wartości przestrzeni nazw, a jedynka na hoście nie jest dowodem na nic.

Nie każdy kontekst routingu ma etykietę, którą możesz podać do ip netns. Środowiska uruchomieniowe kontenerów i usługi tworzą przestrzenie nazw, które nigdy nie są rejestrowane pod przyjazną nazwą, i dla nich używasz narzędzi inspekcyjnych środowiska. Zastąp vpn-gw prawdziwą nazwą albo mechanizmem środowiska, który osiąga ten sam kontekst, i przestań zgadywać na poziomie hosta.

Daj ustawieniu jednego właściciela

Na konwencjonalnej bramie-hostcie systemd trwałą formą jest plik drop-in o nazwie wybranej przez administratora, taki jak /etc/sysctl.d/60-vpn-forwarding.conf, zawierający net.ipv4.ip_forward = 1. Zapisz plik, a następnie wczytaj właśnie ten plik, aby zmienił się także stan bieżący: sudo sysctl -p /etc/sysctl.d/60-vpn-forwarding.conf, po czym odczytaj ponownie. Nazwa pliku jest przykładem, a nie zarezerwowaną ścieżką VPN, a wiodąca liczba ma znaczenie, bo pliki posortowane później wygrywają.

Pierwszeństwo to miejsce, w którym trwałość cicho się psuje. Sprawdź zarówno loader dystrybucji, jak i własny drop-in, bo procps sysctl --system na końcu czyta także /etc/sysctl.conf, podczas gdy kolejność sysctl.d w systemd to zupełnie inna sekwencja. Późniejsze przypisanie może natychmiast przywrócić ten sam klucz, zostawiając twój plik poprawny, a wartość efektywną błędną. Nie nadpisuj istniejącego pliku administratora, aby wygrać ten spór; znajdź właściciela i zmień to tam.

Przestrzeń nazw utworzona po starcie w ogóle nie jest zarządzana przez drop-in hosta. Jej ustawienie należy do tego, co ją tworzy, czy jest to środowisko uruchomieniowe kontenerów, czy jednostka zaopatrzenia przestrzeni nazw. Danie kontenerowi szerokich uprawnień hosta, by obejść pytanie, jest gorszą transakcją niż dziesięć minut spędzone na ustaleniu właściwego właściciela.

Wiedz, ile kosztuje przełącznik, zanim go przełączysz

ip_forward nie jest nieszkodliwym booleanem. Dokumentacja jądra zauważa, że jego zmiana resetuje kilka innych parametrów IPv4 do wartości domyślnych hosta lub routera, więc diagnostyczne przełączenie może wyrzucić dostrojenie zrobione gdzie indziej i nigdy o tym nie wspomnieć. Traktuj to jako zmianę konfiguracji z efektami ubocznymi, a nie jako sondę, którą można uruchomić od niechcenia.

To wyklucza też wyłączanie i włączanie go za każdym razem, gdy klient nie może dotrzeć do hosta. Jeśli wartość już wynosi jeden, usterka jest gdzie indziej na drodze, a trzecie przepisanie tego samego klucza jej nie przesunie.

Udowodnij trwałość, a potem przetestuj resztę drogi

Odczytaj wartość z powrotem w czterech momentach: zaraz po zmianie, po pojawieniu się interfejsu VPN, po ponownym połączeniu i po zaplanowanym restarcie. Wartość, która cofa się w którymkolwiek z tych punktów, ma drugiego właściciela, a jeszcze jeden jednorazowy zapis tylko to ukrywa do następnego restartu.

Włączone przekazywanie wciąż zostawia trzy rzeczy do sprawdzenia. Klient potrzebuje trasy do celu, brama potrzebuje dalszej trasy plus zgody na jej użycie, a cel potrzebuje drogi powrotnej do adresu tunelu klienta. Prywatna routowana LAN nie potrzebuje automatycznie NAT, więc nie dodawaj masquerading, zanim nie wiesz, której z trzech brakuje, i testuj z zamierzonego klienta, a nie z samej bramy, bo żądanie powstałe na bramie nigdy nie dotyka ścieżki przekazywania, którą właśnie włączyłeś. IPv6 ma własną politykę przekazywania i routingu, więc działający test IPv4 nic o niej nie mówi.

Trzymaj razem w runbooku ścieżkę drop-in, właściciela przestrzeni nazw i polecenie ponownego odczytu. Kto to przejmie następny, powinien umieć odczytać wartość, zobaczyć, kto ją posiada, i w ciągu minuty zdecydować, czy problemem jest trwałość, czy reszta drogi.