OpenVPN bez klienta sertifikāta: servera politika, ne profils

Jūs dzēšat sertifikāta un atslēgas rindas, nododat profilu, un savienojums joprojām neizdodas ar sertifikāta kļūdu. Profils nekad nav bijis tas, kas īsteno šo prasību. Serveris izlemj, vai klienta sertifikāts ir obligāts, un neviena klienta puses izmaiņa to neizskaidro sarunās. Tāpēc labojums ir servera politikas maiņa, kas veikta apzināti, un viss, kas no tās atkarīgs, tiek atjaunināts tajā pašā piegājienā.

Profils nav politika

Community OpenVPN 2.6 nāk ar obligātiem klienta sertifikātiem, jo verify-client-cert pēc noklusējuma ir require. Tieši none iestatīšana pārtrauc sertifikāta pieprasījumu un nodod klienta autentifikāciju tai lietotājvārda un paroles kārtībai, ko serveris jau izmanto. Vecākas rokasgrāmatas ķeras pie client-cert-not-required, tās pašas idejas novecojušā rakstībā, tāpēc izmantojiet direktīvu, ko dokumentē jūsu instalētā versija. Jebkurā gadījumā izmaiņa notiek serverī, un neviens klienta profils to nevar izpildīt.

Zemāk esošais fragments ir visas servera puses izmaiņas, un pats par sevi tas nav strādājoša autentifikācijas konfigurācija. verify-client-cert none noņem sertifikāta prasību, savukārt username-as-common-name padara konta nosaukumu par identitāti, ko redz vēlākie atzvanījumi un katra klienta faili. Neviena rinda nepārbauda paroli, tāpēc verificētājam joprojām ir jāpastāv.

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

Šis verificētājs ir spraudnis vai skripts, ko vada auth-user-pass-verify, un tam jābūt vietā, pirms jebkura no iepriekš minētajām rindām kaut ko nozīmē. Apgriežot secību, tiek iegūts logs, kurā serveris neprasa sertifikātu un nepārbauda kontu.

Kas joprojām verificē serveri

Klienta sertifikāta atmešana nav TLS atmešana. Serveris patur savu sertifikātu un atslēgu, un klients patur CA uzticēšanos un resursdatora nosaukuma pārbaudes, kas neļauj tam runāt ar krāpnieku. remote-cert-tls server vai CA pakotnes noņemšana tāpēc, ka klientam vairs nav sertifikāta, ir izplatīta un nopietna nepareiza lasīšana, un 2.6 atsauce skaidri norāda, ka abi virzieni ir neatkarīgi. Viens pierāda serveri klientam; otrs pierāda klientu serverim.

Profils var arī saturēt tls-auth vai tls-crypt bloku. Tas ir koplietots vadības kanāla atslēga ar savu izplatīšanas un rotācijas ciklu, tāpēc fails bez sertifikāta vai atslēgas rindām nav automātiski drošs publicēšanai. Uzskatiet to par noslēpumu, līdz to izlasīsiet.

Sertifikāta fails, kas nokopēts no strādājoša profila, pats par sevi neko nepierāda; piederība nozīmē turēt tam atbilstošo privāto atslēgu, ko pārbauda ar sertifikātu autentificēts izvietojums. Fails, kurā ir sertifikāts, nav fails, ar kuru var autentificēties.

Kas verificētājam jādara

Kad sertifikāta prasība ir noņemta, viss balstās uz verificētāju: spraudni vai skriptu, ko vada auth-user-pass-verify. Tam jānoraida nederīgi pieteikšanās dati, jānoraida atspējoti vai neatbilstoši konti un jābeidzas slēgti, kad tas nevar sasniegt savu backend. username-as-common-name bieži tiek iespējots tam blakus, un tas maina identitāti, ko redz vēlākie atzvanījumi un katra klienta konfigurācijas faili. Tas nepārbauda paroli un nepadara neatbilstošu kontu atbilstošu. Tie ir atsevišķi darbi, un to sajaukšana ir veids, kā migrācija iztur laimīgā ceļa testu un neizdodas savā pirmajā reālajā incidentā.

Pārbaudiet negatīvos gadījumus tikpat rūpīgi kā pozitīvo. Profils, kas parāda paroles pieprasījumu, pierāda tikai to, ka klients prot uzzīmēt pieprasījumu, bet serveris, kas pieņem nepareizu paroli, pierāda ko ievērojami sliktāku. Testu kopai pievienojiet atspējotu kontu un beigušos pieteikšanās datus, ne tikai sliktu paroli.

Mainiet politiku, profilu un kartējumu kopā

Saskaņojiet trīs lietas: servera direktīvu, klienta profilu un katra klienta identitātes kartējumu. Mainiet tās atsevišķi, un klienti neizdodas pirms verifikācijas vai savienojas ar nosaukumu, ko administrators negaidīja, kas ir sliktāk, jo izskatās kā panākums. Savienojumu, kas izdodas ar nepareizu identitāti, ir grūtāk pamanīt nekā to, kas neizdodas.

Šim ceļam turiet divus testa kontus, vienu derīgu un vienu zināmi sliktu, un izmantojiet abus pēc jebkuras verificētāja izmaiņas. Derīgais konts pierāda laimīgo ceļu un identitātes kartējumu; sliktais pierāda, ka noraidīšana joprojām darbojas. Neviens tests neko nepasaka par atbilstības noteikumiem, tāpēc pievienojiet kontu, kas būtu jānoraida politisku iemeslu dēļ, ja izvietojumā tādi ir. Palaidiet visus trīs pēc katras izmaiņas, jo verificētājs, kas sāk pieņemt visu, izskatās tieši kā strādājoša pieteikšanās.

Pierakstiet, kādas autentifikācijas metodes serveris faktiski pieņem, nevis kādas iesaka profils. Šis ieraksts atbild uz jautājumu, ko cilvēki nemitīgi uzdod, proti, kas var pieslēgties šim pakalpojumam. Tas arī pārdzīvo nākamo administratoru, kurš citādi to no jauna atklātu no pakešu uztveršanas.