OpenVPN bez klijentskog sertifikata: serverska politika, a ne profil

Obrišete redove za sertifikat i ključ, predate profil, a veza se i dalje prekida sa greškom sertifikata. Profil nikada nije bio ono što nameće taj zahtev. Server odlučuje da li je klijentski sertifikat obavezan, i nijedna izmena na strani klijenta to ne pregovara. Dakle, popravka je promena serverske politike, napravljena namerno, uz ažuriranje svega što od nje zavisi u istom prolazu.

Profil nije politika

Community OpenVPN 2.6 dolazi sa obaveznim klijentskim sertifikatima, jer verify-client-cert po defaultu ima vrednost require. Postavljanje na none zaustavlja zahtev za sertifikatom 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, zastarelim pravopisom iste ideje, pa koristite direktivu koju dokumentuje vaša instalirana verzija. U svakom slučaju promena se dešava na serveru i nijedan klijentski profil je ne može izvesti.

Fragment ispod je cela promena na strani servera i sam po sebi nije radna konfiguracija autentikacije. verify-client-cert none uklanja zahtev za sertifikatom, dok username-as-common-name čini ime naloga identitetom koji vide kasniji povratni pozivi i datoteke pojedinačnog klijenta. Nijedan red ne proverava 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 mestu pre nego što ijedan od gornjih redova išta znači. Obrnuti redosled vam daje prozor u kojem server ne traži sertifikat i ne proverava nijedan nalog.

Šta još proverava server

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

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

Datoteka sertifikata kopirana iz radnog profila sama po sebi ništa ne dokazuje; posedovanje znači držanje privatnog ključa koji joj odgovara, što proverava implementacija sa autentikacijom po sertifikatu. Datoteka koja sadrži sertifikat nije datoteka kojom se može autentifikovati.

Šta verifikator mora da radi

Kad se zahtev za sertifikatom ukloni, sve počiva na verifikatoru: dodatku ili skripti koju pokreće auth-user-pass-verify. Mora da odbija nevažeće akreditive, odbija onemogućene ili nepodobne naloge i zatvoreno se prekida kad ne može da dosegne svoj backend. username-as-common-name se često uključuje uz to i menja identitet koji vide kasniji povratni pozivi i konfiguracione datoteke pojedinačnog klijenta. Ne proverava lozinku i ne čini nepodoban nalog podobnim. To su odvojeni poslovi, a njihovo mešanje je način na koji migracija prođe test srećnog 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 da nacrta upit, dok server koji prihvati pogrešnu lozinku dokazuje nešto znatno gore. Dodajte onemogućen nalog i istekle akreditive u testni skup, a ne samo lošu lozinku.

Menjajte politiku, profil i mapiranje zajedno

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

Držite dva testna naloga za taj put, jedan valjan i jedan poznato loš, i koristite oba nakon svake promene verifikatora. Valjan nalog dokazuje srećan put i mapiranje identiteta; loš dokazuje da odbijanje još radi. Nijedan test ne govori ništa o pravilima podobnosti, pa dodajte nalog koji bi trebalo da bude odbijen iz političkih razloga ako ih implementacija ima. Pokrenite sva tri nakon svake promene, jer verifikator koji počne da prihvata sve izgleda tačno kao radna prijava.

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