Waarom net.ipv4.conf.default.forwarding tun0 met rust laat

U stelt net.ipv4.conf.default.forwarding=1 in, herstart de VPN, en de tunnel laat nog steeds pakketten vallen die de gateway zou moeten routeren. De instelling ziet er in het bestand goed uit, en de interface meldt nog steeds dat doorsturen is uitgeschakeld. Niets is kapot: u hebt de waarde gewijzigd die toekomstige interfaces erven, niet de waarde die de levende tunnel gebruikt.

Loop dit na op de host die de tunnel bezit, in de netwerk-namespace waar de tunnel echt bestaat. Een container of een netwerk-namespace kan de interface houden terwijl de host andere getallen toont.

Lees de drie waarden samen

Begin met het vergelijken van de gatewaybrede schakelaar, de sjabloon voor nieuwe interfaces en de interface die u aangaat. Vervang tun0 door de echte inkomende interface, en lees ook de retourinterface, want doorsturen wordt beoordeeld op het punt waar het pakket aankomt.

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

Een veelvoorkomend resultaat is ip_forward = 0, default.forwarding = 1 en tun0.forwarding = 0. De eerste twee zijn het oneens over de rol van de host, en de derde laat zien wat de interface werkelijk doet. Die combinatie past bij een host die nooit als router is geconfigureerd, maar alleen een sjabloonwaarde kreeg. De drie getallen spreken elkaar niet tegen; ze beantwoorden drie verschillende vragen. Ook het schrijven van de sjabloonwaarde bepaalt de rol van de host niet.

Waarom de globale schakelaar degene is die beweegt

net.ipv4.ip_forward is de gatewaybrede besturing. Als u die wijzigt, worden de doorstuurinstellingen per interface bijgewerkt als onderdeel van dezelfde bewerking, daarom kan één schrijfactie een bestaande tunnel laten beginnen met doorsturen. default.forwarding zaait alleen interfaces die daarna worden geïnitialiseerd, dus een tunnel die al bestond behoudt de waarde waarmee hij geboren is.

De kerneldocumentatie markeert ip_forward als bijzonder om een verwante reden: het wijzigen ervan zet een reeks andere IPv4-parameters terug naar de standaardwaarden voor host of router. Dat maakt het een bot instrument. Het één keer instellen als onderdeel van het vestigen van de gatewayrol is prima; het herhaaldelijk omzetten als debugtruc kan stilzwijgend configuratie herschrijven waar u tijd in hebt gestoken.

Waarden per interface bestaan ook om een reden. Een bewust beheerde gateway kan doorsturen uit laten op een interface die nooit zou moeten routeren, zelfs terwijl de host elders doorstuurt. Daarom is het belangrijk de levende interface te lezen en daarom is de globale waarde alleen niet het hele antwoord. Lees zo'n uitzondering als een bewuste beslissing, en schrijf op waarom die interface anders is. Anders zal de volgende engineer hem behulpzaam "repareren".

Maak de instelling permanent op de juiste plek

Een geslaagde eenmalige sysctl -w bewijst dat de kernel de waarde accepteert. Het overleeft geen herstart, en het overleeft geen netwerkbeheerder die bij het opnieuw verbinden zijn eigen idee van de interfaceconfiguratie opnieuw toepast. Zet de gatewayrol in het sysctl-configuratiebestand of in de netwerkbeheerder die de host bezit, en herstart dan de dienst die hem toepast.

De volgorde is belangrijk bij tunnels. Als de beheerder de interface bij het opstarten aanmaakt en doorsturen daarna toepast, kan de interface de oude standaard erven. Een dienstherstart die de tunnel opnieuw aanmaakt is ook een aanmaakgebeurtenis, en dat is makkelijk te missen wanneer de unit gezond lijkt. Controleer de volgorde, niet alleen de uiteindelijke bestandsinhoud.

Lees dezelfde drie waarden opnieuw nadat de VPN opnieuw verbonden is en nog eens na een herstart. Een nieuw aangemaakte tunnel is een nieuwe interface, en een nieuwe interface neemt de standaard die op het moment van aanmaken geldt. Als de getallen over die gebeurtenissen veranderen, wordt de configuratie toegepast door iets dat u nog niet hebt geïdentificeerd.

Repareer dit niet met het verkeerde gereedschap

Toen doorsturen kapot leek, is de verleiding groot om de firewall te legen of masquerading toe te voegen. Geen van beide pakt de doorstuurschakelaar aan. Doorstuurstaat, toestemming om door te sturen, een route naar de bestemming en een retourpad zijn vier afzonderlijke vereisten, en alleen de eerste is de sysctl.

Test ook met de juiste stroom. Een verzoek op de gateway zelf oefent doorsturen helemaal niet, want dat is lokaal gegenereerd verkeer. De vraag is of een pakket dat van een VPN-client of een LAN-host komt, wordt geaccepteerd en verder gerouteerd, dus de test moet achter de gateway beginnen.

Houd het IPv6-geval apart

Alles hier is IPv4. IPv6-doorsturen, routeraankondigingen en het accept_ra-gedrag hebben hun eigen besturing, en een ipv4-pad in een ipv6-instelling kopiëren levert een bestand op dat aannemelijk lijkt en niets nuttigs doet. Een dual-stack-gateway heeft beide sets bewust geconfigureerd nodig.

Een laatste controle: als de waarden overeenkomen, bevestig dan dat de route van de tunnel voor de bestemming wordt gekozen en dat het retourpad bestaat. Doorsturen aan op een interface zonder route is nog steeds een zwart gat, en die storing ziet er vanaf de clientkant hetzelfde uit.