OpenVPN sen klienta atestilo: servila politiko, ne profilo

Vi forigas la liniojn de atestilo kaj ŝlosilo, transdonas la profilon, kaj la konekto daŭre malsukcesas per atestila eraro. La profilo neniam estis tio, kio trudis tiun postulon. La servilo decidas, ĉu klienta atestilo estas deviga, kaj neniu ŝanĝo ĉe la klienta flanko intertraktas tion for. Do la ripeto estas ŝanĝo de servila politiko, farita intence, kun ĉio dependa de ĝi ĝisdatigita en la sama paso.

La profilo ne estas la politiko

Community OpenVPN 2.6 venas kun devigaj klientaj atestiloj, ĉar verify-client-cert defaŭlte estas require. Agordi ĝin al none estas tio, kio haltigas la postulon pri atestilo kaj transdonas la klientan aŭtentikigon al kiu ajn aranĝo de uzantnomo kaj pasvorto, kiun la servilo jam uzas. Pli malnovaj gvidiloj alprenas client-cert-not-required, la malnovan literumadon de la sama ideo, do uzu la direktivon, kiun dokumentas via instalita versio. Ĉiuokaze la ŝanĝo okazas sur la servilo, kaj neniu klienta profilo povas plenumi ĝin.

La fragmento sube estas la tuta ŝanĝo sur la servila flanko, kaj per si mem ĝi ne estas funkcianta aŭtentikiga agordo. verify-client-cert none forigas la postulon pri atestilo, dum username-as-common-name faras la kontan nomon la idento, kiun vidas pli postaj reagoj kaj dosieroj por ĉiu kliento. Neniu el la du linioj kontrolas pasvorton, do kontrolilo ankoraŭ devas ekzisti.

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

Tiu kontrolilo estas kromaĵo aŭ skripto stirata de auth-user-pass-verify, kaj ĝi devas esti en loko antaŭ ol iu ajn el la supraj linioj signifas ion. Inversigi la ordon donas al vi fenestron, en kiu la servilo petas neniun atestilon kaj kontrolas neniun konton.

Kio ankoraŭ kontrolas la servilon

Forlasi la klientan atestilon ne signifas forlasi TLS. La servilo konservas sian atestilon kaj ŝlosilon, kaj la kliento konservas la CA-fidon kaj la gastigantnoman kontroladon, kiuj malhelpas ĝin paroli kun trompanto. Forigi remote-cert-tls server aŭ la CA-pakaĵon ĉar la kliento jam ne havas atestilon estas ofta kaj grava mislegado, kaj la 2.6-referenco klare diras, ke la du direktoj estas sendependaj. Unu pruvas la servilon al la kliento; la alia pruvas la klienton al la servilo.

Profilo povas ankaŭ porti blokon tls-auth aŭ tls-crypt. Tio estas komuna ŝlosilo de la kontrola kanalo kun propra disdona kaj rotacia ciklo, do dosiero sen linioj de atestilo aŭ ŝlosilo ne estas aŭtomate sekura por publikigo. Traktu ĝin kiel sekreton ĝis vi legos ĝin.

Atestila dosiero kopiita el funkcianta profilo pruvas nenion per si mem; posedi signifas teni la privatan ŝlosilon, kiu kongruas kun ĝi, kion kontrolas instalado aŭtentikigita per atestilo. Dosiero, kiu enhavas atestilon, ne estas dosiero, per kiu oni povas aŭtentikigi.

Kion la kontrolilo devas fari

Forigite la atestilan postulon, ĉio ripozas sur la kontrolilo: kromaĵo aŭ skripto stirata de auth-user-pass-verify. Ĝi devas malakcepti nevalidajn akreditaĵojn, malakcepti malŝaltitajn aŭ neelekteblajn kontojn, kaj malsukcesi fermite kiam ĝi ne povas atingi sian malantaŭan sistemon. username-as-common-name ofte estas ŝaltita apude, kaj ĝi ŝanĝas la identon, kiun vidas pli postaj reagoj kaj agordaj dosieroj por ĉiu kliento. Ĝi ne kontrolas pasvorton kaj ne igas neelekteblan konton elektebla. Tiuj estas apartaj taskoj, kaj miksi ilin estas kiel migrado trapasas sian teston de la feliĉa vojo kaj malsukcesas ĉe sia unua reala okazaĵo.

Testu la negativajn kazojn same zorgeme kiel la pozitivan. Profilo, kiu montras pasvortan inviton, pruvas nur ke la kliento povas desegni inviton, dum servilo, kiu akceptas la malĝustan pasvorton, pruvas ion konsiderinde pli malbonan. Aldonu malŝaltitan konton kaj eksvalidiĝintan akreditaĵon al la testa aro, ne nur malbonan pasvorton.

Ŝanĝu politikon, profilon kaj mapadon kune

Kunordigu tri aferojn: la servilan direktivon, la klientan profilon kaj la mapadon de idento por ĉiu kliento. Ŝanĝu ilin aparte kaj klientoj malsukcesas antaŭ la kontrolo, aŭ konektiĝas sub nomo, kiun la administranto ne atendis, kio estas pli malbone ĉar ĝi aspektas kiel sukceso. Konekto, kiu sukcesas sub la malĝusta idento, estas pli malfacile rimarkebla ol tiu, kiu malsukcesas.

Tenu du testajn kontojn por ĉi tiu vojo, unu validan kaj unu konate malbonan, kaj uzu ambaŭ post iu ajn ŝanĝo al la kontrolilo. La valida konto pruvas la feliĉan vojon kaj la mapadon de idento; la malbona pruvas, ke la malakcepto ankoraŭ funkcias. Neniu el la testoj diras ion pri elektecaj reguloj, do aldonu konton, kiu devus esti rifuzata pro politikaj kialoj, se la instalado havas ilin. Rulu ĉiujn tri post ĉiu ŝanĝo, ĉar kontrolilo, kiu komencas akcepti ĉion, aspektas precize kiel funkcianta ensaluto.

Registru, kiujn aŭtentikigajn metodojn la servilo efektive akceptas, ne kiujn la profilo sugestas. Tiu registro respondas la demandon, kiun homoj daŭre starigas, nome kiu povas konektiĝi al ĉi tiu servo. Ĝi ankaŭ postvivas la sekvan administranton, kiu alie retrovus ĝin el paketa kapto.