De ce net.ipv4.conf.default.forwarding lasă tun0 în pace

Ați setat net.ipv4.conf.default.forwarding=1, ați repornit VPN-ul, iar tunelul încă aruncă pachetele pe care gateway-ul ar trebui să le ruteze. Setarea arată corect în fișier, iar interfața raportează în continuare că redirecționarea este dezactivată. Nimic nu este stricat: ați schimbat valoarea pe care o moștenesc interfețele viitoare, nu pe cea pe care o folosește tunelul activ.

Parcurgeți acest lucru pe gazda care deține tunelul, în namespace-ul de rețea în care tunelul există cu adevărat. Un container sau un namespace de rețea poate ține interfața în timp ce gazda afișează alte numere.

Citiți cele trei valori împreună

Începeți prin a compara comutatorul la nivel de gateway, șablonul pentru interfețele noi și interfața care vă interesează. Înlocuiți tun0 cu interfața de intrare reală și citiți și interfața de retur, deoarece redirecționarea este evaluată în punctul în care sosește pachetul.

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

Un rezultat obișnuit este ip_forward = 0, default.forwarding = 1 și tun0.forwarding = 0. Primele două nu sunt de acord cu privire la rolul gazdei, iar a treia arată ce face de fapt interfața. Această combinație este compatibilă cu o gazdă care nu a fost niciodată configurată ca router, ci a primit doar o valoare de șablon. Cele trei numere nu se contrazic; ele răspund la trei întrebări diferite. Nici scrierea valorii șablonului nu decide rolul gazdei.

De ce comutatorul global este cel care se mișcă

net.ipv4.ip_forward este controlul la nivel de gateway. Modificarea lui actualizează setările de redirecționare pe interfață ca parte a aceleiași operațiuni, de aceea o singură scriere poate face un tunel existent să înceapă să redirecționeze. default.forwarding seamănă doar interfețele inițializate ulterior, așa că un tunel care exista deja păstrează valoarea cu care s-a născut.

Documentația nucleului marchează ip_forward ca special dintr-un motiv înrudit: modificarea lui resetează un set de alți parametri IPv4 la valorile implicite pentru gazdă sau router. Asta îl face un instrument grosolan. Să îl setați o dată ca parte a stabilirii rolului de gateway este în regulă; să îl comutați în mod repetat ca truc de depanare poate rescrie în tăcere o configurație pentru care ați investit timp.

Valorile pe interfață există și ele dintr-un motiv. Un gateway administrat intenționat poate ține redirecționarea oprită pe o interfață care nu ar trebui niciodată să ruteze, chiar și în timp ce gazda redirecționează în altă parte. De aceea contează citirea interfeței active și de aceea valoarea globală singură nu este tot răspunsul. Citiți o astfel de excepție ca pe o decizie deliberată și notați de ce acea interfață este diferită. Altfel următorul inginer o va "repara" cu multă bunăvoință.

Faceți setarea permanentă în locul potrivit

Un sysctl -w punctual reușit dovedește că nucleul acceptă valoarea. Nu supraviețuiește unei reporniri și nu supraviețuiește unui manager de rețea care reaplică propria idee despre configurația interfeței la reconectare. Puneți rolul de gateway în fișierul de configurare sysctl sau în managerul de rețea care deține gazda, apoi reporniți serviciul care îl aplică.

Ordinea contează la tuneluri. Dacă managerul creează interfața la pornire și aplică redirecționarea după aceea, interfața poate moșteni vechea valoare implicită. Repornirea unui serviciu care recreează tunelul este și ea un eveniment de creare și este ușor de ratat când unitatea pare sănătoasă. Verificați secvența, nu doar conținutul final al fișierului.

Recitiți aceleași trei valori după ce VPN-ul se reconectează și încă o dată după o repornire. Un tunel nou creat este o interfață nouă, iar o interfață nouă ia valoarea implicită în vigoare în momentul creării. Dacă numerele se schimbă între aceste evenimente, configurația este aplicată de ceva ce încă nu ați identificat.

Nu reparați asta cu instrumentul greșit

Când redirecționarea părea stricată, tentația este să goliți firewall-ul sau să adăugați masquerading. Niciuna nu se ocupă de comutatorul de redirecționare. Starea redirecționării, permisiunea de a redirecționa, o rută către destinație și o cale de retur sunt patru cerințe separate, iar doar prima este sysctl.

Testați și cu fluxul corect. O cerere făcută pe gateway-ul însuși nu exersează deloc redirecționarea; este trafic generat local. Întrebarea este dacă un pachet care sosește de la un client VPN sau de la o gazdă LAN este acceptat și rutat mai departe, așa că testul trebuie să pornească din spatele gateway-ului.

Țineți cazul IPv6 separat

Aici totul este IPv4. Redirecționarea IPv6, anunțurile de router și comportamentul accept_ra au propriile controale, iar copierea unei căi ipv4 într-o setare ipv6 produce un fișier care pare plauzibil și nu face nimic util. Un gateway cu două stive are nevoie de ambele seturi configurate intenționat.

O ultimă verificare: după ce valorile coincid, confirmați că ruta tunelului este selectată pentru destinație și că calea de răspuns există. Redirecționarea activată pe o interfață fără rută rămâne o gaură neagră, iar acea defecțiune arată la fel din partea clientului.