OpenVPN ilman asiakasvarmennetta: palvelinkäytäntö, ei profiili

Poistat varmenne- ja avainrivit, luovutat profiilin, ja yhteys epäonnistuu edelleen varmennevirheeseen. Profiili ei ollut koskaan se, mikä vaatimusta valvoi. Palvelin päättää, onko asiakasvarmenne pakollinen, eikä mikään asiakaspuolen muutos neuvottele sitä pois. Korjaus on siis palvelinkäytännön muutos, joka tehdään tarkoituksella ja jossa kaikki siitä riippuva päivitetään samalla kertaa.

Profiili ei ole käytäntö

Community OpenVPN 2.6 tulee pakollisten asiakasvarmenteiden kanssa, koska verify-client-cert on oletuksena require. Asettaminen arvoon none lopettaa varmenteen vaatimisen ja antaa asiakkaan todennuksen sille käyttäjätunnus- ja salasanajärjestelylle, jota palvelin jo pyörittää. Vanhemmat oppaat tarttuvat client-cert-not-required-direktiiviin, saman idean vanhentuneeseen kirjoitusasuun, joten käytä direktiiviä, jonka asennettu versiosi dokumentoi. Joka tapauksessa muutos tapahtuu palvelimella, eikä mikään asiakasprofiili voi tehdä sitä.

Alla oleva katkelma on koko palvelinpuolen muutos, eikä se yksinään ole toimiva todennuskonfiguraatio. verify-client-cert none poistaa varmennevaatimuksen, kun taas username-as-common-name tekee tilin nimestä identiteetin, jonka myöhemmät takaisinkutsut ja asiakaskohtaiset tiedostot näkevät. Kumpikaan rivi ei tarkista salasanaa, joten todennuskomponentin on edelleen oltava olemassa.

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

Tuo todennuskomponentti on liitännäinen tai skripti, jota auth-user-pass-verify ohjaa, ja sen on oltava paikallaan ennen kuin kumpikaan yllä olevista riveistä merkitsee mitään. Järjestyksen kääntäminen antaa ikkunan, jossa palvelin ei pyydä varmennetta eikä tarkista tiliä.

Mikä yhä todentaa palvelimen

Asiakasvarmenteesta luopuminen ei tarkoita TLS:stä luopumista. Palvelin pitää varmenteensa ja avaimensa, ja asiakas pitää CA-luottamuksen ja isäntänimen tarkistukset, jotka estävät sitä puhumasta huijarille. remote-cert-tls server-rivin tai CA-nipun poistaminen siksi, että asiakkaalla ei enää ole varmennetta, on yleinen ja vakava väärinymmärrys, ja 2.6-viite toteaa selvästi, että kaksi suuntaa ovat toisistaan riippumattomia. Toinen todistaa palvelimen asiakkaalle; toinen todistaa asiakkaan palvelimelle.

Profiili voi sisältää myös tls-auth- tai tls-crypt-lohkon. Se on jaettu ohjauskanavan avain, jolla on oma jakelu- ja kierrätyssykli, joten tiedosto ilman varmenne- tai avainrivejä ei ole automaattisesti turvallinen julkaistavaksi. Kohtele sitä salaisuutena, kunnes olet lukenut sen.

Toimivasta profiilista kopioitu varmennetiedosto ei todista itsessään mitään; hallussapito tarkoittaa sitä vastaavan yksityisavaimen hallussapitoa, minkä varmenteella todennettu käyttöönotto tarkistaa. Tiedosto, joka sisältää varmenteen, ei ole tiedosto, jolla voi todentua.

Mitä todennuskomponentin on tehtävä

Kun varmennevaatimus on poistettu, kaikki nojaa todennuskomponenttiin: liitännäiseen tai skriptiin, jota auth-user-pass-verify ohjaa. Sen on hylättävä virheelliset tunnistetiedot, hylättävä poistetut tai kelpaamattomat tilit ja epäonnistuttava suljetusti, kun se ei tavoita taustajärjestelmäänsä. username-as-common-name otetaan usein käyttöön sen rinnalla, ja se muuttaa identiteettiä, jonka myöhemmät takaisinkutsut ja asiakaskohtaiset asetustiedostot näkevät. Se ei tarkista salasanaa eikä tee kelpaamattomasta tilistä kelpaavaa. Ne ovat erillisiä tehtäviä, ja niiden sekoittaminen on se tapa, jolla migraatio läpäisee onnellisen polun testin ja epäonnistuu ensimmäisessä todellisessa tapauksessaan.

Testaa negatiiviset tapaukset yhtä huolellisesti kuin positiivinen. Profiili, joka näyttää salasanakehotteen, todistaa vain, että asiakas osaa piirtää kehotteen, kun taas palvelin, joka hyväksyy väärän salasanan, todistaa jotain huomattavasti pahempaa. Lisää testijoukkoon poistettu tili ja vanhentunut tunnistetieto, ei vain huonoa salasanaa.

Muuta käytäntöä, profiilia ja mappausta yhdessä

Sovita yhteen kolme asiaa: palvelindirektiivi, asiakasprofiili ja asiakaskohtaisen identiteetin kartoitus. Muuta niitä erikseen, niin asiakkaat epäonnistuvat ennen todennusta tai yhdistävät nimellä, jota ylläpitäjä ei odottanut, mikä on pahempaa, koska se näyttää onnistumiselta. Väärällä identiteetillä onnistuva yhteys on vaikeampi huomata kuin epäonnistuva.

Pidä tätä polkua varten kahta testitiliä, yhtä kelvollista ja yhtä tunnetusti huonoa, ja käytä molempia jokaisen todennuskomponentin muutoksen jälkeen. Kelvollinen tili todistaa onnellisen polun ja identiteetin kartoituksen; huono todistaa, että hylkääminen toimii edelleen. Kumpikaan testi ei kerro mitään kelpoisuussäännöistä, joten lisää tili, joka pitäisi hylätä käytännön syistä, jos käyttöönotossa on sellaisia. Aja kaikki kolme jokaisen muutoksen jälkeen, koska todennuskomponentti, joka alkaa hyväksyä kaiken, näyttää täsmälleen toimivalta kirjautumiselta.

Kirjaa, mitkä todennusmenetelmät palvelin tosiasiassa hyväksyy, älä niitä, joita profiili ehdottaa. Se kirjaus vastaa kysymykseen, jota ihmiset jatkuvasti kysyvät, eli kuka voi yhdistää tähän palveluun. Se myös elää seuraavan ylläpitäjän yli, joka muuten löytäisi sen uudelleen pakettikaappauksesta.