Az OpenVPN szerint az ncp-disable ismeretlen: mi váltotta fel?

A kliens opcióhibával indul, amely az ncp-disable beállítást nevezi meg, pedig a profil a korábbi gépen működött. Ez az üzenet nem azt jelenti, hogy a beállítás el van gépelve, vagy hogy a titkosítás elromlott. Azt jelenti, hogy az előtted lévő bináris egyáltalán nem ismeri az utasítást, és erre két nagyon különböző ok van. Melyik érvényes, eldönti, a profilt szerkeszted-e vagy a klienst cseréled.

A hiba újabb bináristól is származhat

Az ismeretlen beállítás hibája az értelmezőről szól, nem az alagútról. Az OpenVPN 2.4 tárgyalható titkosítási paramétereket adott hozzá, a 2.5 elavulttá nyilvánította az ezeket kikapcsoló kapcsolót, a 2.6 pedig teljesen eltávolította. Ezért a 2.3 vagy 2.4 számára írt profil elbukik a jelenlegi kliensen, még akkor is, ha semmi sem változott a fájlban. A panaszos verzió újabb, nem régebbi.

Derítse ki, melyik végrehajtható fájl állította elő az üzenetet, mielőtt bármit szerkesztene. Az asztali kliens saját motort hoz magával, míg a külön telepített parancssori bináris saját verzióval rendelkezik. A kettő ugyanazon a gépen is eltérhet.

openvpn --version ezt a tesztelt binárisra nézve tisztázza. Előfordulhat, hogy egy grafikus kliens nem jeleníti meg ezt a parancsot; ebben az esetben olvassa el a névjegy képernyőjét vagy a beágyazott könyvtár verzióját.

Mit szabályozott valójában a beállítás

Az utasítás kikapcsolta a kriptográfiai paraméterek tárgyalását, ezért mindkét vég visszaesett a cipher beállítás által vezérelt régebbi kiválasztási viselkedésre. Soha nem kapcsolta ki a titkosítást, és soha nem alakította az alagutat egyszerű szöveggé. Biztonsági kapcsolóként olvasni az első rossz fordulat, és olyan változásokhoz vezet, amelyek rosszabbá teszik a kapcsolatot a jobb helyett.

Ha létezik tárgyalás, az egyenértékű kérdés az, hogy mely rejtjeleket hajlandó használni mindkét fél. Ez szabályzat kérdése, és a szabályzat a 2.5-től a data-ciphers beállításban él.

A régebbi ncp-ciphers név a 2.4-hez tartozik. A két név keverése a felek között az egyirányú tárgyalási hibák gyakori forrása. Az a profil, amely mindkettőt hordozza, olyan profil, amelyet két ember különböző időpontokban szerkesztett.

A szabályzatot cserélje, ne a helyesírást

Állítsa be a data-ciphers értéket mindkét félen egy szándékolt közös választással, és tartsa a listát elég rövidnek ahhoz, hogy egy ellenőrző át tudja gondolni. Egyetlen önkényes sor megváltoztatása nem bizonyít semmit; az eredmény a két lista metszetétől és attól függ, mit támogat a TLS verem. Erősítse meg a felek egyetértését a tárgyalt eredmény olvasásával a konfiguráció helyett. Ezután írja mindkét listát az üzembe helyezési nyilvántartásba, hogy a következő változás ismert állapotból induljon.

Frissítse a profilt azon keresztül, aki birtokolja. Egy figyelmen kívül hagyó beállítás hozzáadása egy elavult utasítás elrejtésére nyitva hagyja a szabályzat kérdését.

Ha egy régebbi fél valóban igényel kompatibilitási kezelést, szűkítse azt arra az üzembe helyezésre. Az elavult viselkedés globális visszaállítása nem előfeltétele a modern felek összekapcsolásának. A kivételnek meg kell neveznie a felet, amelyre létezik.

Két sor, amely rejtjellistának látszik, de nem az

Két rejtjelsor egymásra rakása sem állítja vissza a tárgyalást, és az eredmény egy olyan profil, amely listának látszik, miközben egyetlen értékként viselkedik. Az egyik sorban AES-256-CBC, a következőben CBC szerepel, ez gyakori próbálkozás. A CBC önmagában üzemmódot nevez meg, nem algoritmust, ezért az értelmező az egyik helyen elfogadhatja, a következőben elutasíthatja. Az ismételt cipher utasítások ugyanazt a beállítást kétszer adják meg a jelöltek halmozása helyett.

Az elfogadott neveket a cél binárison openvpn --show-ciphers segítségével ellenőrizze, ne pedig egy másik ághoz írt útmutatóból másoljon listát. A lista kiadások között változik. Az egyik ágban érvényes név nem feltétlenül érvényes a másikban.

Ha a cél teljesítmény-összehasonlítás volt, jegyezze fel az algoritmusokat és a terhelést. A CBC-re váltás nem a titkosítás hiányának mérése.

Ellenőrizze, mit tárgyalt valójában a kapcsolat

Hozzon létre egy friss kapcsolatot, és olvassa el a napló adatcsatorna-sorát, amely megnevezi a használt rejtjelet. A vezérlőcsatorna-készlet külön dől el, ezért a fájlban engedélyezett lista csak azt mutatja, mit kínáltak fel. Amikor a két fél olyasmit választott, amire nem számított, a listák a keresendő hely, nem az alagút interfésze. Bármilyen változás után erősítse meg az eredményt egy második kapcsolaton, mert egy újraindítás újrahasználhat egy gyorsítótárazott munkamenetet.

Tartsa a tárgyalt eredményt az üzembe helyezési nyilvántartásban a profilverzió mellett. Ez az a tény, amely megválaszolja a következő kérdést arról, melyik rejtjel védi valóban a forgalmat.