OpenVPN brez odjemalskega potrdila: politika strežnika, ne profil

Izbrišete vrstice s potrdilom in ključem, predate profil in povezava še vedno spodleti z napako potrdila. Profil nikoli ni bil tisto, kar je uveljavljalo to zahtevo. O tem, ali je odjemalsko potrdilo obvezno, odloča strežnik, in nobena sprememba na strani odjemalca tega ne izpogaja. Popravek je torej sprememba politike strežnika, narejena namerno, z vsem, kar je od nje odvisno, posodobljenim v istem prehodu.

Profil ni politika

Community OpenVPN 2.6 prihaja z obveznimi odjemalskimi potrdili, ker je verify-client-cert privzeto require. Nastavitev na none ustavi zahtevo po potrdilu in preda avtentikacijo odjemalca tisti ureditvi uporabniškega imena in gesla, ki jo strežnik že izvaja. Starejši vodniki segajo po client-cert-not-required, zastarelem zapisu iste ideje, zato uporabite direktivo, ki jo dokumentira vaša nameščena različica. V vsakem primeru se sprememba zgodi na strežniku in noben odjemalski profil je ne more izvesti.

Spodnji odlomek je celotna sprememba na strani strežnika in sam po sebi ni delujoča konfiguracija avtentikacije. verify-client-cert none odstrani zahtevo po potrdilu, medtem ko username-as-common-name naredi ime računa identiteto, ki jo vidijo poznejši povratni klici in datoteke posameznega odjemalca. Nobena vrstica ne preverja gesla, zato mora preveritelj še vedno obstajati.

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

Ta preveritelj je vtičnik ali skript, ki ga vodi auth-user-pass-verify, in mora biti na mestu, preden katera od zgornjih vrstic kaj pomeni. Obrnjen vrstni red vam da okno, v katerem strežnik ne zahteva potrdila in ne preverja računa.

Kaj še vedno preverja strežnik

Opustitev odjemalskega potrdila ne pomeni opustitve TLS. Strežnik obdrži svoje potrdilo in ključ, odjemalec pa obdrži zaupanje v CA in preveritve imena gostitelja, ki ga zadržijo pred pogovorom z prevarantom. Odstranitev remote-cert-tls server ali paketa CA zato, ker odjemalec nima več potrdila, je pogosto in resno napačno branje, in referenca za 2.6 izrecno navaja, da sta smeri neodvisni. Ena dokazuje strežnik odjemalcu; druga dokazuje odjemalca strežniku.

Profil lahko nosi tudi blok tls-auth ali tls-crypt. To je skupni ključ krmilnega kanala z lastnim ciklom distribucije in rotacije, zato datoteka brez vrstic s potrdilom ali ključem ni samodejno varna za objavo. Obravnavajte jo kot skrivnost, dokler je ne preberete.

Datoteka s potrdilom, kopirana iz delujočega profila, sama po sebi ničesar ne dokazuje; imetje pomeni imeti zasebni ključ, ki se ujema z njo, kar preveri namesnitev, avtenticirana s potrdilom. Datoteka, ki vsebuje potrdilo, ni datoteka, s katero se je mogoče avtenticirati.

Kaj mora preveritelj narediti

Ko je zahteva po potrdilu odstranjena, vse sloni na preveritelju: vtičniku ali skriptu, ki ga vodi auth-user-pass-verify. Zavračati mora neveljavne poverilnice, zavračati onemogočene ali neprimerne račune in zaprto odpovedati, ko ne more doseči svojega backenda. username-as-common-name se pogosto omogoči ob njem in spremeni identiteto, ki jo vidijo poznejši povratni klici in konfiguracijske datoteke posameznega odjemalca. Ne preverja gesla in ne naredi neprimernega računa primernega. To so ločena opravila, in njihovo mešanje je način, kako migracija prestane test srečne poti in spodleti pri svojem prvem resničnem incidentu.

Negativne primere preizkusite enako skrbno kot pozitivnega. Profil, ki pokaže poziv za geslo, dokaže le, da odjemalec zna narisati poziv, medtem ko strežnik, ki sprejme napačno geslo, dokaže nekaj precej slabšega. V preizkusni nabor dodajte onemogočen račun in potekle poverilnice, ne le slabega gesla.

Spremenite politiko, profil in preslikavo skupaj

Uskladite tri stvari: direktivo strežnika, profil odjemalca in preslikavo identitete posameznega odjemalca. Če jih spremenite ločeno, odjemalci spodletijo pred preverjanjem ali se povežejo pod imenom, ki ga skrbnik ni pričakoval, kar je slabše, ker je videti kot uspeh. Povezavo, ki uspe pod napačno identiteto, je težje opaziti kot tisto, ki spodleti.

Za to pot imejte dva preizkusna računa, enega veljavnega in enega znano slabega, in po vsaki spremembi preveritelja uporabite oba. Veljavni račun dokaže srečno pot in preslikavo identitete; slabi dokaže, da zavračanje še deluje. Noben preizkus ne pove ničesar o pravilih primernosti, zato dodajte račun, ki bi moral biti zavrnjen iz političnih razlogov, če jih namesnitev ima. Po vsaki spremembi zaženite vse tri, ker je preveritelj, ki začne sprejemati vse, videti natanko kot delujoča prijava.

Zabeležite, katere metode avtentikacije strežnik dejansko sprejema, ne katere predlaga profil. Ta zapis odgovarja na vprašanje, ki ga ljudje nenehno postavljajo, namreč kdo se lahko poveže s to storitvijo. Preživi tudi naslednjega skrbnika, ki bi ga sicer znova odkril iz zajema paketov.