Hvorfor net.ipv4.conf.default.forwarding lar tun0 være i fred

Du satte net.ipv4.conf.default.forwarding=1, startet VPN på nytt, og tunnelen slipper fortsatt pakker som gatewayen burde rute. Innstillingen ser riktig ut i filen, og grensesnittet rapporterer fortsatt at videresending er deaktivert. Ingenting er ødelagt: du endret verdien fremtidige grensesnitt arver, ikke den den levende tunnelen bruker.

Gå gjennom dette på verten som eier tunnelen, i nettverks-namespace-et der tunnelen faktisk finnes. En container eller et nettverks-namespace kan holde grensesnittet mens verten viser andre tall.

Les de tre verdiene sammen

Begynn med å sammenligne bryteren for hele gatewayen, malen for nye grensesnitt og grensesnittet du bryr deg om. Erstatt tun0 med det faktiske inngangsgrensesnittet, og les også returgrensesnittet, fordi videresending vurderes på punktet der pakken ankommer.

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

Et vanlig resultat er ip_forward = 0, default.forwarding = 1 og tun0.forwarding = 0. De to første er uenige om vertens rolle, og den tredje viser hva grensesnittet faktisk gjør. Kombinasjonen stemmer med en vert som aldri ble konfigurert som ruter, bare fikk en malverdi. De tre tallene motsier ikke hverandre; de svarer på tre forskjellige spørsmål. Å skrive malverdien avgjør heller ikke vertens rolle.

Hvorfor den globale bryteren er den som flytter seg

net.ipv4.ip_forward er styringen for hele gatewayen. Å endre den oppdaterer videresendingsinnstillingene per grensesnitt som en del av samme operasjon, og derfor kan én skriving få en eksisterende tunnel til å begynne å videresende. default.forwarding sår bare grensesnitt som initialiseres etterpå, så en tunnel som allerede fantes beholder verdien den ble født med.

Kerneldokumentasjonen markerer ip_forward som spesiell av en beslektet grunn: å endre den tilbakestiller en gruppe andre IPv4-parametere til standardverdier for vert eller ruter. Det gjør den til et stump verktøy. Å sette den én gang som del av å etablere gatewayrollen er greit; å veksle den gjentatte ganger som et feilsøkingstriks kan stille skrive over konfigurasjon du brukte tid på å få riktig.

Verdier per grensesnitt finnes også av en grunn. En bevisst styrt gateway kan holde videresending av på et grensesnitt som aldri skal rute, selv mens verten videresender andre steder. Derfor er det viktig å lese det levende grensesnittet, og derfor er den globale verdien alene ikke hele svaret. Les et slikt unntak som en bevisst beslutning, og skriv ned hvorfor det grensesnittet er annerledes. Ellers vil den neste ingeniøren hjelpsomt "fikse" det.

Gjør innstillingen varig på riktig sted

En enkelt vellykket sysctl -w beviser at kjernen godtar verdien. Den overlever ikke en omstart, og den overlever ikke en nettverksbehandler som på nytt bruker sitt eget bilde av grensesnittkonfigurasjonen ved gjenoppkobling. Legg gatewayrollen i sysctl-konfigurasjonsfilen eller i nettverksbehandleren som eier verten, og start deretter tjenesten som bruker den på nytt.

Rekkefølgen betyr noe med tunneler. Hvis behandleren oppretter grensesnittet ved oppstart og bruker videresending etterpå, kan grensesnittet arve den gamle standardverdien. En tjenesteomstart som gjenoppretter tunnelen er også en opprettelseshendelse, og det er lett å overse når enheten ser sunn ut. Sjekk sekvensen, ikke bare det endelige filinnholdet.

Les de samme tre verdiene på nytt etter at VPN har koblet til på nytt, og igjen etter en omstart. En nylig opprettet tunnel er et nytt grensesnitt, og et nytt grensesnitt tar standardverdien som gjelder ved opprettelsen. Hvis tallene endrer seg gjennom disse hendelsene, brukes konfigurasjonen av noe du ennå ikke har identifisert.

Ikke reparer dette med feil verktøy

Da videresending så ødelagt ut, er fristelsen å tømme brannmuren eller legge til masquerading. Ingen av dem tar for seg videresendingsbryteren. Videresendingstilstand, tillatelse til å videresende, en rute til målet og en returvei er fire separate krav, og bare det første er sysctl.

Test også med riktig flyt. En forespørsel på gatewayen selv utøver ikke videresending i det hele tatt; det er lokalt generert trafikk. Spørsmålet er om en pakke som kommer fra en VPN-klient eller en LAN-vert godtas og rutes videre, så testen må oppstå bak gatewayen.

Hold IPv6-tilfellet adskilt

Alt her er IPv4. IPv6-videresending, ruterannonseringer og accept_ra-atferden har sine egne kontroller, og å kopiere en ipv4-sti inn i en ipv6-innstilling gir en fil som ser rimelig ut og ikke gjør noe nyttig. En dual-stack-gateway trenger begge settene bevisst konfigurert.

En siste sjekk: når verdiene stemmer, bekreft at tunnelens rute velges for målet og at returveien finnes. Videresending slått på et grensesnitt uten rute er fortsatt et svart hull, og den feilen ser lik ut fra klientsiden.