O parte a tunelului semnează canalul de control cu un slot de cheie pe care cealaltă parte nu îl verifică niciodată, iar conexiunea moare cu o eroare de autentificare înainte de a fi schimbat măcar un certificat. Așa arată o nepotrivire de direcție la tls-auth, și este deterministă: aceleași două fișiere eșuează la fiecare încercare, din orice rețea. Nimic din jurnal nu numește opțiunea pe care o căutați, de aceea oamenii reconstruiesc chei și reemit certificate care nu au fost niciodată stricate. Soluția este să faceți cele două capete complementare sau să le lăsați pe amândouă bidirecționale, nu să slăbiți verificarea.

Eșecul apare înaintea certificatelor

Cu tls-auth, ambele părți dețin aceeași cheie partajată și fiecare folosește unul dintre cele două sloturi derivate din ea: un slot semnează pachetele de control ieșite, celălalt verifică pachetele primite. Direcția 0 și direcția 1 atribuie aceste roluri în ordine inversă, așa că perechea trebuie să fie complementară pentru ca verificările HMAC să se potrivească. Când atribuirea este inversată pe o parte, receptorul caută o semnătură în slotul greșit și respinge pachetul. Sesiunea se termină acolo, de aceea eroarea privește autentificarea pachetelor, nu ceva ce ar produce depozitul de certificate.

Determinismul contează pentru diagnostic, pentru că o problemă de timp sau de rută lasă o urmă diferită: întreruperi intermitente, o direcție care eșuează sau o sesiune care moare doar într-o anumită rețea. O nepotrivire de direcție eșuează la primul handshake de fiecare dată și eșuează identic pe altă mașină cu aceleași două fișiere. Citiți jurnalul la --verb 4 și găsiți primul pachet respins în locul ultimei linii. Dacă acea respingere are loc înainte de orice schimb de certificate, cheia partajată și direcția ei sunt cele două lucruri care merită verificate.

What you seeWhat it rules outNext check
Authentication error before any certificate is sentThe data channel is irrelevant; the control channel never authenticatedCompare tls-auth and its direction on both ends
Certificate or handshake failure after the control channel authenticatesThe shared key and its direction already agreeCheck the CA, the certificate dates and the hostname
Session completes but throughput or cipher warnings appearDirection was never the problemCompare the data-channel cipher settings
Startup stops on an options errorThe number itself is not the issueRe-read the inline versus external directive syntax

Unde locuiește numărul

Manualul OpenVPN 2.6 documentează două locuri pentru direcție: al doilea argument al tls-auth când cheia stă într-un fișier propriu, și o linie key-direction separată când cheia este încorporată în profil. Ambele stabilesc aceeași valoare, așa că un profil trebuie să folosească o formă sau cealaltă, niciodată pe amândouă. Omiterea este și ea o alegere și pune ambele părți într-o aranjare bidirecțională care funcționează când nici o parte nu numește o direcție. Două părți cu același număr nu sunt în acea aranjare: fiecare se așteaptă să semneze într-un slot și să verifice în celălalt, iar ambele fac asta la fel.

# server.conf, external key
tls-auth ta.key 0

# client.ovpn, external key
tls-auth ta.key 1

# client.ovpn, inline key
key-direction 1

Forma încorporată este o directivă pe linia ei, nu un atribut pe eticheta de deschidere a blocului de cheie, iar adăugarea unui argument la acea etichetă este o eroare, nu o schimbare de direcție. Și plasarea contează: directiva stă în afara blocului căruia îi aparține, așa că o valoare scrisă în interiorul blocului este citită ca material de cheie. Copiați aranjarea pe care distribuitorul profilului a intenționat-o în loc să inventați o pereche, pentru că un profil care funcționează împotriva unui server poate fi deja oglindit pe cealaltă parte.

Ce lasă neatins opțiunea

Nu criptează traficul aplicațiilor. tls-auth pune un HMAC în jurul pachetelor canalului de control, în timp ce canalul de date este protejat de chei de sesiune negociate în timpul handshake-ului, așa că o întrebare despre debit sau cifru nu are nimic de-a face cu numărul direcției. Setarea nu adaugă nici un al doilea strat de criptare, și exact această presupunere trimite oamenii să caute o cheie mai lungă.

Nu se aplică pentru tls-crypt, un alt mecanism de canal de control cu opțiuni și gestionare a cheilor proprii, și nu spune nimic despre identitatea certificatului vreunei părți. Așa că o potrivire de direcție care funcționează dovedește doar că cele două capete sunt de acord cum să autentifice canalul de control, nu că lanțul de încredere a fost validat.

Aliniați perechea, apoi reconectați

Comparați cele două configurații înainte de a o schimba pe vreuna, pentru că editarea părții care era deja corectă dublează munca. Grep-ul de mai jos arată ce mecanism alege fiecare fișier; rularea detaliată arată dacă canalul de control a fost autentificat. Păstrați ambele ieșiri, ca următoarea modificare să poată fi comparată cu o stare cunoscută.

grep -n -E 'tls-auth|tls-crypt|key-direction' server.conf client.ovpn
openvpn --config client.ovpn --verb 4 2>&1 | grep -i -E 'hmac|tls error|control channel'

Reporniți ambele capete după orice modificare, pentru că aceste opțiuni sunt citite o dată la pornire, iar reîncărcarea unei părți lasă perechea inconsistentă pentru toată durata de viață a sesiunii vechi. Dacă implementarea funcționează acum fără o direcție configurată, adăugarea setării la un capăt reproduce eșecul cu care ați început; fie lăsați ambele, fie configurați ambele. Schimbați un capăt pe rând și păstrați fișierul anterior, ca o regresie să fie o revenire de două minute, nu o reconstrucție.

Notați mecanismul, fișierul de cheie și direcția pentru fiecare capăt în notele de implementare, pentru că altfel următoarea persoană va citi două fișiere similare și va presupune că numerele trebuie să se potrivească între ele. Direcția este un detaliu de coordonare, nu o îmbunătățire de securitate: separă cele două direcții ale canalului de control și nu face nimic altceva.

Articole similare