Cum alege OpenVPN data-ciphers cifrul canalului de date

Tunelul se ridică, jurnalul arată un cifru și revizuirea profilului continuă. Apoi sosește o actualizare la un partener și același profil eșuează cu un mesaj despre niciun cifru comun, ceea ce trimite oamenii să caute o directivă de șters. Lucrul util de înțeles este că data-ciphers descrie o negociere, nu o setare. O parte oferă o listă, cealaltă alege din ea, iar rezultatul este un singur algoritm pe care ambele îl acceptă. Citirea acelui schimb explică majoritatea acestor eșecuri înainte de a schimba o linie.

Două canale, două configurații

O OpenVPN sesiune are un canal de control și un canal de date. Canalul de control rulează strângerea de mână TLS care autentifică partenerii și negociază cheile. Canalul de date criptează pachetele care transportă traficul dumneavoastră.

data-ciphers îl configurează pe al doilea. Canalul de control are propriile opțiuni, iar verificările de identitate ale profilului sunt o a treia chestiune, separată. O modificare la unul nu îl repară pe celălalt, motiv pentru care un profil poate părea corect și totuși poate eșua la o anumită etapă.

Țineți cele trei în cutii separate când citiți un fișier de configurare.

Citiți negocierea din jurnal

Jurnalul clientului numește ambele rezultate când conexiunea reușește. O linie raportează canalul de control și detaliile sale TLS, iar alta raportează cifrul canalului de date care a fost selectat.

Citiți ambele, pentru că răspund la întrebări diferite. O defecțiune a canalului de control oprește conexiunea înainte ca vreun cifru de date să conteze. O nepotrivire a canalului de date apare după o strângere de mână reușită, cu un mesaj despre niciun cifru comun.

Apoi comparați listele oferite pe ambele părți. Un nume pe care versiunea unui partener sau fundalul său criptografic nu îl furnizează nu poate fi selectat, oricât de devreme ar apărea în lista celuilalt partener.

Cum se produce de fapt selecția

Serverul împinge lista sa data-ciphers către client în timpul strângerii de mână, iar clientul selectează prima intrare din acea listă pe care o acceptă și el. Ordinea aparține așadar configurației serverului, nu celei a clientului.

Acel detaliu explică o clasă de rezultate încurcătoare. Reordonarea listei clientului nu schimbă nimic cât timp decide lista serverului. Adăugarea unui cifru pe care clientul nu îl poate furniza nu schimbă nici ea nimic, pentru că clientul trebuie să poată folosi intrarea pe care o alege.

Versiunile mai noi au schimbat lista implicită și au redenumit opțiunea care o conținea, astfel încât doi parteneri pe versiuni diferite se pot contrazice fără ca cineva să editeze un profil. Verificați versiunea pe fiecare parte înainte de a presupune o greșeală de tastare.

O listă nu este un clasament al puterii în abstract. Este un set de candidați, iar cel selectat este prima intrare acceptată reciproc în ordinea serverului. De aceea două liste care arată diferit pot negocia același cifru. De aceea și două liste care arată identic pot eșua.

Partenerii mai vechi au nevoie de o rezervă deliberată

Un partener care nu poate negocia deloc, pentru că este mai vechi decât mecanismul sau îl are dezactivat, are nevoie de o soluție de compatibilitate documentată. Opțiunea de rezervă există exact pentru acel caz și se aplică partenerilor care nu participă la negociere.

Aceasta nu este același lucru cu activarea fiecărui cifru vechi pentru ca un mesaj să dispară. O listă largă slăbește sesiunea pentru fiecare partener, inclusiv pentru cei care ar fi negociat ceva puternic.

Coordonați cele două părți în loc să editați nume de algoritmi fără legătură. Dacă o actualizare a serverului a eliminat o opțiune veche, corectarea aparține planului de versiuni, nu unei alergături la client.

Păstrați verificarea intactă

O nepotrivire a canalului de date nu este un motiv să acceptați un server neverificat. Verificarea certificatului, numele de server așteptat și setările de protecție ale canalului de control sunt separate de alegerea cifrului și ar trebui să supraviețuiască oricărei schimbări de compatibilitate.

Înregistrați împreună cifrul de date negociat, versiunea clientului și versiunea serverului, astfel încât următoarea comparație să pornească de la fapte, nu de la fișierul de profil.

După o corectare acceptată, testați conexiunea inițială și o renegociere, pentru că o sesiune care se stabilește o dată poate eșua în continuare la reînnoirea cheilor.

Dacă tunelul se stabilește și site-urile încă eșuează, cifrul nu mai este suspectul. Continuați cu rutarea și DNS. Ordinea de lucru: citiți ambele linii de jurnal, comparați ambele liste, verificați versiunile, adăugați o rezervă doar pentru un partener care are nevoie de ea, apoi retestați calea de reînnoire.