Zorg dat IPv4-doorsturen een herstart van de VPN-gateway overleeft

Pingen naar de gateway werkt en iets erachter bereiken niet, en dat is de vorm van een doorstuurprobleem en niet van een tunnelprobleem. Lokale aflevering aan de gateway bewijst dat de tunnel omhoogkwam en dat de adrestoewijzing werkte; het zegt niets over de vraag of de kernel een pakket van de ene interface naar de andere doorlaat. Voordat u aan een sysctl zit, bevestig dat de machine bedoeld is om dit verkeer te routeren en lokaliseer de netwerkcontext met de interface richting de client. Lees de waarde daar, niet waar de laatste gids die u las toevallig keek.

De gateway bereiken is niet hetzelfde als doorsturen

Binnen de kernel vallen twee afzonderlijke beslissingen. Aflevering aan een lokaal adres beëindigt de reis van het pakket; doorsturen stuurt het via een andere interface weer naar buiten, en die tweede beslissing wordt per netwerknaamruimte geregeld. Een gateway kan perfect bereikbaar zijn terwijl doorsturen uit staat, en vanaf een ping-prompt zien de twee fouten er identiek uit.

Noteer op welke interface het clientpakket binnenkomt en via welke interface het vervolgpad naar buiten gaat. Beide horen bij één naamruimte, en die naamruimte bevat de instelling die ertoe doet.

Lees de waarde waar de pakketten werkelijk zijn

Op een gateway die in de hostnaamruimte routeert, beantwoordt één commando de vraag: sysctl net.ipv4.ip_forward. Wanneer het inkomende en het vervolgpad in een benoemde naamruimte leven, vraag het die naamruimte: ip netns exec vpn-gw sysctl net.ipv4.ip_forward. De hostwaarde is geen vervanging voor de naamruimtewaarde, en een één op de host is geen bewijs voor iets.

Niet elke routeringscontext heeft een label dat u aan ip netns kunt geven. Container-runtimes en diensten maken naamruimten die nooit onder een vriendelijke naam worden geregistreerd, en daarvoor gebruikt u de inspectiegereedschappen van de runtime. Vervang vpn-gw door de echte naam, of door het runtimemechanisme dat dezelfde context bereikt, en stop met gissen op hostniveau.

Geef de instelling één eigenaar

Op een conventionele systemd-hostgateway is de duurzame vorm een drop-inbestand met een door de beheerder gekozen naam zoals /etc/sysctl.d/60-vpn-forwarding.conf, dat net.ipv4.ip_forward = 1 bevat. Schrijf het bestand en laad daarna precies dat bestand zodat ook de live toestand verandert: sudo sysctl -p /etc/sysctl.d/60-vpn-forwarding.conf, gevolgd door een teruglezing. De bestandsnaam is een voorbeeld en geen gereserveerd VPN-pad, en het voorloopnummer telt omdat later gesorteerde bestanden winnen.

Prioriteit is waar duurzaamheid stil breekt. Controleer zowel de loader van de distributie als uw eigen drop-in, want procps sysctl --system leest aan het eind ook /etc/sysctl.conf, terwijl de sysctl.d-volgorde van systemd een heel andere reeks is. Een latere toewijzing kan dezelfde sleutel meteen terugzetten, waardoor uw bestand correct blijft en de effectieve waarde fout. Overschrijf geen bestaand beheerdersbestand om die discussie te winnen; zoek de eigenaar en wijzig het daar.

Een naamruimte die na het opstarten is gemaakt, wordt helemaal niet door een host-drop-in beheerd. De instelling ervan hoort bij wat hem maakt, of dat nu de container-runtime is of de provisioning-unit voor de naamruimte. Een container brede hostrechten geven om de vraag te omzeilen is een slechtere ruil dan tien minuten besteden aan het vinden van de juiste eigenaar.

Weet wat de schakelaar kost voordat u hem omzet

ip_forward is geen onschuldige boolean. De kerneldocumentatie merkt op dat het wijzigen ervan verschillende andere IPv4-parameters terugzet naar de standaardwaarden van de host of router, dus een diagnostische omzetting kan tuning weggooien die elders is gedaan zonder dat ooit te vermelden. Behandel het als een configuratiewijziging met bijwerkingen en niet als een test die u luchtig kunt uitvoeren.

Dat sluit ook uit dat u hem elke keer uit en aan zet wanneer een client een host niet bereikt. Als de waarde al één is, ligt de fout elders op het pad, en dezelfde sleutel een derde keer herschrijven verplaatst hem niet.

Bewijs de duurzaamheid en test daarna de rest van het pad

Lees de waarde terug op vier momenten: direct na de wijziging, nadat de VPN-interface verschijnt, na een herverbinding en na een geplande herstart. Een waarde die op een van die punten terugspringt heeft een tweede eigenaar, en nog een eenmalige schrijfactie verbergt dat alleen tot de volgende herstart.

Ingeschakeld doorsturen laat nog drie dingen te verifiëren. De client heeft een route naar de bestemming nodig, de gateway heeft een vervolgroute plus toestemming om die te gebruiken nodig, en de bestemming heeft een retourpad naar het tunneladres van de client nodig. Een particulier gerouteerd LAN heeft niet automatisch NAT nodig, dus voeg geen masquerading toe voordat u weet welke van de drie ontbreekt, en test vanaf de bedoelde client in plaats van vanaf de gateway zelf, want een verzoek dat op de gateway is ontstaan raakt nooit het doorstuurpad dat u net hebt ingeschakeld. IPv6 heeft zijn eigen doorstuur- en routeringsbeleid, dus een werkende IPv4-test zegt daar niets over.

Houd het drop-inpad, de eigenaar van de naamruimte en het terugleescommando bij elkaar in de runbook. Wie dit als volgende oppakt, moet de waarde kunnen lezen, zien wie hem bezit en binnen een minuut beslissen of het probleem de duurzaamheid of de rest van het pad is.