OpenVPN ilma kliendisertifikaadita: serveripoliitika, mitte profiil

Kustutate sertifikaadi- ja võtmeread, annate profiili üle ning ühendus ebaõnnestub endiselt sertifikaadiveaga. Profiil ei olnud kunagi see, mis seda nõuet kehtestas. Server otsustab, kas kliendisertifikaat on kohustuslik, ja ükski kliendipoolne muudatus ei kaubelda seda ära. Seega on parandus serveripoliitika muutmine, mis tehakse teadlikult, ning kõik sellest sõltuv värskendatakse samas käigus.

Profiil ei ole poliitika

Community OpenVPN 2.6 tuleb kohustuslike kliendisertifikaatidega, sest verify-client-cert on vaikimisi require. Selle seadmine väärtusele none lõpetab sertifikaadi nõudmise ja annab kliendi autentimise üle sellele kasutajanime ja parooli korraldusele, mida server juba kasutab. Vanemad juhendid haaravad client-cert-not-required järele, mis on sama idee vananenud kirjapilt, seega kasutage direktiivi, mida teie paigaldatud versioon dokumenteerib. Igal juhul toimub muudatus serveris ja ükski kliendiprofiil ei saa seda teha.

Allpool olev fragment on kogu serveripoolne muudatus ja iseenesest ei ole see toimiv autentimiskonfiguratsioon. verify-client-cert none eemaldab sertifikaadinõude, samas kui username-as-common-name teeb konto nimest identiteedi, mida näevad hilisemad tagasikutsumised ja iga kliendi failid. Kumbki rida ei kontrolli parooli, seega peab verifikaator siiski olemas olema.

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

See verifikaator on plugin või skript, mida käivitab auth-user-pass-verify, ja see peab olema paigas enne, kui ülalolevad read midagi tähendavad. Järjekorra ümberpööramine annab teile akna, milles server ei küsi sertifikaati ega kontrolli ühtegi kontot.

Mis serverit endiselt kontrollib

Kliendisertifikaadi ärajätmine ei tähenda TLS-i ärajätmist. Server hoiab oma sertifikaati ja võtit ning klient hoiab CA-usaldust ja hostinime kontrolle, mis takistavad tal petisega rääkida. remote-cert-tls server või CA-kimbu eemaldamine sellepärast, et kliendil pole enam sertifikaati, on levinud ja tõsine vale lugemine, ja 2.6 viide ütleb selgesõnaliselt, et kaks suunda on sõltumatud. Üks tõestab serverit kliendile; teine tõestab klienti serverile.

Profiil võib kanda ka tls-auth või tls-crypt plokki. See on jagatud juhtkanali võti, millel on oma levitus- ja rotatsioonitsükkel, seega ilma sertifikaadi- või võtmereadadeta fail ei ole automaatselt avaldamiseks ohutu. Käsitlege seda saladusena, kuni olete selle läbi lugenud.

Toimivast profiilist kopeeritud sertifikaadifail ei tõesta iseenesest midagi; omamine tähendab sellele vastava privaatvõtme hoidmist, mida sertifikaadiga autentiv kasutuselevõtt kontrollib. Fail, mis sisaldab sertifikaati, ei ole fail, millega saab autentida.

Mida peab verifikaator tegema

Kui sertifikaadinõue on eemaldatud, toetub kõik verifikaatorile: plugin või skript, mida käivitab auth-user-pass-verify. See peab tagasi lükkama kehtetud mandaadid, tagasi lükkama keelatud või kõlbmatud kontod ja sulguma turvaliselt, kui ta ei pääse oma taustasüsteemile ligi. username-as-common-name lülitatakse sageli kõrvale ja see muudab identiteeti, mida näevad hilisemad tagasikutsumised ja iga kliendi konfiguratsioonifailid. See ei kontrolli parooli ega tee kõlbmatut kontot kõlblikuks. Need on eraldi tööd ja nende segamine on viis, kuidas migratsioon läbib õnneliku tee testi ja ebaõnnestub oma esimeses tõelises intsidendis.

Testige negatiivseid juhtumeid sama hoolikalt kui positiivset. Profiil, mis näitab parooliküsimust, tõestab ainult seda, et klient suudab küsimuse joonistada, samas kui server, mis võtab vastu vale parooli, tõestab midagi tunduvalt hullemat. Lisage testikomplekti keelatud konto ja aegunud mandaat, mitte ainult halb parool.

Muutke poliitikat, profiili ja vastendust koos

Kooskõlastage kolm asja: serveridirektiiv, kliendiprofiil ja iga kliendi identiteedi vastendus. Muutke neid eraldi ja kliendid ebaõnnestuvad enne kontrolli või ühenduvad nimega, mida administraator ei oodanud, mis on hullem, sest see näeb välja nagu edu. Ühendust, mis õnnestub vale identiteedi all, on raskem märgata kui seda, mis ebaõnnestub.

Hoidke selle tee jaoks kahte testkontot, üks kehtiv ja üks teadaolevalt halb, ning kasutage mõlemat pärast iga verifikaatori muudatust. Kehtiv konto tõestab õnnelikku teed ja identiteedi vastendust; halb tõestab, et tagasilükkamine töötab endiselt. Kumbki test ei ütle teile midagi kõlblikkusreeglite kohta, seega lisage konto, mis tuleks poliitilistel põhjustel tagasi lükata, kui kasutuselevõtul need on. Käivitage kõik kolm pärast iga muudatust, sest verifikaator, mis hakkab kõike vastu võtma, näeb välja täpselt nagu toimiv sisselogimine.

Kirjutage üles, milliseid autentimismeetodeid server tegelikult vastu võtab, mitte milliseid profiil vihjab. See kirje vastab küsimusele, mida inimesed ikka küsivad, nimelt kes saab selle teenusega ühenduda. See elab üle ka järgmise administraatori, kes muidu avastaks selle paketisalvestusest uuesti.