Cine deține adresa, ruta, DNS-ul și firewall-ul pe un VPN Linux?

Două scripturi care se luptă pentru aceeași rută este forma obișnuită a unei probleme de VPN Linux care este înregistrată ca eroare de rutare. O componentă creează dispozitivul de tunel, alta adaugă o rută implicită, a treia rescrie configurația resolverului, iar a patra reîncarcă regulile firewall-ului. Oricare dintre ele poate anula munca alteia, iar câștigător este pur și simplu cel care a rulat ultimul. Întrebarea care merită un răspuns nu este ce pachet să instalați, ci ce componentă are autoritate pentru fiecare parte a stării.

Scrieți această hartă o dată, și majoritatea eșecurilor de reconectare încetează să mai fie misterioase. Patru obiecte contează: dispozitivul și adresele sale, rutele și regulile de politică, configurația DNS și firewall-ul.

Dispozitivul și adresele sale

Un dispozitiv de tunel este creat fie de un manager care cunoaște profilul, fie de un daemon pe care cineva l-a pornit manual. Ambele aranjamente funcționează singure; amestecarea lor nu. Dacă NetworkManager deține profilul, lăsați-l să dețină și dispozitivul, și nu porniți un OpenVPN proces negestionat împotriva aceluiași nume de tunel.

Notați cine elimină dispozitivul când sesiunea se termină. Un dispozitiv care supraviețuiește sesiunii sale este cea mai frecventă sursă de adrese învechite și de confuzia care urmează.

Rute și reguli de politică

Exact pe rute conflictele de proprietate fac pagube vizibile. Un manager de conexiuni instalează o rută implicită pentru tunel plus o rută mai specifică pentru rețeaua îndepărtată; apoi un script scris de mână adaugă propria rută implicită cu altă metrică și câștigă sau pierde în tăcere în funcție de moment. Decideți care intrări sunt legate de conexiune, care sunt politică permanentă și ce componentă le reîmprospătează după o reconectare. Apoi țineți celelalte componente în afara acelei tabele.

Regulile de politică merită aceeași claritate, pentru că o regulă care indică un tabel pe care nimeni nu îl umple produce o gaură neagră care arată exact ca un tunel mort. Dacă există o regulă pentru a forța traficul undeva, tabelul pe care îl selectează trebuie întreținut de același proprietar.

DNS este întotdeauna un proprietar separat

Un daemon resolver rulează ca proces propriu sub propria identitate, așa că nu moștenește din greșeală deciziile de rutare ale tunelului. Când VPN-ul împinge servere DNS, ceva trebuie să traducă asta într-o configurație pe legătură pe care resolverul o respectă, iar ceva trebuie să o elimine după aceea.

Mitul de aici este că scrierea unui server de nume în profil schimbă unde merg interogările. Schimbă ce i se spune resolverului, nu ce socket folosește resolverul în amonte. Testați cu o interogare plus o căutare de rută în loc să aveți încredere în fișier.

Starea firewall-ului, și cine o restaurează

Regulile firewall sunt obiectul cel mai des suprascris pe un host VPN. Un manager poate adăuga reguli NAT sau de redirecționare pentru fiecare conexiune, în timp ce un serviciu firewall la pornire reîncarcă un set de reguli salvat și le șterge. Alegeți o singură autoritate pentru politică și faceți din cealaltă un consumator al ei, sau acceptați că o repornire schimbă comportamentul în tăcere. Excepțiile legate de conexiune aparțin unui fișier pe care îl încarcă același proprietar, nu unei comenzi iptables tastate în timpul depanării.

Dacă regulile trebuie să supraviețuiască unei reconectări, spuneți-o explicit. Dacă nu trebuie, spuneți și asta, pentru că următorul inginer va presupune răspunsul cel mai comod.

Ciclu de viață: pornire, reconectare, demontare

Dați un proprietar fiecăruia dintre cele trei momente. La pornire, decideți ce pregătește condițiile prealabile și în ce ordine. La o repornire blândă, amintiți-vă că dispozitivul poate supraviețui în timp ce starea sesiunii nu, așa că trebuie să ruleze un validator, nu un creator. La demontare, eliminați doar ce a creat această conexiune, pentru că resetarea fiecărei rute sau golirea întregului firewall nu este același lucru cu scoaterea unui singur tunel din uz.

Pentru observare, ip monitor link address route arată modificările kernelului pe măsură ce apar, dar raportează evenimente, nu intenție: o rută ștearsă nu spune nimic despre ce proces a șters-o. Asociați-l cu harta de proprietate, și o oprire confuză devine o listă scurtă de candidați.

Excepțiile au și ele un cost. Marcarea unei întregi clase de dispozitive ca negestionată pentru a scăpa de un conflict predă acea stare nimănui, ceea ce este o decizie, nu o corecție.