Miért nem javítja meg az opt-verify hozzáadása az OpenVPN titkosítási hibáját

Talál egy javaslatot, hogy adja hozzá a opt-verify beállítást, hozzáadja a sort, és a titkosítási hiba pontosan ott marad, ahol volt. Ez az eredmény kiszámítható, mert a beállítás soha nem tárgyalt titkosításról. Opciókonzisztencia-ellenőrzés volt, a 2.6-ban elavult, a 2.7-ben eltávolították, és egy profil, amely ezzel még elemezhető, ezáltal semmit sem kényszerített ki.

Hasznos tudni, mit tett korábban a sor, mielőtt arra jutna, hogy ez a hiányzó darab. A történet azt is elmagyarázza, miért nem segíthet most.

Mit kényszerített ki korábban a beállítás

A 2.6 kézikönyve elavultként jelöli a opt-verify beállítást, és leírja a korábbi viselkedést: a kiszolgáló eldobja azokat a klienseket, amelyek deklarált beállításai nem egyeznek a sajátjaival, olyan dolgokat hasonlítva össze, mint az eszköztípus és az MTU. Ez az ellenőrzés attól is függ, hogy az opciókonzisztencia-ellenőrzés bekapcsolva maradjon, így egy disable-occ beállítással futó kiszolgálónak soha nem volt ilyenje. Figyelje meg, miből épül fel az összehasonlítás: a másik fél konfigurációját leíró szövegből. Semmit sem mond arról, melyik titkosítást fogja használni az adatcsatorna.

Ez az első ok, amiért a kapcsoló nem tud megjavítani egy titkosítási hibát. A titkosítás kiválasztását a data-ciphers szabályzat és mindkét fél támogatása határozza meg, és egy szöveges konzisztencia-ellenőrzés sem nem bővíti ezt a listát, sem nem végzi el a tárgyalást. A második ok a hatókör: az ellenőrzés arról szól, hogy a deklarált beállítások kompatibilisnek tűnnek-e, nem az eredményül kapott útvonal minőségéről.

Mit tesz a 2.7, amikor meglátja a sort

A 2.7-ben a beállítás már nincs. Az elemző még felismeri a nevet, ezért egy régi profil szintaktikai hiba nélkül betöltődik, és jelenti, hogy a beállítást eltávolították, ahelyett hogy csendben átlépné. Egy nevet felismerni és egy viselkedést kikényszeríteni két különböző dolog, és még csak az első történik meg. Az eltávolítási megjegyzések adják meg az okot: amint a paraméterekről tárgyalni lehet, két fél jogosan rendelkezhet eltérő opciósztringekkel, miközben megegyezik a kapcsolatban.

Egy elemzett profil tehát nem bizonyíték arra, hogy bármilyen belépésellenőrzés lefutott. Ha az egyetlen jelzés az, hogy a kliens csatlakozott, akkor azt tudta meg, hogy a szintaxist elfogadták.

Hol lakik valójában a hiba

Őrizze meg az első konkrét hibát, mielőtt bármit módosítana, mert a későbbi üzenetek általában annak következményei. Az adatcsatorna-tárgyalás kudarca a jóváhagyott titkosítási szabályzathoz és azokhoz a képességekhez tartozik, amelyeket mindkét fél ténylegesen hirdet. A TLS-verzió vagy -csomag kudarca a vezérlőcsatornához tartozik. A tanúsítvány elutasítása az identitást és a bizalmi láncot igényli, nem egy kompatibilitási kapcsolót.

Azonosítsa a motort mindkét végén is. Egy asztali alkalmazás más buildet csomagolhat, mint a parancssori bináris, amellyel tesztelt, és az opciótámogatás eltér közöttük. Nézze meg annak a motornak a dokumentációját, ahelyett hogy feltételezné, hogy minden profilimportáló program ugyanúgy viselkedik.

Cserélje le a szándékot, ne csak a sort

Ha egy régebbi felügyelt kiszolgáló valóban a konzisztencia-ellenőrzésre támaszkodott, jegyezze fel, milyen korlátot kényszerített ki a frissítés előtt. Egy figyelmen kívül hagyott beállítás megtartása egy újabb profilban nem őrizheti meg ezt a szabályzatot, és a sorok válogatás nélküli törlése sem.

Ne válaszoljon egy régi javaslatra, hogy minden titkosítás le van tiltva, azzal, hogy minden történelmi algoritmust engedélyez.

Egy jóváhagyott javítás után vizsgálja meg a tárgyalt eredményeket egy friss kapcsolaton, és tesztelje az alkalmazást, amelyre a felhasználónak valóban szüksége van. Tartsa a kiszolgáló verzióját és a tényleges szabályzatot az eredmény mellett, hogy a következő ember lássa, mi lett megbeszélve, ne csak azt, mit fogadtak el.

A cél egy támogatott korlát és egy működő hitelesített útvonal, nem egy örökölt kapcsoló, amely még elemzhető.