Három különböző tény olvad össze egyetlen sorba a legtöbb OpenVPN TLS-vitában: mit tud a kliens buildje, mit engedélyez a profil, és mit egyeztetett ténylegesen a munkamenet. Egy rövid TLS 1.3 csomaglista csak félig válaszol a középső kérdésre, és semmit sem mond a protokollverzió alsó korlátjáról. Haladjon végig az alábbi ellenőrzéseken sorrendben, és álljon meg az elsőnél, amely nem állja meg a helyét, mert minden későbbi ellenőrzés azt feltételezi, hogy az előzőek rendezettek.

Ellenőrizze a buildet, mielőtt bármilyen listát elolvasna

Egy konfigurációs direktíva nem tud protokolltámogatást hozzáadni egy bináris fájlhoz, amelyből hiányzik. Kezdje a verzióbannerrel, amely megnevezi a lefordított kriptográfiai könyvtárat:

openvpn --version

Az OpenSSL-hez linkelt 2.6 build elfogadja mind a tls-cipher, mind a tls-ciphersuites beállítást. Az mbed TLS-szel készült buildben egyáltalán nincs TLS 1.3 csomagválasztás, és a 2.6 kézikönyv a tls-ciphersuites beállítást OpenSSL-opcióként jelöli. Ha a szervert más backenddel építik újra, ugyanaz a profil megváltoztathatja a viselkedését anélkül, hogy a konfiguráció egyetlen sora megváltozna.

Amíg itt van, futtassa a openvpn --show-tls parancsot, és őrizze meg a kimenetet. Ez az a leltár, amelyhez később hasonlítani fog, és olcsó rögzíteni, mielőtt bárki elkezdi szerkeszteni a profilokat.

Írja a bannert és a listát a változásjegybe, ne egy csevegőablakba. Amikor két ember vitatkozik azon, hogy egy kliens hat hét múlva tud-e majd csomagot kínálni, a rögzített kimenet egyetlen sorban eldönti.

Tartsa a verziókorlátokat külön a rejtjeles listáktól

A 2.6 kézikönyvben ezek három vezérlőelem, nem egy:

  • tls-cipher beállítja a rejtjelezési szabályt a TLS 1.2 és korábbi verziókhoz, és átadja az OpenSSL rejtjeles listájának;
  • tls-ciphersuites kiválasztja a TLS 1.3 csomagokat;
  • tls-version-min és tls-version-max korlátozza azokat a protokollverziókat, amelyeket a kapcsolat használhat.

Tehát egy gondosan megnyírt TLS 1.3 csomaglista semmit sem bizonyít arról, hogy egy régebbi verzió még engedélyezett. Ha a követelmény «csak TLS 1.3», akkor a verzió alsó korlátja hordozza, és a csomaglista csak az ezen a korláton belüli választásokat szűkíti:

tls-version-min 1.3
tls-ciphersuites TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256

Ez a pár két feladatot lát el. Az egyik sor törlése a másikat kevesebbet kényszeríti ki, mint gondolná, és pontosan ez az a hiba, amelynek elkapására ez az egész ellenőrzés létezik.

Az adatcsatorna a negyedik vezérlő. data-ciphers az alagúton belüli szimmetrikus rejtjelezést egyezteti, és az eredménye semmit sem mond a vezérlőcsatorna TLS-verziójáról. Az AES-256-GCM látványa a munkamenet-összegzésben egyik irányban sem bizonyíték a TLS 1.3-ra.

Olvassa a show-tls-t helyi leltárként

--show-tls felsorolja azokat a csomagokat, amelyeket az a kriptográfiai könyvtár támogat, amelyhez ez a bináris fájl linkelve van, preferenciális sorrendben. Ez nem az átjáró jelentése. A kézikönyv kifejezetten kimondja, hogy a lista a helyi könyvtárból származik, ami azt jelenti, hogy egy OpenSSL 3.x-szel rendelkező laptop és egy régebbi builddel rendelkező router különböző listákat nyomtat, miközben ugyanazzal a szerverrel beszél.

EvidenceWhat it actually describes
--show-tls outputCapabilities of this client build and its library
Profile directivesWhat this attempt is allowed to offer
Session log lineWhat this one negotiation selected

Tegyük fel, hogy egy kliens támogatja az A, B és C csomagokat, és egy munkamenet a B-t választja. Ez semmit sem állít arról, hogy a szerver engedélyezi-e az A-t vagy a C-t, és arról sem, hogy a B az egyetlen engedélyezett választása. Tartsa külön a három sort, és a legtöbb zavaros TLS-szál magától megoldódik.

A leltárt mégis érdemes megtartani. Amikor egy munkamenet meghiúsul, a könyvtár listájának összevetése a profil listájával megmutatja, volt-e egyáltalán esélye a kliensnek felkínálni azt, amit a szerver akart. Azt is megmutatja, hogy egy backend-változás csendben eltávolította-e a TLS_CHACHA20_POLY1305_SHA256 csomagot abból a készletből, amelyre a régebbi kliensek támaszkodnak — az a fajta regresszió, amely néhány felhasználó csatlakozási kudarcaként jelenik meg, miközben mindenki más semmit sem vesz észre.

Kérdezze az átjárót valamiről, amire tud válaszolni

Ha Ön üzemelteti a szolgáltatást, a futó példány tényleges konfigurációját vizsgálja meg, ne egy lemezen lévő fájlt. Lehet, hogy az OpenVPN más --config útvonallal indult, beépítéseket húz be, és a szerkesztés óta nem indították újra. A futó démon szabályzata az, amivel a kliensek találkoznak.

Ha nem Ön üzemelteti, kérje meg az üzemeltetőt a támogatott klienskövetelményekre vagy egy körülhatárolt elfogadási tesztre. Egy elutasított kísérlet nem automatikusan elutasított csomag: egy verzió alsó korlát, a remote-cert-tls-höz hasonló tanúsítvány-identitás-ellenőrzések, vagy a tls-auth és a tls-crypt közötti eltérés még a csomagválasztás előtt véget vethet a cserének. Olvassa el a szerver hibáját, mielőtt módosítja a kliens listáját, mert a «handshake failed» négy különböző okot takar, és ezek közül csak egy a rejtjel-eltérés.

A openssl s_client VPN-portra irányítása sem reprodukálja a kérdést. A vezérlőcsatorna az OpenVPN saját keretezésén belül fut, ezért egy nyers TLS-szonda más protokollt tesztel egy olyan porton, amely valami mást vár. A belőle levont bármilyen következtetés a szondáról szól, nem az alagútról.

Rögzítsen két eredményt, és tartsa őket külön

Egy friss engedélyezett munkamenet létrehoz egy vezérlőcsatorna-sort, amely megnevezi a protokollverziót és a kiválasztott rejtjelet, valamint egy külön adatcsatorna-sort, amely az alagút rejtjelét nevezi meg. Rögzítse mindkettőt a kliensverzióval és a profil nevével, és jegyezze fel, melyik szerverpéldány válaszolt:

openvpn --config office.ovpn --verb 4 2>&1 | tee session.txt

Utána abból a fájlból olvassa ki a két sort, ne emlékezetből. A pár a bizonyíték; egy csomagnév önmagában preferencia, és a verziókorlát külön állítás arról, hogy a szerver mit utasít el.

Végezze el az ellenőrzéseket ebben a sorrendben. Erősítse meg a buildet és a backendet a --version paranccsal. Rögzítse a --show-tls kimenetét, mielőtt bármit megváltoztat. A szükséges verzió alsó korlátját a csomaglistától külön mondja ki. Erősítse meg a futó példány tényleges szabályzatát annak tulajdonosával. Figyeljen meg egy engedélyezett munkamenetet, és ha a terv engedi, egy elutasított régebbi verziós kísérletet. Rögzítse a vezérlőcsatorna és az adatcsatorna eredményeit külön megállapításként.

Ha egy szükséges kliens nem tud megfelelni egy új minimumnak, hozza meg ezt az áttelepítési vagy kivételi döntést kifejezetten, ahelyett hogy csendben leszállítana egy nem kapcsolódó elfogadási szabályt, hogy a bevezetés késznek tűnjön.

Kapcsolódó cikkek