Dlaczego net.ipv4.conf.default.forwarding zostawia tun0 w spokoju

Ustawiono net.ipv4.conf.default.forwarding=1, zrestartowano VPN, a tunel nadal odrzuca pakiety, które brama powinna routować. Ustawienie w pliku wygląda poprawnie, a interfejs nadal zgłasza, że przekazywanie jest wyłączone. Nic nie jest zepsute: zmieniono wartość, którą odziedziczą przyszłe interfejsy, a nie tę, której używa żywy tunel.

Przejdź to na hoście, który posiada tunel, w namespace sieciowym, w którym tunel naprawdę istnieje. Kontener lub namespace sieciowy może trzymać interfejs, podczas gdy host pokazuje inne liczby.

Czytaj trzy wartości razem

Zacznij od porównania przełącznika dla całej bramy, szablonu dla nowych interfejsów i interfejsu, który cię interesuje. Zastąp tun0 rzeczywistym interfejsem wejściowym i odczytaj także interfejs powrotny, ponieważ przekazywanie jest oceniane w punkcie, w którym pakiet dociera.

sysctl net.ipv4.ip_forward
sysctl net.ipv4.conf.default.forwarding
sysctl net.ipv4.conf.tun0.forwarding

Częsty wynik to ip_forward = 0, default.forwarding = 1 i tun0.forwarding = 0. Pierwsze dwie nie zgadzają się co do roli hosta, a trzecia pokazuje, co interfejs naprawdę robi. Ta kombinacja pasuje do hosta, który nigdy nie był konfigurowany jako router, tylko dostał wartość szablonu. Trzy liczby nie są sprzeczne; odpowiadają na trzy różne pytania. Zapisanie wartości szablonu też nie rozstrzyga roli hosta.

Dlaczego rusza się właśnie przełącznik globalny

net.ipv4.ip_forward to sterowanie dla całej bramy. Jego zmiana aktualizuje ustawienia przekazywania dla poszczególnych interfejsów w ramach tej samej operacji, dlatego jeden zapis może sprawić, że istniejący tunel zacznie przekazywać. default.forwarding zasiewa tylko interfejsy inicjalizowane później, więc tunel, który już istniał, zachowuje wartość, z którą się urodził.

Dokumentacja jądra oznacza ip_forward jako szczególne z powiązanego powodu: jego zmiana resetuje zestaw innych parametrów IPv4 do domyślnych wartości hosta lub routera. To czyni go tępym narzędziem. Ustawienie go raz w ramach ustalania roli bramy jest w porządku; przełączanie go wielokrotnie jako sztuczki debugowania może po cichu nadpisać konfigurację, na którą poświęcono czas.

Wartości dla poszczególnych interfejsów też istnieją nie bez powodu. Świadomie zarządzana brama może trzymać przekazywanie wyłączone na interfejsie, który nigdy nie powinien routować, nawet gdy host przekazuje gdzie indziej. Dlatego ważne jest czytanie żywego interfejsu i dlatego sama wartość globalna nie jest całą odpowiedzią. Czytaj taki wyjątek jako świadomą decyzję i zapisz, dlaczego ten interfejs jest inny. Inaczej następny inżynier "naprawi" go z dobrego serca.

Uczyń ustawienie trwałym we właściwym miejscu

Jednorazowy udany sysctl -w dowodzi, że jądro akceptuje wartość. Nie przetrwa restartu ani menedżera sieci, który przy ponownym połączeniu ponownie stosuje własne wyobrażenie o konfiguracji interfejsu. Umieść rolę bramy w pliku konfiguracyjnym sysctl lub w menedżerze sieci, który posiada host, a następnie zrestartuj usługę, która ją stosuje.

Kolejność ma znaczenie przy tunelach. Jeśli menedżer tworzy interfejs przy starcie i stosuje przekazywanie później, interfejs może odziedziczyć starą wartość domyślną. Restart usługi, która odtwarza tunel, też jest zdarzeniem tworzenia i łatwo to przeoczyć, gdy unit wygląda zdrowo. Sprawdź sekwencję, nie tylko końcową zawartość pliku.

Przeczytaj ponownie te same trzy wartości po ponownym połączeniu VPN i jeszcze raz po restarcie. Nowo utworzony tunel to nowy interfejs, a nowy interfejs przyjmuje wartość domyślną obowiązującą w chwili utworzenia. Jeśli liczby zmieniają się między tymi zdarzeniami, konfigurację stosuje coś, czego jeszcze nie zidentyfikowano.

Nie naprawiaj tego niewłaściwym narzędziem

Gdy przekazywanie wyglądało na zepsute, kusi, by wyczyścić zaporę lub dodać masquerading. Żadne z nich nie dotyczy przełącznika przekazywania. Stan przekazywania, pozwolenie na przekazywanie, trasa do celu i droga powrotna to cztery osobne wymagania, a tylko pierwsze jest sysctl.

Testuj też właściwym przepływem. Żądanie wykonane na samej bramie w ogóle nie ćwiczy przekazywania; to ruch generowany lokalnie. Pytanie brzmi, czy pakiet przychodzący od klienta VPN lub hosta LAN jest akceptowany i routowany dalej, więc test musi zaczynać się za bramą.

Trzymaj przypadek IPv6 osobno

Tutaj wszystko jest IPv4. Przekazywanie IPv6, ogłoszenia routera i zachowanie accept_ra mają własne sterowanie, a kopiowanie ścieżki ipv4 do ustawienia ipv6 daje plik, który wygląda wiarygodnie i nie robi nic użytecznego. Brama z dwoma stosami potrzebuje świadomie skonfigurowanych obu zestawów.

Ostatnia kontrola: gdy wartości się zgadzają, potwierdź, że trasa tunelu jest wybierana dla celu i że droga powrotna istnieje. Przekazywanie włączone na interfejsie bez trasy nadal jest czarną dziurą, a ta awaria wygląda z strony klienta identycznie.