Få IPv4-videresendelse til at holde efter en genstart af VPN-gatewayen

At pinge gatewayen virker, og at nå noget bag den gør ikke, og det er formen af et videresendelsesproblem snarere end et tunnelproblem. Lokal levering til gatewayen beviser, at tunnelen kom op, og at tildelingen af adresse virkede; det siger intet om, hvorvidt kernen vil sende en pakke fra et interface til et andet. Før du rører ved en sysctl, skal du bekræfte, at maskinen er beregnet til at route denne trafik og finde den netværkskontekst, der holder det klientvendte interface. Læs derefter værdien dér i stedet for der, hvor den sidste guide, du læste, tilfældigvis kiggede.

At nå gatewayen er ikke det samme som at videresende

Der sker to separate beslutninger inde i kernen. Levering til en lokal adresse afslutter pakkens rejse; videresendelse sender den ud igen gennem et andet interface, og den anden beslutning styres pr. netværksnamespace. En gateway kan være fuldt ud tilgængelig, mens videresendelse er slået fra, og fra en ping-prompt ser de to fejl ens ud.

Skriv ned, hvilket interface klientpakken ankommer på, og hvilket interface den videre vej forlader gennem. Begge hører til ét namespace, og det namespace rummer den indstilling, der betyder noget.

Læs værdien, hvor pakkerne faktisk er

På en gateway, der router i host-namespacet, svarer én kommando på spørgsmålet: sysctl net.ipv4.ip_forward. Når indgangsvejen og den videre vej lever i et navngivet namespace, så spørg det namespace i stedet: ip netns exec vpn-gw sysctl net.ipv4.ip_forward. Hostværdien er ikke en erstatning for namespaceværdien, og et ettal på hosten er ikke bevis på noget.

Ikke alle routingkontekster har et mærke, du kan give til ip netns. Container-runtimes og tjenester opretter namespaces, der aldrig registreres under et venligt navn, og til dem bruger du runtimets inspektionsværktøjer. Erstat vpn-gw med det rigtige navn eller den runtimemekanisme, der når samme kontekst, og hold op med at gætte på hostniveau.

Giv indstillingen én ejer

På en konventionel systemd-hostgateway er den varige form en drop-in-fil med et administratorkåret navn som /etc/sysctl.d/60-vpn-forwarding.conf, der indeholder net.ipv4.ip_forward = 1. Skriv filen, og indlæs derefter netop den fil, så den levende tilstand også ændres: sudo sysctl -p /etc/sysctl.d/60-vpn-forwarding.conf, efterfulgt af en tilbagelæsning. Filnavnet er et eksempel og ikke en reserveret VPN-sti, og det førende tal betyder noget, fordi filer, der sorteres senere, vinder.

Forrang er dér, hvor vedholdenhed stille går i stykker. Kontrollér både distributionens loader og din egen drop-in, fordi procps sysctl --system også læser /etc/sysctl.conf til sidst, mens systemds sysctl.d-rækkefølge er en helt anden sekvens. En senere tildeling kan sætte den samme nøgle direkte tilbage, så din fil er korrekt og den effektive værdi forkert. Overskriv ikke en eksisterende administratorfil for at vinde den diskussion; find ejeren, og skift den dér.

Et namespace, der oprettes efter opstart, styres slet ikke af en host-drop-in. Dets indstilling tilhører det, der opretter det, uanset om det er container-runtimen eller provisioning-enheden for namespacet. At give en container brede hostprivilegier for at omgå spørgsmålet er en dårligere handel end at bruge ti minutter på at finde den rigtige ejer.

Vid, hvad kontakten koster, før du vender den

ip_forward er ikke en uskyldig boolean. Kernedokumentationen bemærker, at ændring af den nulstiller flere andre IPv4-parametre til deres host- eller routerstandarder, så en diagnostisk vending kan kaste finjustering væk, der er lavet et andet sted, uden nogensinde at nævne det. Behandl det som en konfigurationsændring med bivirkninger snarere end en sondering, du kan køre let hen.

Det udelukker også at slå den fra og til, hver gang en klient ikke kan nå en host. Hvis værdien allerede er et ettal, er fejlen et andet sted på vejen, og at genskrive den samme nøgle en tredje gang flytter den ikke.

Bevis vedholdenhed, og test derefter resten af vejen

Læs værdien tilbage på fire tidspunkter: lige efter ændringen, efter VPN-interfacet dukker op, efter en genopkobling og efter en planlagt genstart. En værdi, der ruller tilbage på et af disse punkter, har en anden ejer, og endnu en enkeltstående skrivning skjuler det kun indtil næste genstart.

Aktiveret videresendelse efterlader stadig tre ting at kontrollere. Klienten har brug for en rute til destinationen, gatewayen har brug for en videre rute plus tilladelse til at bruge den, og destinationen har brug for en returvej til klientens tunneladresse. Et privat routet LAN har ikke automatisk brug for NAT, så tilføj ikke masquerading, før du ved, hvilken af de tre der mangler, og test fra den tilsigtede klient i stedet for fra gatewayen selv, fordi en anmodning, der starter på gatewayen, aldrig rører den videresendelsesvej, du netop har aktiveret. IPv6 har sin egen videresendelses- og routingpolitik, så en fungerende IPv4-test siger intet om den.

Hold drop-in-stien, namespaceejeren og tilbagelæsningskommandoen sammen i runbooken. Den næste, der tager over, bør kunne læse værdien, se hvem der ejer den, og inden for et minut afgøre, om problemet er vedholdenhed eller resten af vejen.