Varför net.ipv4.conf.default.forwarding lämnar tun0 i fred

Du satte net.ipv4.conf.default.forwarding=1, startade om VPN, och tunneln släpper fortfarande paket som gatewayen borde routa. Inställningen ser rätt ut i filen, och gränssnittet rapporterar fortfarande att vidarebefordran är avstängd. Inget är trasigt: du ändrade värdet som framtida gränssnitt ärver, inte det som den levande tunneln använder.

Gå igenom detta på värden som äger tunneln, i det nätverks-namespace där tunneln faktiskt finns. En container eller ett nätverks-namespace kan hålla gränssnittet medan värden visar andra siffror.

Läs de tre värdena tillsammans

Börja med att jämföra brytaren för hela gatewayen, mallen för nya gränssnitt och gränssnittet du bryr dig om. Ersätt tun0 med det faktiska ingångsgränssnittet, och läs också returgränssnittet, eftersom vidarebefordran utvärderas vid den punkt där paketet anländer.

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

Ett vanligt resultat är ip_forward = 0, default.forwarding = 1 och tun0.forwarding = 0. De två första är oense om värdens roll, och den tredje visar vad gränssnittet faktiskt gör. Den kombinationen stämmer med en värd som aldrig konfigurerades som router, utan bara fick ett mallvärde. De tre siffrorna motsäger inte varandra; de svarar på tre olika frågor. Att skriva mallvärdet avgör inte heller värdens roll.

Varför det är den globala brytaren som flyttar sig

net.ipv4.ip_forward är styrningen för hela gatewayen. Att ändra den uppdaterar vidarebefordringsinställningarna per gränssnitt som en del av samma operation, och därför kan en enda skrivning få en befintlig tunnel att börja vidarebefordra. default.forwarding sår bara gränssnitt som initieras efteråt, så en tunnel som redan fanns behåller värdet den föddes med.

Kerneldokumentationen markerar ip_forward som speciell av en besläktad anledning: att ändra den återställer en grupp andra IPv4-parametrar till standardvärden för värd eller router. Det gör den till ett trubbigt verktyg. Att sätta den en gång som en del av att etablera gatewayrollen är okej; att växla den upprepade gånger som ett felsökningstrick kan tyst skriva över konfiguration du lagt tid på att få rätt.

Värden per gränssnitt finns också av en anledning. En medvetet hanterad gateway kan hålla vidarebefordran avstängd på ett gränssnitt som aldrig borde routa, även när värden vidarebefordrar någon annanstans. Därför är det viktigt att läsa det levande gränssnittet, och därför är det globala värdet ensamt inte hela svaret. Läs ett sådant undantag som ett medvetet beslut, och skriv ned varför det gränssnittet är annorlunda. Annars kommer nästa ingenjör att hjälpsamt "laga" det.

Gör inställningen beständig på rätt ställe

En lyckad engångs sysctl -w bevisar att kärnan accepterar värdet. Den överlever inte en omstart, och den överlever inte en nätverkshanterare som vid återanslutning tillämpar sin egen bild av gränssnittskonfigurationen igen. Lägg gatewayrollen i sysctl-konfigurationsfilen eller i nätverkshanteraren som äger värden, och starta sedan om tjänsten som tillämpar den.

Ordningen spelar roll med tunnlar. Om hanteraren skapar gränssnittet vid uppstart och tillämpar vidarebefordran efteråt, kan gränssnittet ärva det gamla standardvärdet. En tjänsteomstart som återskapar tunneln är också en skapelsehändelse, och det är lätt att missa när enheten ser frisk ut. Kontrollera sekvensen, inte bara det slutliga filinnehållet.

Läs samma tre värden igen efter att VPN har återanslutit och ännu en gång efter en omstart. En nyskapad tunnel är ett nytt gränssnitt, och ett nytt gränssnitt tar det standardvärde som gäller vid skapandet. Om siffrorna ändras mellan dessa händelser tillämpas konfigurationen av något du ännu inte har identifierat.

Reparera inte detta med fel verktyg

När vidarebefordran såg trasig ut är frestelsen att tömma brandväggen eller lägga till masquerading. Ingen av dem tar itu med vidarebefordringsbrytaren. Vidarebefordringstillstånd, tillstånd att vidarebefordra, en rutt till målet och en returväg är fyra separata krav, och bara det första är sysctl.

Testa också med rätt flöde. En begäran på gatewayen själv utövar inte vidarebefordran alls; det är lokalt genererad trafik. Frågan är om ett paket som kommer från en VPN-klient eller en LAN-värd accepteras och routas vidare, så testet måste utgå från bakom gatewayen.

Håll IPv6-fallet separat

Här är allt IPv4. IPv6-vidarebefordran, routerannonseringar och accept_ra-beteendet har egna styrningar, och att kopiera en ipv4-väg till en ipv6-inställning ger en fil som ser rimlig ut och inte gör något nyttigt. En dual-stack-gateway behöver båda uppsättningarna medvetet konfigurerade.

En sista kontroll: när värdena stämmer, bekräfta att tunnelns rutt väljs för målet och att returvägen finns. Vidarebefordran påslagen på ett gränssnitt utan rutt är fortfarande ett svart hål, och det felet ser likadant ut från klientsidan.