Sørg for at IPv4-vidaresending overlever ein omstart av VPN-gatewayen

Ping mot gatewayen verkar, men å nå noko bak han gjer det ikkje, og det er forma til eit vidaresendingsproblem og ikkje eit tunnelproblem. Lokal levering til gatewayen provar at tunnelen kom opp og at adressetildelinga verka; det seier ingenting om korvidt kjernen vil sleppe ein pakke gjennom frå eitt grensesnitt til eit anna. Før du rører nokon sysctl, stadfest at maskinen er meint å rute denne trafikken og finn nettverkskonteksten som held grensesnittet mot klienten. Les deretter verdien der, ikkje der den siste rettleiinga du las tilfeldigvis såg.

Å nå gatewayen er ikkje det same som å vidaresende

To separate avgjerder skjer inne i kjernen. Levering til ei lokal adresse avsluttar reisa til pakken; vidaresending sender han ut igjen gjennom eit anna grensesnitt, og den andre avgjerda blir styrt per nettverksnamnerom. Ein gateway kan vere fullt ut tilgjengeleg medan vidaresending er av, og frå ein ping-leietekst ser dei to feila like ut.

Skriv ned kva grensesnitt klientpakken kjem inn på, og kva grensesnitt vegen vidare går ut gjennom. Begge høyrer til eitt namnerom, og det namnerommet held innstillinga som betyr noko.

Les verdien der pakkane faktisk er

På ein gateway som rutar i vertsnamnerommet, svarar éin kommando på spørsmålet: sysctl net.ipv4.ip_forward. Når inngangsvegen og vegen vidare lever i eit namngjeve namnerom, spør det namnerommet i staden: ip netns exec vpn-gw sysctl net.ipv4.ip_forward. Verdien til verten er ikkje ein erstatning for verdien til namnerommet, og ein einar på verten er ikkje prov for noko.

Ikkje alle rutekontekstar har ei etikett du kan gi til ip netns. Container-runtime og tenester lagar namnerom som aldri blir registrerte under eit venleg namn, og for dei brukar du inspeksjonsverktøya til runtime-en. Bytt ut vpn-gw med det verkelege namnet, eller med runtime-mekanismen som når same kontekst, og slutt å gjette på vertsnivå.

Gi innstillinga éin eigar

På ein konvensjonell systemd-vertsgateway er den varige forma ei drop-in-fil med eit administratørvalt namn som /etc/sysctl.d/60-vpn-forwarding.conf, som inneheld net.ipv4.ip_forward = 1. Skriv fila, og last deretter akkurat den fila slik at den levande tilstanden også blir endra: sudo sysctl -p /etc/sysctl.d/60-vpn-forwarding.conf, etterfølgt av ei tilbakelesing. Filnamnet er eit døme og ikkje ein reservert VPN-sti, og det leidande talet betyr noko fordi filer som blir sorterte seinare vinn.

Prioritet er der vedvarigheita stille blir broten. Sjekk både lastaren til distribusjonen og din eigen drop-in, fordi procps sysctl --system også les /etc/sysctl.conf på slutten, medan sysctl.d-rekkjefølgja til systemd er ein heilt annan sekvens. Ei seinare tildeling kan setje same nøkkel rett tilbake, slik at fila di er riktig og den effektive verdien feil. Ikkje skriv over ei eksisterande administratorfil for å vinne den diskusjonen; finn eigaren og endre han der.

Eit namnerom som blir laga etter oppstart blir ikkje styrt av ein verts-drop-in i det heile. Innstillinga høyrer til det som lagar han, anten det er container-runtime-en eller provisjoneringseininga for namnerommet. Å gi ein container breie vertsprivilegium for å omgå spørsmålet er ein dårlegare handel enn å bruke ti minutt på å identifisere rett eigar.

Vit kva brytaren kostar før du snur han

ip_forward er ikkje ein uskuldig boolean. Kerneldokumentasjonen nemner at endring av han nullstiller fleire andre IPv4-parametrar til standardverdiane til verten eller rutaren, så ei diagnostisk vending kan kaste tuning som er gjort ein annan stad, og aldri nemne det. Handsame det som ei konfigurasjonsendring med biverknader og ikkje som ei sondering du kan køyre lettvint.

Det utelukkar også å slå han av og på kvar gong ein klient ikkje når ein vert. Viss verdien allereie er éin, ligg feilen ein annan stad på vegen, og å skrive same nøkkelen ein tredje gong flyttar han ikkje.

Prov vedvarigheita, og test deretter resten av vegen

Les verdien tilbake på fire tidspunkt: rett etter endringa, etter at VPN-grensesnittet dukkar opp, etter ei attoppkopling og etter ein planlagd omstart. Ein verdi som rullar tilbake på noko av desse punkta har ein annan eigar, og nok ei eingongsskriving gøymer det berre til neste omstart.

Aktivert vidaresending etterlèt framleis tre ting å verifisere. Klienten treng ei rute til destinasjonen, gatewayen treng ei vidare rute pluss løyve til å bruke ho, og destinasjonen treng ein returveg til tunneladressa til klienten. Eit privat ruta LAN treng ikkje automatisk NAT, så ikkje legg til masquerading før du veit kva av dei tre som manglar, og test frå den tiltenkte klienten i staden for frå gatewayen sjølv, fordi ein førespurnad som startar på gatewayen aldri rører vidaresendingsvegen du nettopp aktiverte. IPv6 har sin eigen vidaresendings- og rutingspolitikk, så ein fungerande IPv4-test seier ingenting om han.

Hald drop-in-stien, eigaren av namnerommet og tilbakelesingskommandoen saman i runbooken. Den som tek over neste gong, bør kunne lese verdien, sjå kven som eig han, og avgjere innan eit minutt om problemet er vedvarigheit eller resten av vegen.