OpenVPN cade după o reînnoire DHCP: păstrează ruta punctului final

Tunelul se conectează, apoi o reînnoire a bailului pe legătura de acces îl ucide, iar jurnalul dă vina pe un timeout în loc de o rută. Nimic din configurația VPN nu s-a schimbat, și acesta este indiciul: ceva din afara ei s-a schimbat. Un eveniment DHCP a rescris adresa sau gateway-ul, iar ruta de host care ținea punctul final al tunelului accesibil indică acum un salt următor care nu mai există. Aceasta este o problemă de proprietate înainte de a fi o problemă de rutare.

Compară simptomul cu rutele semi-implicite

Cu redirect-gateway def1, OpenVPN instalează 0.0.0.0/1 și 128.0.0.0/1 în loc să înlocuiască ruta implicită. Împreună, cele două acoperă întregul spațiu de adrese și înving 0.0.0.0/0 doar prin lungimea prefixului. De aceea orice destinație fără o potrivire mai specifică intră în tunel.

Punctul final are nevoie de o excepție. OpenVPN adaugă o rută de host către adresa serverului prin gateway-ul de acces original înainte de a intra semi-implicitele, ca pachetele încapsulate să poată ieși. Când acea excepție dispare, sau păstrează un salt următor care nu mai există, pachetele exterioare ale tunelului însuși se potrivesc cu o semi-implicită și sunt trimise înapoi în tunel. Rezultatul este o conexiune care moare la următorul keepalive sau handshake, fără nimic în jurnal care să semene cu o eroare de rutare.

Confirmă forma tabelului înainte de a atinge orice altceva. ip route show ar trebui să listeze ambele jumătăți plus o rută de host pentru adresa serverului; când ruta de host lipsește, restul investigației are un punct de plecare evident.

De ce câștigă semi-implicitele fără schimbarea metricii

O metrică mai mică nu învinge un prefix mai lung. Rutele /1 câștigă pentru că nucleul potrivește mai întâi ruta cea mai specifică, așa că ridicarea unei metrici pe ruta implicită nu schimbă nimic în privința locului unde merge traficul destinat tunelului. Goana după metrici este cea mai frecventă greșeală în acest diagnostic.

Verifică selecția cu ip route get 203.0.113.10, înlocuind cu adresa reală a serverului. Răspunsul numește interfața și saltul următor pe care nucleul le-ar folosi efectiv, ceea ce este mai informativ decât să citești un tabel și să raționezi despre el.

Rulează acea comandă înainte ca tunelul să pornească, în timp ce rulează și după evenimentul de bail. Trei răspunsuri dintr-o singură comandă, iar punctul de divergență devine vizibil.

Fă trei instantanee, nu unul

Colectează adresa de acces, gateway-ul de acces, destinația punctului final, ruta selectată și orice reguli de politică în trei momente: după configurarea legăturii de acces, după conectarea VPN și după evenimentul de bail sau al operatorului. Fiecare instantaneu este o mână de comenzi, și au sens doar împreună. Un singur instantaneu după eșec înregistrează starea, nu tranziția. Scrie comenzile într-un script mic, ca fiecare instantaneu să fie făcut la fel.

Ține instantaneele într-un singur fișier cu mărci de timp, pentru că întrebarea interesantă mai târziu este ordinea. Evenimentul DHCP a venit înainte sau după ce OpenVPN și-a reîmprospătat ruta? Răspunsul decide cine trebuie să repare. O marcă de timp de la un ceas greșit este mai rea decât niciuna, așa că ia-o de la gazda care deține tabelul de rutare.

Când punctul final este configurat ca nume în loc de adresă, rezolvă-l și în fiecare instantaneu. O schimbare DNS pe legătura de acces poate muta punctul final fără ca vreo rută să fie atinsă.

Decide ce componentă reîmprospătează excepția

Pe un sistem dhcpcd, cârligele rulează din directorul de cârlige și din cârligul de ieșire, iar modul manager diferă ca amploare de modul pe interfață. Orice ar face cârligul, trebuie să fie idempotent, pentru că reînnoirile pot veni în rafale.

Proprietarul de încredere este integrarea care cunoaște deja ambele părți: un manager de rețea care administrează conexiunea VPN, sau o unitate ordonată după ce legătura de acces urcă. O rută statică adăugată de un cârlig funcționează până la următoarea schimbare de gateway, apoi eșuează exact în același fel. Dacă totuși folosești un cârlig, fă-l să citească gateway-ul curent la rulare în loc să codifice dur pe cel pe care l-ai văzut azi.

Înregistrează proprietarul în configurație. Următoarea persoană care depanează o reconectare trebuie să știe că un cârlig, nu VPN-ul, este responsabil pentru ruta de excepție.

Testează ciclul de viață, nu doar reconectarea

Forțează o reînnoire cu dhcpcd -n eth0 sau eliberând și reînnoind bailul, apoi verifică din nou ip route get pentru punctul final. Fă-o de două ori, pentru că a doua trecere prinde cârligele care adaugă rute duplicate. Apoi repornește, pentru că persistența este o proprietate diferită de corectitudine.

Un tunel care supraviețuiește unei reînnoiri și unei reporniri are proprietar și o excepție funcțională. Cel care supraviețuiește doar unei reporniri manuale nu are niciuna, și va eșua la următorul eveniment pe care nu îl poți programa.