OpenVPN be kliento sertifikato: serverio politika, o ne profilis

Ištrinate sertifikato ir rakto eilutes, perduodate profilį, o ryšys vis tiek nepavyksta su sertifikato klaida. Profilis niekada nebuvo tai, kas vykdė šį reikalavimą. Serveris nusprendžia, ar kliento sertifikatas yra privalomas, ir joks kliento pusės pakeitimas to nesuderina. Taigi pataisa yra serverio politikos pakeitimas, atliktas sąmoningai, ir viskas, kas nuo jo priklauso, atnaujinama tame pačiame etape.

Profilis nėra politika

Community OpenVPN 2.6 pateikiamas su privalomais kliento sertifikatais, nes verify-client-cert pagal numatytuosius nustatymus yra require. Būtent nustatymas į none sustabdo sertifikato reikalavimą ir perduoda kliento autentifikavimą tam vartotojo vardo ir slaptažodžio sprendimui, kurį serveris jau naudoja. Senesni vadovai siekia client-cert-not-required, pasenusios tos pačios idėjos rašybos, todėl naudokite direktyvą, kurią dokumentuoja jūsų įdiegta versija. Bet kuriuo atveju pakeitimas atliekamas serveryje, ir joks kliento profilis negali jo atlikti.

Toliau pateiktas fragmentas yra visas serverio pusės pakeitimas, ir pats savaime jis nėra veikianti autentifikavimo konfigūracija. verify-client-cert none pašalina sertifikato reikalavimą, o username-as-common-name padaro paskyros vardą tuo tapatumu, kurį mato vėlesni atgaliniai iškvietimai ir kiekvieno kliento failai. Nė viena eilutė netikrina slaptažodžio, todėl tikrintuvas vis tiek turi egzistuoti.

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

Tas tikrintuvas yra papildinys arba scenarijus, valdomas auth-user-pass-verify, ir jis turi būti vietoje anksčiau, nei bet kuri aukščiau esanti eilutė ką nors reiškia. Apvertus tvarką gaunamas langas, kuriame serveris neprašo sertifikato ir netikrina jokios paskyros.

Kas vis dar tikrina serverį

Atsisakymas kliento sertifikato nereiškia atsisakymo TLS. Serveris išlaiko savo sertifikatą ir raktą, o klientas išlaiko CA pasitikėjimą ir pagrindinio kompiuterio vardo patikras, kurios neleidžia jam kalbėtis su apsišaukėliu. remote-cert-tls server ar CA paketo pašalinimas todėl, kad klientas nebeturi sertifikato, yra dažnas ir rimtas neteisingas skaitymas, o 2.6 nuoroda aiškiai nurodo, kad dvi kryptys yra nepriklausomos. Viena įrodo serverį klientui; kita įrodo klientą serveriui.

Profilis taip pat gali turėti tls-auth arba tls-crypt bloką. Tai bendras valdymo kanalo raktas su savo platinimo ir rotacijos ciklu, todėl failas be sertifikato ar rakto eilučių nėra automatiškai saugus skelbti. Traktuokite jį kaip paslaptį, kol jį perskaitysite.

Sertifikato failas, nukopijuotas iš veikiančio profilio, pats savaime nieko neįrodo; turėjimas reiškia turėti jį atitinkantį privatų raktą, ką tikrina sertifikatu autentifikuojamas diegimas. Failas, kuriame yra sertifikatas, nėra failas, kuriuo galima autentifikuotis.

Ką turi daryti tikrintuvas

Pašalinus sertifikato reikalavimą, viskas remiasi tikrintuvu: papildiniu arba scenarijumi, valdomu auth-user-pass-verify. Jis turi atmesti negaliojančius prisijungimo duomenis, atmesti išjungtas ar netinkamas paskyras ir užsidaryti, kai negali pasiekti savo backend. username-as-common-name dažnai įjungiamas šalia, ir jis pakeičia tapatumą, kurį mato vėlesni atgaliniai iškvietimai ir kiekvieno kliento konfigūracijos failai. Jis netikrina slaptažodžio ir nepadaro netinkamos paskyros tinkama. Tai atskiri darbai, ir jų sumaišymas yra būdas, kuriuo migracija praeina laimingosios kelio testą ir žlunga pirmame tikrame incidente.

Tikrinkite neigiamus atvejus taip pat kruopščiai kaip teigiamą. Profilis, rodantis slaptažodžio užklausą, įrodo tik tai, kad klientas moka nupiešti užklausą, o serveris, priimantis neteisingą slaptažodį, įrodo kur kas ką blogesnio. Į testų rinkinį įtraukite išjungtą paskyrą ir pasibaigusius prisijungimo duomenis, ne tik blogą slaptažodį.

Keiskite politiką, profilį ir susiejimą kartu

Suderinkite tris dalykus: serverio direktyvą, kliento profilį ir kiekvieno kliento tapatumo susiejimą. Keiskite juos atskirai ir klientai žlunga prieš patikrą arba jungiasi vardu, kurio administratorius nesitikėjo, o tai dar blogiau, nes atrodo kaip sėkmė. Ryšį, kuris pavyksta su neteisingu tapatumu, pastebėti sunkiau nei tą, kuris žlunga.

Šiam keliui laikykite dvi bandomąsias paskyras, vieną galiojančią ir vieną žinomai blogą, ir naudokite abi po bet kurio tikrintuvo pakeitimo. Galiojanti paskyra įrodo laimingąjį kelią ir tapatumo susiejimą; blogoji įrodo, kad atmetimas vis dar veikia. Nė vienas testas nieko nepasako apie tinkamumo taisykles, todėl pridėkite paskyrą, kuri turėtų būti atmetama dėl politikos priežasčių, jei diegimas jų turi. Paleiskite visus tris po kiekvieno pakeitimo, nes tikrintuvas, pradėjęs priimti viską, atrodo lygiai kaip veikiantis prisijungimas.

Užrašykite, kokius autentifikavimo metodus serveris iš tikrųjų priima, o ne kokius siūlo profilis. Tas įrašas atsako į klausimą, kurį žmonės nuolat užduoda, būtent kas gali prisijungti prie šios paslaugos. Jis taip pat pergyvena kitą administratorių, kuris kitu atveju vėl jį atrastų iš paketų įrašymo.