Oikea VPN-salasana ei korvaa puuttuvaa varmennetta

Tunnistetiedot ovat oikein, profiili tuodaan puhtaasti, ja yhteys epäonnistuu silti ennen todennuksen valmistumista. Windowsissa viesti voi olla virhe 798, varmenteesta jota EAP-menetelmälle ei löytynyt. OpenVPN:n asiakasloki näyttää TLS-kättelyn, joka ei koskaan tyydytä palvelinta. Molemmat kuvaavat samaa puuttuvaa objektia: asiakasvarmennetta, joka asiakkaan olisi pitänyt esittää.

Salasana todistaa salaisuuden tuntemisen; varmenne todistaa avaimen hallussapidon, eikä toinen korvaa toista.

Salasana ei ollut koskaan ongelma

Virhe 798 on varmenteen haun epäonnistuminen. Asiakkaalta pyydettiin varmennetta, joka vastaa määritettyä todennusmenetelmää, se etsi varastostaan eikä löytänyt mitään käyttökelpoista. Se voi tarkoittaa, että varmenne puuttuu, on olemassa ilman yksityistä avainta, on vanhentunut tai on tallennettu paikkaan, johon haku ei yllä. Salasanan uudelleen yrittäminen ei voi muuttaa mitään näistä ehdoista, siksi virhe palaa myös oikeilla tunnistetiedoilla.

Lue viesti ennen kuin toimit sen perusteella. Tunnistetietojen hylkäys, varmenteen haun epäonnistuminen ja TLS-kättelyn epäonnistuminen ovat kolme eri havaintoa, ja vain yksi niistä liittyy salasanaan.

Mitä asiakasvaraston on sisällettävä

Kaksi objektia on mukana. Asiakasvarmenne on asennettava VPN-asiakasta käyttävälle käyttäjälle yksityisen avaimensa kanssa, ja myöntävä juuri on voitava luottaa. .cer-tiedosto sisältää vain julkisen varmenteen, joten se ei yksinään voi todentaa mitään. Windowsin varmennehallinnassa asiakkaan identiteetti kuuluu nykyisen käyttäjän henkilökohtaiseen varastoon ja juuri luotettujen juurien varastoon.

Identiteetin asentaminen tietokoneen varastoon tai vain juurivarastoon ei täytä käyttäjän henkilökohtaiseen varastoon kohdistuvaa hakua. Tarkista varasto, yksityisen avaimen merkintä ja voimassaolopäivät yhdessä ja käynnistä asiakas sitten uudelleen, jotta se lukee varaston uudelleen.

Kaksi tuotetta, sama puuttuva tunnistetieto

OpenVPN-palvelimet vaativat oletuksena asiakasvarmenteen. auth-user-pass-asetuksen lisääminen asiakkaaseen lähettää käyttäjänimen ja salasanan, ja TLS-kättely pyytää yhä varmennetta, joten pelkkä salasana ei voi viimeistellä yhteyttä verify-client-cert require -asetuksen alla. Palvelin voidaan asettaa vaatimaan ei mitään, mikä tekee salasanasta asiakkaan ainoan tunnistetiedon ja on todellinen heikennys. auth-user-pass-verify-asetuksen takana oleva shell-skripti voi validoida tunnistetiedot, ja se edellyttää skriptien suorittamisen olevan käytössä, mikä tekee siitä riskialttiimman ratkaisun kuin kunnollinen todennuksen taustajärjestelmä.

Vain salasanaan perustuva profiili riippuu myös työnnetyistä asetuksista, jotka puolestaan riippuvat siitä, että vetomekanismi on käytössä.

Älä korjaa puuttuvaa varmennetta kytkemällä tarkistuksia pois

Kiusaus on löysätä varmennusta, jotta viesti katoaa. Se poistaa valvonnan, joka teki tehtävänsä, ja jättää yhteyden, joka ei enää todista sitä, mitä väittää. Jos yhdyskäytävä on äskettäin vaihtanut juurensa, lataa asiakaspaketti uudelleen sen sijaan että muokkaat profiilia, koska vanha paketti voi yhä sisältää edellisen juuren. Jos varmenteen todennusvaihtoehto puuttuu profiilieditorista, asennettu Windows-versio ei ehkä tarjoa kyseistä menetelmää; päivitä järjestelmä sen sijaan että muokkaat XML:ää käsin.

Kirjaa, mikä varasto sisälsi varmenteen, mikä käyttäjä käytti asiakasta ja oliko yksityinen avain paikalla. Nämä kolme selittävät lähes jokaisen tämän epäonnistumisen tapauksen.

Salasana oli kunnossa. Tunnistetieto, jota menetelmä todella tarvitsi, oli muualla.