Hvorfor net.ipv4.conf.default.forwarding lader tun0 være

Du sætter net.ipv4.conf.default.forwarding=1, genstarter VPN, og tunnelen dropper stadig pakker, som gatewayen burde rute. Indstillingen ser rigtig ud i filen, og grænsefladen rapporterer stadig, at videresendelse er deaktiveret. Intet er i stykker: du ændrede den værdi, som fremtidige grænseflader arver, ikke den den levende tunnel bruger.

Gå det igennem på den vært, der ejer tunnelen, i det netværks-namespace hvor tunnelen faktisk findes. En container eller et netværks-namespace kan holde grænsefladen, mens værten viser andre tal.

Læs de tre værdier sammen

Begynd med at sammenligne kontakten for hele gatewayen, skabelonen for nye grænseflader og den grænseflade, du bekymrer dig om. Erstat tun0 med den rigtige indgående grænseflade, og læs også returgrænsefladen, fordi videresendelse vurderes på det punkt, hvor pakken ankommer.

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

Et almindeligt resultat er ip_forward = 0, default.forwarding = 1 og tun0.forwarding = 0. De to første er uenige om værtens rolle, og den tredje viser, hvad grænsefladen faktisk gør. Kombinationen stemmer med en vært, der aldrig blev konfigureret som router, men kun fik en skabelonværdi. De tre tal modsiger ikke hinanden; de besvarer tre forskellige spørgsmål. At skrive skabelonværdien afgør heller ikke værtens rolle.

Hvorfor det er den globale kontakt, der flytter sig

net.ipv4.ip_forward er styringen for hele gatewayen. Ændres den, opdateres videresendelsesindstillingerne pr. grænseflade som en del af samme handling, og derfor kan én skrivning få en eksisterende tunnel til at begynde at videresende. default.forwarding sår kun grænseflader, der initialiseres bagefter, så en tunnel, der allerede fandtes, beholder den værdi, den blev født med.

Kernedokumentationen markerer ip_forward som speciel af en beslægtet grund: ændres den, nulstilles en række andre IPv4-parametre til standardværdier for vært eller router. Det gør den til et stump redskab. At sætte den én gang som led i at etablere gatewayrollen er fint; at skifte den gentagne gange som et fejlsøgningstrick kan lydløst overskrive konfiguration, du brugte tid på at få rigtig.

Værdier pr. grænseflade findes også af en grund. En bevidst styret gateway kan holde videresendelse slået fra på en grænseflade, der aldrig bør rute, selv mens værten videresender andre steder. Derfor er det vigtigt at læse den levende grænseflade, og derfor er den globale værdi alene ikke hele svaret. Læs en sådan undtagelse som en bevidst beslutning, og skriv ned, hvorfor den grænseflade er anderledes. Ellers vil den næste ingeniør hjælpsomt "rette" den.

Gør indstillingen permanent det rigtige sted

Et enkelt vellykket sysctl -w beviser, at kernen accepterer værdien. Det overlever ikke en genstart og overlever heller ikke en netværksmanager, der ved genopkobling anvender sin egen opfattelse af grænsefladens konfiguration igen. Læg gatewayrollen i sysctl-konfigurationsfilen eller i den netværksmanager, der ejer værten, og genstart derefter den tjeneste, der anvender den.

Rækkefølgen betyder noget med tunneler. Hvis manageren opretter grænsefladen ved opstart og anvender videresendelse bagefter, kan grænsefladen arve den gamle standard. En tjenestegenstart, der genskaber tunnelen, er også en oprettelseshændelse, og det er let at overse, når unit'en ser sund ud. Kontrollér sekvensen, ikke kun filens endelige indhold.

Læs de samme tre værdier igen, efter VPN'en har genopkoblet, og igen efter en genstart. En nyligt oprettet tunnel er en ny grænseflade, og en ny grænseflade tager den standard, der gælder ved oprettelsen. Hvis tallene ændrer sig hen over de hændelser, anvendes konfigurationen af noget, du endnu ikke har identificeret.

Reparer det ikke med det forkerte værktøj

Da videresendelse så brudt ud, frister det at skylle firewallen eller tilføje masquerading. Ingen af delene løser kontakten for videresendelse. Videresendelsestilstand, tilladelse til at videresende, en rute til destinationen og en returvej er fire særskilte krav, og kun det første er sysctl.

Test også med den rigtige strøm. En anmodning på gatewayen selv udøver slet ikke videresendelse; det er lokalt genereret trafik. Spørgsmålet er, om en pakke, der ankommer fra en VPN-klient eller en LAN-vært, accepteres og routes videre, så testen skal udgå fra bagsiden af gatewayen.

Hold IPv6-sagen adskilt

Alt her er IPv4. IPv6-videresendelse, routerannonceringer og accept_ra-adfærden har deres egne kontroller, og at kopiere en ipv4-sti ind i en ipv6-indstilling giver en fil, der ser rimelig ud og ikke gør noget nyttigt. En dual-stack-gateway har brug for, at begge sæt konfigureres bevidst.

En sidste kontrol: når værdierne stemmer, skal du bekræfte, at tunnelens rute vælges til destinationen, og at returvejen findes. Videresendelse slået til på en grænseflade uden rute er stadig et sort hul, og den fejl ser ens ud fra klientsiden.