OpenVPN bez klijentskog certifikata: serverska politika, a ne profil

Obrišete redove za certifikat i ključ, predate profil, a veza se i dalje prekida s greškom certifikata. Profil nikada nije bio ono što nameće taj zahtjev. Server odlučuje je li klijentski certifikat obavezan, i nijedna izmjena na strani klijenta to ne pregovara. Dakle, popravka je promjena serverske politike, napravljena namjerno, uz ažuriranje svega što o njoj ovisi u istom prolazu.

Profil nije politika

Community OpenVPN 2.6 dolazi s obaveznim klijentskim certifikatima, jer verify-client-cert po defaultu ima vrijednost require. Postavljanje na none zaustavlja zahtjev za certifikatom i predaje autentikaciju klijenta onom rasporedu korisničkog imena i lozinke koji server već koristi. Stariji vodiči posežu za client-cert-not-required, zastarjelim pravopisom iste ideje, pa koristite direktivu koju dokumentuje vaša instalirana verzija. U svakom slučaju promjena se događa na serveru i nijedan klijentski profil je ne može izvesti.

Fragment ispod je cijela promjena na strani servera i sam po sebi nije radna konfiguracija autentikacije. verify-client-cert none uklanja zahtjev za certifikatom, dok username-as-common-name čini ime računa identitetom koji vide kasniji povratni pozivi i datoteke pojedinačnog klijenta. Nijedan red ne provjerava lozinku, pa verifikator i dalje mora postojati.

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

Taj verifikator je dodatak ili skripta koju pokreće auth-user-pass-verify i mora biti na mjestu prije nego ijedan od gornjih redova išta znači. Obrnuti redoslijed daje vam prozor u kojem server ne traži certifikat i ne provjerava račun.

Šta još provjerava server

Napuštanje klijentskog certifikata ne znači napuštanje TLS-a. Server zadržava svoj certifikat i ključ, a klijent zadržava povjerenje u CA i provjere imena hosta koje ga sprječavaju da razgovara s prevarantom. Uklanjanje remote-cert-tls server ili CA paketa zato što klijent više nema certifikat često je i ozbiljno pogrešno čitanje, a referenca za 2.6 izričito kaže da su dva smjera nezavisna. Jedan dokazuje server klijentu; drugi dokazuje klijenta serveru.

Profil može sadržavati i blok tls-auth ili tls-crypt. To je zajednički ključ kontrolnog kanala s vlastitim ciklusom distribucije i rotacije, pa datoteka bez redova za certifikat ili ključ nije automatski sigurna za objavljivanje. Tretirajte je kao tajnu dok je ne pročitate.

Datoteka certifikata kopirana iz radnog profila sama po sebi ništa ne dokazuje; posjedovanje znači držanje privatnog ključa koji joj odgovara, što provjerava implementacija s autentikacijom po certifikatu. Datoteka koja sadrži certifikat nije datoteka kojom se može autentificirati.

Šta verifikator mora raditi

Kad se zahtjev za certifikatom ukloni, sve počiva na verifikatoru: dodatku ili skripti koju pokreće auth-user-pass-verify. Mora odbijati nevažeće vjerodajnice, odbijati onemogućene ili nepodobne račune i zatvoreno se prekidati kad ne može dosegnuti svoj backend. username-as-common-name se često uključuje uz to i mijenja identitet koji vide kasniji povratni pozivi i konfiguracijske datoteke pojedinačnog klijenta. Ne provjerava lozinku i ne čini nepodoban račun podobnim. To su odvojeni poslovi, a njihovo miješanje je način na koji migracija prođe test sretnog puta i padne na prvom stvarnom incidentu.

Testirajte negativne slučajeve jednako pažljivo kao pozitivni. Profil koji prikazuje upit za lozinku dokazuje samo da klijent može nacrtati upit, dok server koji prihvati pogrešnu lozinku dokazuje nešto znatno gore. Dodajte onemogućen račun i istekle vjerodajnice u testni skup, a ne samo lošu lozinku.

Mijenjajte politiku, profil i mapiranje zajedno

Uskladite tri stvari: serversku direktivu, klijentski profil i mapiranje identiteta po klijentu. Mijenjajte ih odvojeno pa klijenti padnu prije verifikacije ili se povežu pod imenom koje administrator nije očekivao, što je gore jer izgleda kao uspjeh. Veza koja uspije pod pogrešnim identitetom teže se primjećuje od one koja padne.

Držite dva testna računa za taj put, jedan valjan i jedan poznato loš, i koristite oba nakon svake promjene verifikatora. Valjan račun dokazuje sretan put i mapiranje identiteta; loš dokazuje da odbijanje još radi. Nijedan test ne govori ništa o pravilima podobnosti, pa dodajte račun koji bi trebao biti odbijen iz političkih razloga ako ih implementacija ima. Pokrenite sva tri nakon svake promjene, jer verifikator koji počne prihvaćati sve izgleda točno kao radna prijava.

Zabilježite koje metode autentikacije server zapravo prihvaća, a ne koje profil predlaže. Taj zapis odgovara na pitanje koje ljudi stalno postavljaju, a to je ko se može povezati na ovu uslugu. On nadživljava i sljedećeg administratora, koji bi ga inače ponovno otkrio iz snimanja paketa.