Egy évek óta működő profil hirtelen nem indul el, és az üzenet olyan utasítást nevez meg, amelyet senki nem emlékszik, hogy hozzáadott volna: key-method. A következő találat azt javasolja, hogy kompatibilitás miatt adja hozzá a key-method 2-t, ami egy másik korszak tanácsa. A sort elutasító elemző jelenlegi, és egyáltalán nincs ilyen opciója. A sor eltávolítása rendbe hozza az indítást, és semmit nem változtat azon, hogyan védi a két fél a munkamenetet.

Pontosan ez a rés a profil tartalma és a protokoll tényleges működése között a teljes téma, és ez magyarázza a többi szerkesztést is, amelyet az emberek ugyanakkor végeznek. Azt is megmagyarázza, miért érkeznek ezek a szerkesztések általában egy csomagban.

A tünet elemzési hiba, nem kézfogási hiba

Az opciókat az első csomag elküldése előtt olvassák be. Az ismeretlen utasítást tartalmazó profil ebben a szakaszban elbukik, így a folyamat soha nem éri el a hálózatot, és soha nem okoz kézfogási hibát. A szöveg általában megnevezi az opciót és a fájlt, ami ezt az egyik legkönnyebben hozzárendelhető hibává teszi. Csomag, útvonal és tűzfal nincs benne érintve.

openvpn --config /etc/openvpn/client/office.ovpn --verb 3 --log /tmp/parse.log
grep -n 'Options error' /tmp/parse.log

Ha az üzenet megnevezi az utasítást, a diagnózis kész: a fájl olyasmit tartalmaz, amit ez a build nem fogad el. Ha az üzenet inkább egy fájlútvonalat nevez meg, a probléma hiányzó include vagy kulcs, ami ugyanannak az indítási szakasznak egy másik része.

Amit nem szabad ebből következtetni: hogy a kliensnek vagy a szervernek régebbi protokollmódra van szüksége. Az elemzési hiba szókészleti probléma a fájl és a bináris között, a bináris pedig ebben az esetben egyszerűen ejtett egy szót a szókészletéből.

Az utasítás és az átviteli formátum két különböző dolog

A régi key-method opció azt választotta ki, hogyan kereteződik a TLS kulcscsere, a modern csere pedig az a többcsomagos módszer, amelyet ez az opció egykor kért. Az opció azért tűnt el, mert már semmit nem választott ki; az általa megnevezett formátum lett az egyetlen. A sor eltávolítása tehát ugyanazzal a keretezéssel hagyja a munkamenetet, mint korábban. Szöveges szerkesztés ezen egyik irányban sem változtathat.

Ezért a rossz javítás egy régi bináris visszahozása a 2-es módszer „helyreállításához”. Semmit nem állít helyre, csak egy régebbi elemzőt régebbi alapértékekkel, és elviszi a később érkezett javításokat. Ugyanez a logika érvényes a tanúsítvány-ellenőrzés vagy a rejtjelista gyengítésére, abban a reményben, hogy a kapcsolat visszatér.

Hasznos ellenőrzés a verzió és az elemzett konfiguráció, nem a szó jelenléte a fájlban:

openvpn --version | head -n 1
grep -rn 'key-method' /etc/openvpn/ 2>/dev/null

Mit kell eltávolítani, és melyik fájlból

Azt a fájlt szerkessze, amelyet a futó folyamat ténylegesen olvas, és csak azt. Csomagolt rendszereken ez általában a kliens vagy szerver könyvtárában lévő profil, amelyet az unit megnevez, nem pedig egy másolat az otthoni könyvtárában, amelyet referenciaként tart. Az előállított profil sablonból is újraépülhet, ezért a csak a telepített példányon végzett módosítás a következő provisioning futás után visszatér.

Törölje az elavult sort, és hagyja békén a végpontot, a tanúsítványokat, a rejtjelpolitikát és a vezérlőcsatorna beállításait. Ezek támogatott opciók, amelyekre a folyamatnak szüksége van, és nincsenek érintve az elemzési hibában. Ha ugyanaz a profil más, Ön által nem ismert utasításokat is tartalmaz, ellenőrizze mindegyiket a futtatott verzióhoz képest, ahelyett hogy egy csoportjukat törölné, amíg a folyamat el nem indul.

Ezután indítsa el a szándékolt példányt, és olvassa el az indítási kimenetét. A tiszta indítás jelen lévő figyelővel megerősíti, hogy ez a szakasz befejeződött; az utána következő kliens teszt más kérdésre válaszol.

Egy elutasított profil és egy elutasított kliens hasonlóan néz ki

Két hiba hasonló támogatási szálakat szül, és eltérő bizonyítékot igényel. Az a szerver, amely elutasítja a saját konfigurációját, soha nem indul el, így egyetlen kliens sem tud csatlakozni hozzá. Az a szerver, amely szépen elindul és egy klienst elutasít, fut, és a naplója tartalmazza az okot: tanúsítványprobléma, egy tolt opció, amelyet a kliens nem fogad el, rejtjel-eltérés.

Az eltávolított opció nem diagnózis a második esetre, és utána nyúlni ugyanazt az órát kétszer pazarolja el. Ha a kliens naplója a szerver elutasítását mutatja, olvassa el azt az elutasítást; ha helyi hibát mutat, a kliens profilja a vizsgálandó fájl. Egy már nem létező utasítás után nyúlni mindkét vizsgálatot ugyanannyival késlelteti.

Kompatibilitási kérdések, amelyekre a sor soha nem válaszolt

Az ezzel az utasítással terjedő profilok általában egy adott platformról szóló történetet hordoznak, és a történet túléli a technikai okot. A mobil vagy asztali kliensnek továbbra is szüksége van egy teljes, támogatott profilra: megbízható tanúsítványláncra, mindkét vég által elfogadott adatrejtjelre, mindkét vég által megvalósított vezérlőcsatorna-módra, és arra, hogy a kliens buildje egyetlen utasítást se utasítson el. Ezek egyikét sem a régi key-method sor megléte vagy hiánya dönti el.

A tömörítés ugyanilyen formájú, külön szakpolitikai kérdés. A key-method sor eltávolítása semmit nem mond arról, hogy a tömörítési utasítás támogatott-e vagy elfogadható-e a telepítésében, és a két döntést egymástól függetlenül kell meghozni. Több biztonsági szempontból fontos beállítás egyszerre történő törlése addig, amíg valami csatlakozik, az az út, amelyen egy működő profil megmagyarázhatatlanná válik.

Vezessen rövid feljegyzést arról, mit távolított el és miért: az opciót, az azt elutasító verziót és a hibát mutató parancsot. A következő embernek, aki örökli a profilt, pontosan erre a három tényre lesz szüksége, és olcsóbb most leírni őket, mint később rekonstruálni.

Kapcsolódó cikkek