Sørg for at IPv4-videresending overlever en omstart av VPN-gatewayen

Ping mot gatewayen virker, men å nå noe bak den gjør det ikke, og det er formen til et videresendingsproblem og ikke et tunnelproblem. Lokal levering til gatewayen beviser at tunnelen kom opp og at adressetildelingen virket; det sier ingenting om hvorvidt kjernen vil slippe en pakke gjennom fra ett grensesnitt til et annet. Før du rører noen sysctl, bekreft at maskinen er ment å rute denne trafikken og finn nettverkskonteksten som holder grensesnittet mot klienten. Les deretter verdien der, ikke der den siste veiledningen du leste tilfeldigvis så.

Å nå gatewayen er ikke det samme som å videresende

To separate beslutninger skjer inne i kjernen. Levering til en lokal adresse avslutter pakkens reise; videresending sender den ut igjen gjennom et annet grensesnitt, og den andre beslutningen styres per nettverksnavnerom. En gateway kan være fullt ut tilgjengelig mens videresending er av, og fra en ping-ledetekst ser de to feilene like ut.

Skriv ned hvilket grensesnitt klientpakken kommer inn på, og hvilket grensesnitt veien videre går ut gjennom. Begge hører til ett navnerom, og det navnerommet holder innstillingen som betyr noe.

Les verdien der pakkene faktisk er

På en gateway som ruter i vertsnavnerommet, svarer én kommando på spørsmålet: sysctl net.ipv4.ip_forward. Når inngangsveien og veien videre lever i et navngitt navnerom, spør det navnerommet i stedet: ip netns exec vpn-gw sysctl net.ipv4.ip_forward. Vertens verdi er ikke en erstatning for navnerommets verdi, og en ener på verten er ikke bevis for noe.

Ikke alle rutekontekster har en etikett du kan gi til ip netns. Container-runtime og tjenester lager navnerom som aldri registreres under et vennlig navn, og for dem bruker du runtime-ens inspeksjonsverktøy. Bytt ut vpn-gw med det virkelige navnet, eller med runtime-mekanismen som når samme kontekst, og slutt å gjette på vertsnivå.

Gi innstillingen én eier

På en konvensjonell systemd-vertsgateway er den varige formen en drop-in-fil med et administratørvalgt navn som /etc/sysctl.d/60-vpn-forwarding.conf, som inneholder net.ipv4.ip_forward = 1. Skriv filen, og last deretter akkurat den filen slik at den levende tilstanden også endres: sudo sysctl -p /etc/sysctl.d/60-vpn-forwarding.conf, etterfulgt av en tilbakelesing. Filnavnet er et eksempel og ikke en reservert VPN-sti, og det ledende tallet betyr noe fordi filer som sorteres senere vinner.

Prioritet er der vedholdenheten stille brytes. Sjekk både distribusjonens laster og din egen drop-in, fordi procps sysctl --system også leser /etc/sysctl.conf på slutten, mens systemds sysctl.d-rekkefølge er en helt annen sekvens. En senere tildeling kan sette samme nøkkel rett tilbake, slik at filen din er riktig og den effektive verdien feil. Ikke overskriv en eksisterende administratorfil for å vinne den diskusjonen; finn eieren og endre den der.

Et navnerom som lages etter oppstart styres ikke i det hele tatt av en verts-drop-in. Innstillingen tilhører det som lager det, enten det er container-runtime-en eller provisjoneringsenheten for navnerommet. Å gi en container brede vertsprivilegier for å omgå spørsmålet er en dårligere handel enn å bruke ti minutter på å identifisere riktig eier.

Vit hva bryteren koster før du vender den

ip_forward er ikke en uskyldig boolean. Kerneldokumentasjonen bemerker at endring av den nullstiller flere andre IPv4-parametere til vertens eller ruterenes standardverdier, så en diagnostisk vending kan kaste tuning som er gjort et annet sted, og aldri nevne det. Behandle det som en konfigurasjonsendring med bivirkninger og ikke som en sondering du kan kjøre lettvint.

Det utelukker også å slå den av og på hver gang en klient ikke når en vert. Hvis verdien allerede er en, ligger feilen et annet sted på veien, og å skrive den samme nøkkelen en tredje gang flytter den ikke.

Bevis vedholdenheten, og test deretter resten av veien

Les verdien tilbake på fire tidspunkter: rett etter endringen, etter at VPN-grensesnittet dukker opp, etter en gjenoppkobling og etter en planlagt omstart. En verdi som ruller tilbake på noen av disse punktene har en annen eier, og nok en engangsskriving skjuler det bare til neste omstart.

Aktivert videresending etterlater fortsatt tre ting å verifisere. Klienten trenger en rute til destinasjonen, gatewayen trenger en videre rute pluss tillatelse til å bruke den, og destinasjonen trenger en returvei til klientens tunneladresse. Et privat rutet LAN trenger ikke automatisk NAT, så ikke legg til masquerading før du vet hvilken av de tre som mangler, og test fra den tiltenkte klienten i stedet for fra gatewayen selv, fordi en forespørsel som starter på gatewayen aldri berører videresendingsveien du nettopp aktiverte. IPv6 har sin egen videresendings- og rutingspolitikk, så en fungerende IPv4-test sier ingenting om den.

Hold drop-in-stien, navnerommets eier og tilbakelesingskommandoen sammen i runbooken. Den som tar over neste gang, bør kunne lese verdien, se hvem som eier den, og avgjøre innen et minutt om problemet er vedholdenhet eller resten av veien.