OpenVPN kliens-tanúsítvány nélkül: kiszolgálói irányelv, nem profil

Törli a tanúsítvány- és kulcssorokat, átadja a profilt, és a kapcsolat továbbra is tanúsítványhibával hiúsul meg. A profil soha nem az volt, ami ezt a követelményt érvényesítette. A kiszolgáló dönti el, hogy a kliens-tanúsítvány kötelező-e, és semmilyen kliensoldali szerkesztés nem tárgyalja ezt el. A javítás tehát a kiszolgálói irányelv megváltoztatása, szándékosan végrehajtva, és minden, ami tőle függ, ugyanabban a menetben frissül.

A profil nem az irányelv

A Community OpenVPN 2.6 kötelező kliens-tanúsítványokkal érkezik, mert a verify-client-cert alapértelmezésben require. A none értékre állítás az, ami leállítja a tanúsítvány követelését, és a kliens hitelesítését arra a felhasználónév- és jelszó-elrendezésre bízza, amelyet a kiszolgáló már futtat. A régebbi útmutatók a client-cert-not-required-ra nyúlnak, ugyanannak az ötletnek a régi írásmódjára, ezért használja azt az utasítást, amelyet a telepített verzió dokumentál. Mindkét esetben a változás a kiszolgálón történik, és egyetlen kliensprofil sem tudja végrehajtani.

Az alábbi részlet a teljes kiszolgálóoldali változás, és önmagában nem működő hitelesítési konfiguráció. A verify-client-cert none eltávolítja a tanúsítványkövetelményt, míg a username-as-common-name a fióknevet teszi azzá az identitássá, amelyet a későbbi visszahívások és az ügyfelenkénti fájlok látnak. Egyik sor sem ellenőriz jelszót, ezért továbbra is léteznie kell egy ellenőrzőnek.

verify-client-cert none
username-as-common-name

Az az ellenőrző egy bővítmény vagy egy szkript, amelyet a auth-user-pass-verify vezérel, és a helyén kell lennie, mielőtt bármelyik fenti sor bármit jelent. A sorrend megfordítása olyan ablakot ad, amelyben a kiszolgáló nem kér tanúsítványt, és nem ellenőriz fiókot.

Mi ellenőrzi továbbra is a kiszolgálót

A kliens-tanúsítvány elhagyása nem jelenti a TLS elhagyását. A kiszolgáló megtartja a tanúsítványát és a kulcsát, a kliens pedig megtartja a CA-bizalmat és a gazdanév-ellenőrzéseket, amelyek megakadályozzák, hogy egy csalóval beszéljen. A remote-cert-tls server vagy a CA-csomag eltávolítása azért, mert a kliensnek már nincs tanúsítványa, gyakori és súlyos félreértés, és a 2.6-os hivatkozás egyértelműen kimondja, hogy a két irány független. Az egyik a kiszolgálót bizonyítja a kliensnek; a másik a klienst a kiszolgálónak.

A profil tls-auth vagy tls-crypt blokkot is hordozhat. Ez egy megosztott vezérlőcsatorna-kulcs, saját elosztási és forgatási ciklussal, ezért a tanúsítvány- vagy kulcssorok nélküli fájl nem automatikusan biztonságos közzétételre. Titokként kezelje, amíg el nem olvasta.

Egy működő profilból kimásolt tanúsítványfájl önmagában semmit sem bizonyít; a birtoklás a hozzá illő titkos kulcs birtoklását jelenti, amit egy tanúsítvány-hitelesítésű telepítés ellenőriz. Az a fájl, amely tanúsítványt tartalmaz, nem olyan fájl, amellyel hitelesíteni lehet.

Mit kell tennie az ellenőrzőnek

A tanúsítványkövetelmény eltávolítása után minden az ellenőrzőn nyugszik: egy bővítményen vagy a auth-user-pass-verify által vezérelt szkripten. El kell utasítania az érvénytelen hitelesítő adatokat, el kell utasítania a letiltott vagy nem jogosult fiókokat, és zártan kell meghibásodnia, ha nem éri el a háttérrendszerét. A username-as-common-name gyakran mellette kapcsolódik be, és megváltoztatja azt az identitást, amelyet a későbbi visszahívások és az ügyfelenkénti konfigurációs fájlok látnak. Nem ellenőriz jelszót, és nem tesz jogosulttá egy nem jogosult fiókot. Ezek külön feladatok, és az összekeverésük az az út, ahogyan egy migráció átmegy a boldog út tesztjén, és elbukik az első valódi incidensénél.

A negatív eseteket ugyanolyan gondosan tesztelje, mint a pozitívat. A jelszókérést mutató profil csak azt bizonyítja, hogy a kliens tud kérést rajzolni, míg a rossz jelszót elfogadó kiszolgáló valami sokkal rosszabbat bizonyít. Adjon a tesztkészlethez egy letiltott fiókot és egy lejárt hitelesítő adatot, ne csak egy rossz jelszót.

Az irányelvet, a profilt és a leképezést együtt változtassa

Hangoljon össze három dolgot: a kiszolgálói utasítást, a kliensprofilt és a ügyfelenkénti identitásleképezést. Külön változtassa meg őket, és a kliensek a hitelesítés előtt meghiúsulnak, vagy olyan néven kapcsolódnak, amelyre az adminisztrátor nem számított, ami rosszabb, mert sikernek látszik. A rossz identitás alatt sikerülő kapcsolatot nehezebb észrevenni, mint a meghiúsulót.

Tartson két tesztfiókot ehhez az útvonalhoz, egy érvényeset és egy ismerten rosszat, és mindkettőt használja az ellenőrző minden változása után. Az érvényes fiók bizonyítja a boldog utat és az identitásleképezést; a rossz bizonyítja, hogy az elutasítás továbbra is működik. Egyik teszt sem mond semmit a jogosultsági szabályokról, ezért adjon hozzá egy fiókot, amelyet irányelvi okokból el kellene utasítani, ha a telepítés rendelkezik ilyenekkel. Minden változás után futtassa mindhármat, mert az az ellenőrző, amely elkezd mindent elfogadni, pontosan úgy néz ki, mint egy működő bejelentkezés.

Jegyezze fel, mely hitelesítési módszereket fogad el a kiszolgáló valójában, nem azokat, amelyeket a profil sugall. Ez a feljegyzés válaszol arra a kérdésre, amelyet az emberek folyton feltesznek, mégpedig hogy ki kapcsolódhat ehhez a szolgáltatáshoz. Túléli a következő adminisztrátort is, aki különben újra felfedezné egy csomagrögzítésből.