Faceți ca redirecționarea IPv4 să persiste după o repornire a gateway-ului VPN

Pingul către gateway funcționează, iar accesul la orice din spatele lui nu, și aceasta este forma unei probleme de redirecționare, nu a unei probleme de tunel. Livrarea locală către gateway dovedește că tunelul a pornit și că alocarea adresei a funcționat; nu spune nimic despre dacă nucleul va trece un pachet de la o interfață la alta. Înainte de a atinge vreun sysctl, confirmați că mașina este destinată să ruteze acest trafic și localizați contextul de rețea care ține interfața orientată spre client. Apoi citiți valoarea acolo, nu acolo unde ultimul ghid citit s-a uitat din întâmplare.

A ajunge la gateway nu este același lucru cu a redirecționa

În interiorul nucleului au loc două decizii separate. Livrarea către o adresă locală încheie călătoria pachetului; redirecționarea îl trimite din nou afară prin altă interfață, iar acea a doua decizie este guvernată pe spațiu de nume de rețea. Un gateway poate fi perfect accesibil în timp ce redirecționarea este oprită, iar dintr-un prompt ping cele două defecțiuni arată identic.

Notați pe ce interfață sosește pachetul clientului și prin ce interfață iese calea următoare. Ambele aparțin unui singur spațiu de nume, iar acel spațiu de nume ține setarea care contează.

Citiți valoarea acolo unde pachetele se află cu adevărat

Pe un gateway care rutează în spațiul de nume al gazdei, o singură comandă răspunde la întrebare: sysctl net.ipv4.ip_forward. Când calea de intrare și cea următoare trăiesc într-un spațiu de nume numit, întrebați acel spațiu de nume: ip netns exec vpn-gw sysctl net.ipv4.ip_forward. Valoarea gazdei nu înlocuiește valoarea spațiului de nume, iar un unu pe gazdă nu este dovada nimic.

Nu fiecare context de rutare are o etichetă pe care să o puteți da comenzii ip netns. Mediile de execuție ale containerelor și serviciile creează spații de nume care nu sunt niciodată înregistrate sub un nume prietenos, iar pentru acelea folosiți instrumentele de inspecție ale mediului. Înlocuiți vpn-gw cu numele real, sau cu mecanismul mediului care ajunge la același context, și opriți presupunerile la nivel de gazdă.

Dați setării un singur proprietar

Pe un gateway-gazdă systemd convențional, forma durabilă este un fișier drop-in cu un nume ales de administrator, cum ar fi /etc/sysctl.d/60-vpn-forwarding.conf, care conține net.ipv4.ip_forward = 1. Scrieți fișierul, apoi încărcați exact acel fișier pentru ca și starea live să se schimbe: sudo sysctl -p /etc/sysctl.d/60-vpn-forwarding.conf, urmat de o recitire. Numele fișierului este un exemplu și nu o cale VPN rezervată, iar numărul de la început contează pentru că fișierele sortate mai târziu câștigă.

Prioritatea este locul unde durabilitatea se rupe în liniște. Verificați atât încărcătorul distribuției, cât și propriul drop-in, pentru că procps sysctl --system citește la final și /etc/sysctl.conf, în timp ce ordinea sysctl.d a systemd este o secvență complet diferită. O atribuire ulterioară poate pune aceeași cheie înapoi imediat, lăsând fișierul vostru corect și valoarea efectivă greșită. Nu suprascrieți un fișier de administrator existent ca să câștigați acea dispută; găsiți proprietarul și schimbați acolo.

Un spațiu de nume creat după pornire nu este deloc guvernat de un drop-in al gazdei. Setarea lui aparține celui care îl creează, fie că este mediul de execuție al containerelor, fie unitatea de provizionare a spațiului de nume. A da unui container privilegii largi de gazdă pentru a evita întrebarea este o afacere mai proastă decât zece minute petrecute identificând proprietarul corect.

Aflați cât costă comutatorul înainte de a-l acționa

ip_forward nu este un boolean inofensiv. Documentația nucleului notează că schimbarea lui resetează mai mulți alți parametri IPv4 la valorile implicite ale gazdei sau ale routerului, așa că o comutare de diagnostic poate arunca reglaje făcute în altă parte și nu le menționează niciodată. Tratați-l ca pe o modificare de configurație cu efecte secundare, nu ca pe o sondă care poate fi rulată în joacă.

Asta exclude și oprirea și pornirea lui de fiecare dată când un client nu ajunge la o gazdă. Dacă valoarea este deja unu, defecțiunea este în altă parte a căii, iar rescrierea aceleiași chei a treia oară nu o va mișca.

Dovediți durabilitatea, apoi testați restul căii

Citiți valoarea înapoi în patru momente: imediat după modificare, după ce apare interfața VPN, după o reconectare și după o repornire planificată. O valoare care revine în oricare dintre aceste puncte are un al doilea proprietar, iar încă o scriere unică doar o ascunde până la următoarea repornire.

Redirecționarea activată lasă totuși trei lucruri de verificat. Clientul are nevoie de o rută către destinație, gateway-ul are nevoie de o rută următoare plus permisiunea de a o folosi, iar destinația are nevoie de o cale de întoarcere către adresa tunelului clientului. Un LAN privat rutat nu are nevoie automat de NAT, așa că nu adăugați masquerading înainte de a ști care dintre cele trei lipsește, și testați din clientul dorit, nu din gateway-ul însuși, pentru că o cerere pornită pe gateway nu atinge niciodată calea de redirecționare pe care tocmai ați activat-o. IPv6 are propria politică de redirecționare și rutare, așa că un test IPv4 funcțional nu spune nimic despre ea.

Țineți împreună în runbook calea drop-in, proprietarul spațiului de nume și comanda de recitire. Următoarea persoană care preia asta ar trebui să poată citi valoarea, să vadă cine o deține și să decidă într-un minut dacă problema este durabilitatea sau restul căii.