Kvifor net.ipv4.conf.default.forwarding lèt tun0 vera i fred

Du sette net.ipv4.conf.default.forwarding=1, starta VPN på nytt, og tunnelen slepp framleis pakkar som gatewayen burde rute. Innstillinga ser rett ut i fila, og grensesnittet rapporterer framleis at videresending er slått av. Ingenting er øydelagt: du endra verdien framtidige grensesnitt arvar, ikkje den den levande tunnelen brukar.

Gå gjennom dette på verten som eig tunnelen, i nettverks-namespace-et der tunnelen faktisk finst. Ein container eller eit nettverks-namespace kan halde grensesnittet medan verten viser andre tal.

Les dei tre verdiane saman

Byrja med å samanlikne brytaren for heile gatewayen, malen for nye grensesnitt og grensesnittet du bryr deg om. Byt ut tun0 med det faktiske inngangsgrensesnittet, og les også returgrensesnittet, fordi videresending blir vurdert på punktet der pakken kjem inn.

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

Eit vanleg resultat er ip_forward = 0, default.forwarding = 1 og tun0.forwarding = 0. Dei to første er usamde om rolla til verten, og den tredje viser kva grensesnittet faktisk gjer. Kombinasjonen stemmer med ein vert som aldri vart konfigurert som ruter, berre fekk ein malverdi. Dei tre tala motseier ikkje kvarandre; dei svarar på tre ulike spørsmål. Å skrive malverdien avgjer heller ikkje rolla til verten.

Kvifor den globale brytaren er den som flyttar seg

net.ipv4.ip_forward er styringa for heile gatewayen. Å endre han oppdaterer videresendingsinnstillingane per grensesnitt som ein del av same operasjon, og difor kan éin skriving få ein eksisterande tunnel til å byrje å videresende. default.forwarding sår berre grensesnitt som blir initialiserte etterpå, så ein tunnel som allereie fanst held på verdien han vart fødd med.

Kerneldokumentasjonen merkjer ip_forward som spesiell av ein skyldig grunn: å endre han nullstiller ei gruppe andre IPv4-parametrar til standardverdiar for vert eller ruter. Det gjer han til eit stump reiskap. Å setje han éin gong som del av å etablere gatewayrolla er greitt; å veksle han gong på gong som eit feilsøkingstriks kan stille skrive over konfigurasjon du brukte tid på å få rett.

Verdiar per grensesnitt finst også av ein grunn. Ein medvite styrt gateway kan halde videresending av på eit grensesnitt som aldri skal rute, sjølv medan verten videresender andre stader. Difor er det viktig å lese det levande grensesnittet, og difor er den globale verdien åleine ikkje heile svaret. Les eit slikt unntak som ei medvite avgjerd, og skriv ned kvifor det grensesnittet er annleis. Elles vil den neste ingeniøren hjelpsamt "fikse" det.

Gjer innstillinga varig på rett stad

Ein einskild vellukka sysctl -w beviser at kjernen godtek verdien. Han overlever ikkje ein omstart, og han overlever ikkje ein nettverkshandsamar som på nytt brukar sitt eige bilete av grensesnittkonfigurasjonen ved gjenoppkopling. Legg gatewayrolla i sysctl-konfigurasjonsfila eller i nettverkshandsamaren som eig verten, og start så tenesta som brukar ho på nytt.

Rekkjefylgja har mykje å seie med tunnelar. Viss handsamaren lagar grensesnittet ved oppstart og brukar videresending etterpå, kan grensesnittet arve den gamle standardverdien. Ein tenestestart som gjenopprettar tunnelen er også ei opprettingshending, og det er lett å oversjå når eininga ser sunn ut. Sjekk sekvensen, ikkje berre det endelege filinnhaldet.

Les dei same tre verdiane på nytt etter at VPN har kopla til på nytt, og igjen etter ein omstart. Ein nyleg oppretta tunnel er eit nytt grensesnitt, og eit nytt grensesnitt tek standardverdien som gjeld ved opprettinga. Viss tala endrar seg gjennom desse hendingane, blir konfigurasjonen brukt av noko du enno ikkje har identifisert.

Ikkje reparer dette med feil reiskap

Då videresending såg øydelagd ut, er freistinga å tømme brannmuren eller leggje til masquerading. Ingen av dei tek føre seg videresendingsbrytaren. Videresendingstilstand, løyve til å videresende, ei rute til målet og ein returveg er fire skilde krav, og berre det første er sysctl.

Test også med rett flyt. Ein førespurnad på gatewayen sjølv utøver ikkje videresending i det heile; det er lokalt generert trafikk. Spørsmålet er om ein pakke som kjem frå ein VPN-klient eller ein LAN-vert blir godteken og ruta vidare, så testen må oppstå bak gatewayen.

Hald IPv6-tilfellet skilt

Alt her er IPv4. IPv6-videresending, ruterannonseringar og accept_ra-åtferda har sine eigne kontrollar, og å kopiere ein ipv4-sti inn i ei ipv6-innstilling gjev ei fil som ser rimeleg ut og ikkje gjer noko nyttig. Ein dual-stack-gateway treng begge setta medvite konfigurerte.

Ein siste sjekk: når verdiane stemmer, stadfest at ruta til tunnelen blir vald for målet og at returvegen finst. Videresending slått på eit grensesnitt utan rute er framleis eit svart hol, og den feilen ser lik ut frå klientsida.