tun precreat în OpenVPN: compararea celor două modele de proprietate

Cineva a precreat tun1, profilul spune dev tun1, iar conexiunea tot nu se atașează. Existența numelui pe gazdă aproape nu spune nimic, pentru că atașarea depinde de spațiul de nume, de tipul dispozitivului, de cine deține legătura și de ce i se permite daemonului. Reutilizarea unui dispozitiv impune și o decizie pe care configurația implicită o ascunde: ce component scrie adresele și rutele. Modurile de eșec ale celor două aranjamente diferă mult mai mult decât liniile de configurare, așa că decideți înainte de a edita un profil.

Un nume nu este o atașare

dev tun1 cere OpenVPN acea interfață numită, iar construcțiile tradiționale din spațiul utilizator vor încerca să o deschidă. Dacă numele nu urmează modelul obișnuit tun sau tap, profilul are nevoie și de un dev-type corespunzător, pentru că tipul nu este dedus niciodată dintr-un șir. Un dispozitiv TAP nu este un dispozitiv TUN cu altă etichetă: atașarea celui greșit fie eșuează imediat, fie produce o legătură care transportă cadre pe care nimeni nu le așteaptă. Verificați tipul înainte de orice altceva, fiindcă fiecare verificare ulterioară presupune că ambele părți sunt de acord asupra lui. De acolo, confirmați că procesul poate chiar deschide dispozitivul, nu doar să îl vadă.

dev tun1
dev-type tun

Interfața de rețea și /dev/net/tun sunt obiecte diferite: una este o legătură într-un spațiu de nume, cealaltă este dispozitivul de caractere pe care un program din spațiul utilizator îl folosește pentru atașare. Documentația Linux TUN/TAP descrie acea cale de atașare și regulile de proprietate pentru dispozitivele persistente. Un shell root care poate rula ip link dovedește doar că shell-ul are privilegii, nu că le are daemonul. Proprietatea nodului de dispozitiv, setul de capabilități ale serviciului și utilizatorul sub care rulează trebuie să se alinieze toate înainte ca deschiderea să reușească.

Un dispozitiv care există și nu se deschide este o problemă de proprietate, nu de rutare. Tratați-l ca atare în timpul depanării, altfel după-amiaza se duce citind tabele de rutare care nu au fost niciodată problema.

Cine configurează legătura: două modele de proprietate

În primul model OpenVPN configurează adresele și rutele ca parte a ridicării conexiunii. Acesta este comportamentul implicit și cel mai ușor de analizat, pentru că un singur component creează starea și apoi o elimină. În al doilea model un manager extern deține interfața, iar ifconfig-noexec împiedică OpenVPN să își execute comenzile de configurare a adreselor și predă parametrii unor scripturi. Atunci managerul trebuie să aplice el însuși configurația locală și a partenerului corectă, ceea ce este mai multă muncă decât sugerează numele opțiunii. Alegerea între cele două este o întrebare despre cine poate modifica legătura cât timp este ridicată.

ifconfig-noexec acoperă doar adresele: tabela de rutare rămâne neatinsă, iar configurarea rutelor aparține lui route-noexec. Tratați cele două directive ca mecanisme separate cu proprietari separați, pentru că setarea uneia și presupunerea celeilalte este o sursă obișnuită de legături pe jumătate configurate. Alegeți exact un proprietar pe strat, adresele într-un loc și rutele într-un loc. Un manager de rețea și un ajutor VPN care scriu amândoi adrese este felul în care o deconectare șterge o stare de care cealaltă parte încă depinde.

Inspectați dispozitivul din spațiul de nume care contează

Inspectați dispozitivul din spațiul de nume în care rulează procesul VPN, nu din cel în care se află din întâmplare shell-ul dumneavoastră. Cele două comenzi de mai jos răspund la întrebări diferite, iar diferența apare când o gazdă vede o interfață pe care un container nu o vede. Rulați-le în ordinea dată, pentru că a doua are sens doar după ce știți dacă legătura există.

ip -details link show dev tun1
ip tuntap show

Prima comandă tipărește legătura așa cum o vede kernelul, inclusiv fanioanele și tipul interfeței, și astfel confirmați că acesta este dispozitivul vizat. A doua listează intrările tun/tap persistente, care există fără ca vreun proces să le țină. O interfață care așteaptă proprietarul destinat este o situație diferită de un tunel viu atașat la alt VPN, și doar a doua explică de ce atașarea dumneavoastră eșuează. Găsiți procesul care ține dispozitivul înainte de a schimba ceva, pentru că o intrare persistentă și o interfață ocupată au remedii diferite.

Suportul pentru mai multe cozi este un aranjament specific de driver cu propriile cerințe, nu o permisiune pentru procese nelegate să partajeze o interfață. Sesiunea vie a altui proprietar este o problemă de coordonare, iar nicio editare de profil nu o rezolvă.

Două tipuri de persistență

Persistența kernelului și persist-tun descriu durate de viață ușor de confundat și costisitor de încurcat. Un dispozitiv persistent există independent de orice proces, așa că supraviețuiește unei opriri și poate fi reutilizat la următoarea pornire. persist-tun păstrează resursele peste resetările soft acceptate în interiorul unui singur proces OpenVPN, un orizont mult mai scurt. Niciunul nu promite că oprirea serviciului lasă rutele și adresele la locul lor, iar o interfață care rămâne vizibilă nu este dovada unei sesiuni criptate funcționale.

Confirmați și backendul, pentru că o interfață precreată nu spune nimic despre ce implementare o va deschide. Construcțiile comunitare care aduc calea directă de date vor încerca să o folosească, dacă proiectarea nu spune altceva. Acolo unde versiunea acceptă comutatorul, disable-dco selectează în schimb calea din spațiul utilizator; motoarele mai vechi și alți clienți nu au o astfel de directivă, așa că țineți condiția de versiune lângă opțiune în loc să presupuneți că se aplică.

Ce se strică atunci când se testează doar pornirea

Un acord de proprietate poate trece primul test și poate eșua la ultimul, ceea ce face pornirea o verificare slabă de una singură. Urmăriți în schimb două tranziții: o resetare soft și o oprire completă urmată de o pornire.

systemctl status openvpn-client@lab
ip -details link show dev tun1

Pornirea este cazul ușor: unitatea urcă, legătura apare, iar ieșirea de stare numește profilul încărcat. Atașarea este momentul în care daemonul deschide dispozitivul, așa că rulați verificarea legăturii după ce unitatea raportează că este activă, nu înainte. Dacă legătura există în timp ce starea încă se activează, priviți un dispozitiv persistent de care nu s-a atașat încă nimeni, nu un tunel funcțional. Trimiteți trafic real prin legătură înainte de a continua, pentru că o interfață atașată fără rută utilizabilă rămâne un eșec.

kill -SIGHUP $(pidof openvpn)
journalctl -u openvpn-client@lab -n 40
systemctl stop openvpn-client@lab
ip -details link show dev tun1

O resetare soft ar trebui să lase sesiunea utilizabilă și resursele intacte, iar aceasta este munca pe care o face persist-tun. Oprirea completă este locul unde un manager extern se dezvăluie: dacă legătura sau adresele ei supraviețuiesc opririi, altcineva le deține, iar asta este fie starea pe care ați documentat-o, fie eroarea pe care tocmai ați găsit-o. Consemnați ambele observații lângă profil, ca următoarea modificare să înceapă din dovezi, nu dintr-o diagramă.