De ce adăugarea opt-verify nu va repara eroarea de criptare din OpenVPN

Găsiți o sugestie de a adăuga opt-verify, adăugați linia, iar eroarea de criptare rămâne exact acolo unde era. Acel rezultat este previzibil, deoarece opțiunea nu a negociat niciodată o criptare. A fost o verificare a consecvenței opțiunilor, învechită în 2.6 și eliminată în 2.7, iar un profil care încă este analizat cu ea nu a impus nimic prin asta.

Ajută să știți ce făcea linia înainte de a concluziona că este piesa lipsă. Istoricul explică și de ce nu poate ajuta acum.

Ce impunea opțiunea înainte

Manualul pentru 2.6 marchează opt-verify ca învechită și descrie comportamentul anterior: serverul elimină clienții ale căror opțiuni declarate nu corespund cu ale sale, comparând lucruri precum tipul dispozitivului și MTU. Verificarea depinde și de menținerea activă a verificării consecvenței opțiunilor, așa că un server care rulează cu disable-occ nu a avut-o niciodată. Observați din ce este construită comparația: text care descrie configurația celeilalte părți. Nu spune nimic despre ce criptare va folosi canalul de date.

Acesta este primul motiv pentru care indicatorul nu poate repara o eroare de criptare. Alegerea criptării este guvernată de politica data-ciphers și de ceea ce acceptă ambele părți, iar o verificare textuală a consecvenței nici nu extinde lista, nici nu efectuează negocierea. Al doilea motiv este amploarea: verificarea se referă la dacă opțiunile declarate par compatibile, nu la calitatea căii care rezultă.

Ce face 2.7 când vede linia

În 2.7 opțiunea nu mai există. Parserul recunoaște încă numele, de aceea un profil vechi se încarcă fără eroare de sintaxă, și raportează că opțiunea a fost eliminată în loc să o treacă cu vederea în tăcere. A recunoaște un nume și a impune un comportament sunt lucruri diferite, și doar primul se mai întâmplă. Notele de eliminare dau motivul: odată ce parametrii pot fi negociați, două părți pot avea în mod legitim șiruri de opțiuni diferite în timp ce sunt de acord asupra conexiunii.

Un profil care este analizat, așadar, nu este dovada că s-a executat vreo verificare de admitere. Dacă singurul semnal este că clientul s-a conectat, ați aflat că sintaxa a fost acceptată.

Unde se află de fapt defectul

Păstrați prima eroare concretă înainte de a schimba ceva, pentru că mesajele ulterioare sunt de obicei consecințele ei. Un eșec de negociere a canalului de date aparține politicii de criptare aprobate și capacităților pe care ambele părți le anunță efectiv. Un eșec de versiune sau de suită TLS aparține canalului de control. O respingere de certificat are nevoie de identitate și de lanțul de încredere, nu de un indicator de compatibilitate.

Identificați și motorul la ambele capete. O aplicație desktop poate include o compilare diferită de binarul din linia de comandă cu care ați testat, iar suportul pentru opțiuni diferă între ele. Consultați documentația acelui motor în loc să presupuneți că fiecare program care importă un profil se comportă la fel.

Înlocuiți intenția, nu doar linia

Dacă un server administrat mai vechi se baza cu adevărat pe verificarea consecvenței, notați ce restricție impunea înainte de actualizare. Păstrarea unei opțiuni ignorate într-un profil mai nou nu poate conserva acea politică, iar ștergerea liniilor fără discernământ nici atât.

Nu răspundeți la o sugestie veche că toate criptările sunt dezactivate prin activarea fiecărui algoritm istoric.

După o corecție aprobată, examinați rezultatele negociate pe o conexiune nouă și testați aplicația de care utilizatorul are cu adevărat nevoie. Țineți versiunea serverului și politica efectivă lângă acel rezultat, ca următoarea persoană să vadă ce s-a convenit, nu doar ce s-a acceptat.

Scopul este o restricție acceptată și o cale autentificată funcțională, nu un indicator vechi care încă este analizat.