OpenVPN username-as-common-name: zakaj je vaše preverjanje CN prazno

Dodate skript client-connect, ki zavrne vsako povezavo, v kateri se common_name razlikuje od username, in to je videti kot povezava med potrdilom in računom. Na strežniku, ki izvaja username-as-common-name, je ta primerjava že izgubila pomen, ko se skript zažene. Obe vrednosti sta ista niz, zato preizkus uspe tudi za potrdilo, izdano povsem drugi osebi.

Preverjanje ni napačno zato, ker je skript slabo napisan. Napačno je zato, ker je bila vrednost, ki jo bere, zamenjana prej v isti povezavi.

Kaj primerjava navidez dokazuje

Preverjanje pristnosti s potrdilom in preverjanje pristnosti z geslom sta ločena dokaza, in strežnik lahko zahteva oba, ne da bi zahteval, da pripadata isti osebi. Vrzel je resnična: veljavno potrdilo naprave plus kateri koli veljaven račun je druga trditev kot to potrdilo plus en imenovan račun. Skript, ki primerja common_name z username, se bere kot manjkajoči člen med njima. To bi bil, če bi common_name še vedno pomenilo, kar je povedalo potrdilo.

Ali je tako, je odvisno od ene možnosti strežnika, in ta možnost se običajno vklopi iz nepovezanega razloga, na primer da je konfiguracijske datoteke za posameznega uporabnika lažje poimenovati.

Kaj username-as-common-name naredi z imenom

Ko je username-as-common-name omogočen, OpenVPN po preverjanju uporabniškega imena in gesla zamenja skupno ime potrdila z overjenim uporabniškim imenom. Kavelj za preverjanje, ki se izvaja med tem preverjanjem, še vedno prejme skupno ime potrdila, ker zamenjava še ni bila izvedena. Vse pozneje, vključno z client-connect, vidi uporabniško ime. Zato poznejši povratni klic prejme eno identiteto dvakrat in je ne more primerjati s predstavljenim potrdilom.

Sledite eni ponazoritveni povezavi: potrdilo, izdano za bob-device, uspešna prijava v imenik kot alice in omogočena možnost. Faza preverjanja lahko še vedno vidi dva različna niza. Faza povezave vidi alice in alice.

Ta primer kaže, zakaj je primerjava prazna. Ne kaže, da bi bila povezava sicer sprejeta, ker preverjanje potrdila in preverjanje gesla še vedno tečeta sama.

Povezavo postavite tja, kjer obe identiteti še obstajata

Pravilo je treba uveljaviti v fazi, ki vidi identiteto potrdila in račun hkrati, kar v praksi pomeni kavelj za preverjanje uporabniškega imena in gesla ali tam naložen vtičnik. Podprt vtičnik, ki že izvaja preverjanje gesla, je običajno pravo mesto za dodajanje pravila seznanjanja, ker bi njegova zamenjava s primerjavo imen popolnoma odstranila preverjanje gesla.

Preslikavo določite pred pisanjem kode, ker je enakost redko resnična politika. Potrdilo pogosto identificira napravo, medtem ko prijava identificira osebo, in ena naprava lahko zakonito služi več ljudem. Razmerje shranite v obliki, katere izdajo nadzorujete, in odločite, kaj se zgodi pri preimenovanju, pri ponovni izdaji in pri imenih s kvalifikacijo domene. Pretvorba v male črke ali odstranitev domenske predpone brez razumevanja imenika lahko združi dva računa, ki bi morala ostati ločena.

Ne pozabite, da možnost spreminja tudi, katera konfiguracija za posameznega odjemalca velja, ker je client-config-dir vezan na skupno ime.

Preizkusite seznanjanje z dvema veljavnima poverilnicama

Začnite s parom, ki ga vaša politika dovoljuje, in potrdite, da se poveže. Nato predstavite isto veljavno potrdilo z drugim, a sicer veljavnim računom: ta poskus mora spodleteti, in spodleteti mora zaradi pravila seznanjanja, ne zaradi napačno vpisanega gesla. Napačno geslo dokazuje, da preverjanje gesla deluje, in ne pove ničesar o pravilu med potrdilom in računom.

Preverite tudi poti z manjkajočim in neveljavnim potrdilom ter potrdite, katero identiteto strežnik uporablja za nastavitve posameznega odjemalca. Če je edini način, da primerjava deluje, izklop username-as-common-name, najprej ocenite stroške te spremembe, ker vrne iskanje konfiguracije vsakega odjemalca nazaj na ime potrdila.