Se till att IPv4-vidarebefordran överlever en omstart av VPN-gatewayen

Ping mot gatewayen fungerar men att nå något bakom den gör det inte, och det är formen av ett vidarebefordringsproblem och inte ett tunnelproblem. Lokal leverans till gatewayen bevisar att tunneln kom upp och att adresstilldelningen fungerade; det säger ingenting om huruvida kärnan släpper igenom ett paket från ett gränssnitt till ett annat. Innan du rör någon sysctl, bekräfta att maskinen är avsedd att routa denna trafik och hitta nätverkskontexten som håller gränssnittet mot klienten. Läs sedan värdet där, inte där den senaste guiden du läste råkade titta.

Att nå gatewayen är inte samma sak som att vidarebefordra

Inne i kärnan fattas två separata beslut. Leverans till en lokal adress avslutar paketets resa; vidarebefordran skickar ut det igen genom ett annat gränssnitt, och det andra beslutet styrs per nätverksnamnutrymme. En gateway kan vara helt nåbar medan vidarebefordran är avstängd, och från en ping-prompt ser de två felen identiska ut.

Skriv ned vilket gränssnitt klientpaketet kommer in på och vilket gränssnitt vägen vidare går ut genom. Båda hör till ett namnutrymme, och det namnutrymmet håller inställningen som spelar roll.

Läs värdet där paketen faktiskt finns

På en gateway som routar i värdens namnutrymme svarar ett enda kommando på frågan: sysctl net.ipv4.ip_forward. När ingångsvägen och vägen vidare lever i ett namngivet namnutrymme, fråga det namnutrymmet i stället: ip netns exec vpn-gw sysctl net.ipv4.ip_forward. Värdets värde är inte en ersättning för namnutrymmets värde, och en etta på värden är inte bevis för något.

Inte varje routingkontext har en etikett som du kan ge till ip netns. Container-runtimes och tjänster skapar namnutrymmen som aldrig registreras under ett vänligt namn, och för dem använder du runtimets inspektionsverktyg. Byt ut vpn-gw mot det riktiga namnet, eller mot runtime-mekanismen som når samma kontext, och sluta gissa på värdnivå.

Ge inställningen en enda ägare

På en konventionell systemd-värdgateway är den varaktiga formen en drop-in-fil med ett administratörsvalt namn som /etc/sysctl.d/60-vpn-forwarding.conf, som innehåller net.ipv4.ip_forward = 1. Skriv filen och ladda sedan just den filen så att det levande tillståndet också ändras: sudo sysctl -p /etc/sysctl.d/60-vpn-forwarding.conf, följt av en återläsning. Filnamnet är ett exempel och inte en reserverad VPN-sökväg, och den inledande siffran spelar roll eftersom filer som sorteras senare vinner.

Prioritet är där varaktigheten tyst bryts. Kontrollera både distributionens laddare och din egen drop-in, eftersom procps sysctl --system också läser /etc/sysctl.conf i slutet, medan systemds sysctl.d-ordning är en helt annan sekvens. En senare tilldelning kan sätta tillbaka samma nyckel direkt, så att din fil är korrekt och det effektiva värdet fel. Skriv inte över en befintlig administratörsfil för att vinna den diskussionen; hitta ägaren och ändra där.

Ett namnutrymme som skapas efter start styrs inte alls av en värd-drop-in. Dess inställning tillhör det som skapar det, vare sig det är container-runtimen eller provisioneringsenheten för namnutrymmet. Att ge en container breda värdprivilegier för att kringgå frågan är en sämre affär än att lägga tio minuter på att identifiera rätt ägare.

Vet vad strömbrytaren kostar innan du vänder den

ip_forward är inte en oskyldig boolean. Kärndokumentationen noterar att en ändring av den återställer flera andra IPv4-parametrar till värdenas eller routrarnas standardvärden, så en diagnostisk vändning kan kasta bort trimning som gjorts någon annanstans och aldrig nämna det. Behandla det som en konfigurationsändring med bieffekter och inte som en sondering du kan köra lättvindigt.

Det utesluter också att slå av och på den varje gång en klient inte når en värd. Om värdet redan är ett ligger felet någon annanstans på vägen, och att skriva samma nyckel en tredje gång flyttar det inte.

Bevisa varaktigheten och testa sedan resten av vägen

Läs tillbaka värdet vid fyra tillfällen: direkt efter ändringen, efter att VPN-gränssnittet dyker upp, efter en återanslutning och efter en planerad omstart. Ett värde som rullar tillbaka vid någon av dessa punkter har en andra ägare, och ännu en engångsskrivning döljer det bara till nästa omstart.

Aktiverad vidarebefordran lämnar fortfarande tre saker att verifiera. Klienten behöver en rutt till destinationen, gatewayen behöver en vidare rutt plus tillstånd att använda den, och destinationen behöver en returväg till klientens tunneladress. Ett privat routat LAN behöver inte automatiskt NAT, så lägg inte till masquerading innan du vet vilken av de tre som saknas, och testa från den avsedda klienten i stället för från gatewayen själv, eftersom en förfrågan som startar på gatewayen aldrig rör vidarebefordringsvägen du just aktiverade. IPv6 har sin egen vidarebefordrings- och routingpolicy, så ett fungerande IPv4-test säger ingenting om den.

Håll drop-in-vägen, namnutrymmets ägare och återläsningskommandot tillsammans i runbooken. Den som tar över nästa gång bör kunna läsa värdet, se vem som äger det och inom en minut avgöra om problemet är varaktigheten eller resten av vägen.