OpenVPN pa certifikatë klienti: politikë serveri, jo profil

Ju fshini rreshtat e certifikatës dhe çelësit, dorëzoni profilin, dhe lidhja vazhdon të dështojë me një gabim certifikate. Profili nuk ishte kurrë ajo që zbatonte atë kërkesë. Serveri vendos nëse një certifikatë klienti është e detyrueshme, dhe asnjë redaktim në anën e klientit nuk e negocion atë. Pra, rregullimi është një ndryshim i politikës së serverit, i bërë me qëllim, me gjithçka që varet prej saj të përditësuar në të njëjtin hap.

Profili nuk është politika

Community OpenVPN 2.6 vjen me certifikata klienti të detyrueshme, sepse verify-client-cert si parazgjedhje është require. Vendosja e tij në none është ajo që ndalon kërkesën për certifikatë dhe ia dorëzon vërtetimin e klientit atij rregullimi të emrit të përdoruesit dhe fjalëkalimit që serveri tashmë e ekzekuton. Udhëzuesit më të vjetër kapen pas client-cert-not-required, drejtshkrimit të vjetëruar të së njëjtës ide, prandaj përdorni direktivën që dokumenton versioni juaj i instaluar. Në çdo rast ndryshimi ndodh në server, dhe asnjë profil klienti nuk mund ta kryejë atë.

Fragmenti më poshtë është i gjithë ndryshimi në anën e serverit, dhe më vete nuk është një konfigurim vërtetimi funksional. verify-client-cert none heq kërkesën për certifikatë, ndërsa username-as-common-name e bën emrin e llogarisë identitetin që shohin kthimet e thirrjeve të mëvonshme dhe skedarët e secilit klient. Asnjë prej rreshtave nuk kontrollon një fjalëkalim, pra duhet të ekzistojë ende një verifikues.

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

Ai verifikues është një shtojcë ose një skript i drejtuar nga auth-user-pass-verify, dhe duhet të jetë në vend përpara se ndonjë prej rreshtave më sipër të nënkuptojë diçka. Kthimi i rendit ju jep një dritare në të cilën serveri nuk kërkon certifikatë dhe nuk kontrollon asnjë llogari.

Çfarë vazhdon të verifikojë serverin

Heqja e certifikatës së klientit nuk do të thotë heqje e TLS. Serveri mban certifikatën dhe çelësin e tij, dhe klienti mban besimin te CA dhe kontrollet e emrit të hostit që e pengojnë të flasë me një mashtrues. Heqja e remote-cert-tls server ose e paketës CA sepse klienti nuk ka më certifikatë është një lexim i gabuar i zakonshëm dhe serioz, dhe referenca 2.6 është e qartë se dy drejtimet janë të pavarur. Njëra dëshmon serverin ndaj klientit; tjetra dëshmon klientin ndaj serverit.

Një profil mund të mbajë gjithashtu një bllok tls-auth ose tls-crypt. Ky është një çelës i përbashkët i kanalit të kontrollit me ciklin e tij të shpërndarjes dhe rrotullimit, pra një skedar pa rreshta certifikate ose çelësi nuk është automatikisht i sigurt për t'u publikuar. Trajtojeni si sekret derisa ta keni lexuar.

Një skedar certifikate i kopjuar nga një profil funksional nuk dëshmon asgjë më vete; zotërimi do të thotë të mbash çelësin privat që përputhet me të, gjë që e kontrollon një vendosje e vërtetuar me certifikatë. Një skedar që përmban një certifikatë nuk është një skedar me të cilin mund të vërtetohesh.

Çfarë duhet të bëjë verifikuesi

Me kërkesën për certifikatë të hequr, gjithçka mbështetet te verifikuesi: një shtojcë, ose një skript i drejtuar nga auth-user-pass-verify. Ai duhet të refuzojë kredencialet e pavlefshme, të refuzojë llogaritë e çaktivizuara ose të papërshtatshme dhe të dështojë i mbyllur kur nuk mund të arrijë backend-in e tij. username-as-common-name shpesh aktivizohet pranë tij, dhe ndryshon identitetin që shohin kthimet e thirrjeve të mëvonshme dhe skedarët e konfigurimit të secilit klient. Nuk verifikon një fjalëkalim dhe nuk e bën të përshtatshme një llogari të papërshtatshme. Këto janë detyra të ndara, dhe përzierja e tyre është mënyra se si një migrim kalon testin e rrugës së lumtur dhe dështon në incidentin e tij të parë real.

Testoni rastet negative po aq me kujdes sa atë pozitiv. Një profil që shfaq një kërkesë fjalëkalimi dëshmon vetëm se klienti mund të vizatojë një kërkesë, ndërsa një server që pranon fjalëkalimin e gabuar dëshmon diçka shumë më të keqe. Shtoni në grupin e testeve një llogari të çaktivizuar dhe një kredencial të skaduar, jo vetëm një fjalëkalim të keq.

Ndryshoni politikën, profilin dhe hartëzimin së bashku

Koordinoni tre gjëra: direktivën e serverit, profilin e klientit dhe hartëzimin e identitetit për çdo klient. Ndryshojini veçmas dhe klientët dështojnë para verifikimit, ose lidhen me një emër që administratori nuk e priste, gjë që është më keq sepse duket si sukses. Një lidhje që ka sukses nën identitetin e gabuar është më e vështirë për t'u vënë re sesa një që dështon.

Mbani dy llogari testimi për këtë rrugë, një të vlefshme dhe një të njohur si të keqe, dhe përdorni të dyja pas çdo ndryshimi në verifikues. Llogaria e vlefshme dëshmon rrugën e lumtur dhe hartëzimin e identitetit; e keqja dëshmon se refuzimi ende funksionon. Asnjë prej testeve nuk ju thotë asgjë për rregullat e përshtatshmërisë, prandaj shtoni një llogari që duhet të refuzohet për arsye politike nëse vendosja i ka ato. Ekzekutoni të treja pas çdo ndryshimi, sepse një verifikues që fillon të pranojë gjithçka duket saktësisht si një hyrje funksionale.

Regjistroni cilat metoda vërtetimi serveri pranon në të vërtetë, jo ato që sugjeron profili. Ai regjistrim i përgjigjet pyetjes që njerëzit vazhdojnë të bëjnë, domethënë kush mund të lidhet me këtë shërbim. Ai gjithashtu i mbijeton administratorit të ardhshëm, i cili përndryshe do ta rizbulonte nga një kapje paketash.