Yhdyskäytävän varmenne on kunnossa: miksi IKEv2 PEAP -kirjautuminen silti epäonnistuu

VPN-yhdyskäytäväsi varmenne on voimassa, ketju validoituu, ja IKEv2-asiakas silti hylkää kirjautumisen viestillä varmenteen voimassaolovälistä. Ensimmäinen vaisto on myöntää yhdyskäytävän varmenne uudelleen tai vaihtaa EAP-menetelmä, ja molemmat ovat yleensä väärin. Kirjautumisyritys kantaa kahta erillistä palvelinidentiteettiä: yhdyskäytävän varmenne, jota IKE käyttää, ja varmenne, jonka esittää se, mikä päättää PEAPin. Toinen niistä on kunnossa, ja toinen on syy siihen, miksi asiakas pysähtyi.

Kaksi identiteettiä, yksi kirjautumisyritys

VPN-profiilin varmenne kuuluu IKE-vaihtoon: se todistaa, että yhdyskäytävä on se vastapuoli, jonka profiili nimeää, määritetyn IKE-käytännön mukaisesti. Tässä epäonnistuva varmenne kuuluu toiseen keskusteluun, siihen TLS-istuntoon, jonka PEAP avaa sen kanssa, joka todentaa käyttäjän, usein RADIUS-palvelin kuten NPS eikä itse yhdyskäytävä. Kolmas tarkistus, käyttäjän tunnistetiedot, tapahtuu tuon istunnon sisällä. Voimassa oleva salasana ei voi korjata vanhentunutta palvelinvarmennetta, eikä voimassa oleva yhdyskäytävän varmenne voi taata PEAP-päätepistettä.

Tämä kerrostus selittää, miksi varmennevirhe ilmaantuu paikkaan, jossa ainoa määritetty varmenne oli yhdyskäytävän oma. Se selittää myös, miksi tuon varmenteen uudelleenmyöntäminen ei muuta mitään.

Lue lokirivi vaihetta vasten

Etsi viesti, joka nimeää syyn ja päivämäärät. Voimassaolovälistä kertova valitus subjektivirheen vieressä tarkoittaa, että palvelin hylkäsi sille annetun varmenteen, ei että käyttäjä hylkäsi kirjautumisen. Etsi sitten vaihe: strongSwanin charon-loki näyttää IKE_SA .* established ennen EAP-vaihdon alkua, joten varmennevirhe tuon rivin jälkeen kuuluu EAP-identiteetille, kun taas sitä ennen oleva virhe osoittaa yhdyskäytävään. Windows-asiakkaan yhteyksien paneelin vaiheteksti kertoo saman.

Tarkista asiakkaan kello ennen minkään varmenteen koskemista. Laite, joka on tunteja pielessä, tuottaa saman voimassaolovirheen kuin todella vanhentunut varmenne. Kellon asettaminen on viiden sekunnin korjaus, ja varmenteen vaihtaminen, joka ei koskaan ollut ongelma, on katkos.

Selvitä, mikä päätepiste päättää PEAPin

Yhdyskäytävä ja RADIUS -ratkaisussa yhdyskäytävä välittää EAPin eikä päätä sitä. strongSwanin eap-radius-liitännäinen antaa vaihdon RADIUS-palvelimelle, joka omistaa PEAPin TLS-istunnon ja sen varmenteen. Korreloi yksi epäonnistunut yritys molemmista lokeista ja vahvista, mikä prosessi todella valitsi varmenteen tuolle istunnolle.

NPS:ssä varmenteen on oltava paikallisen tietokoneen arkistossa, sen on kannettava palvelintodennuksen käyttötarkoitusta, vastattava nimeä, jota asiakkaat odottavat, ja oltava palvelutilin luettavissa. Microsoftin NPS:n varmennevaatimukset luettelevat nämä ehdot. Muilla EAP-palvelimilla on omat valintasääntönsä, joten älä kopioi NPS:n erityispiirteitä FreeRADIUS-asennukseen äläkä päinvastoin. Sääntö, joka pätee molemmissa tapauksissa, on että PEAPin päättävä päätepiste omistaa sen varmenteen, jota olet vaihtamassa.

Vaihda varmenne siellä, missä EAP päättyy

Uusi tai vaihda varmenne päätepisteessä, joka päättää PEAPin, tuetun prosessin kautta, säilyttäen palvelintodennuksen käyttötarkoituksen ja odotetun nimen. Asenna täysi ketju sinne, mistä palvelu sitä etsii, ja anna palvelulle pääsy yksityiseen avaimeen. Käynnistä palvelu uudelleen tai sido se uudelleen, koska monet palvelut pitävät vanhaa varmennetta muistissa ja esittävät sitä edelleen. Koneelle kopioitu tiedosto ei todista mitään siitä, minkä varmenteen palvelu todella esittää.

Vahvista muutos korreloimalla seuraava yritys palvelun omaan lokiin tai tarkistamalla varmenne, jonka istunto esitti. Jos loki näyttää yhä vanhan sormenjäljen, uudelleenkäynnistys ei tehonnut.

Älä oleta, että hakemiston uusin tiedosto on se, jota käytetään. Kopio oikealla nimellä ja väärillä käyttöoikeuksilla ei muuta mitään. Arvioi muutos esitetyn identiteetin, älä tiedoston aikaleiman perusteella.

Mitä ei pidä tehdä

Älä poista PEAP-tarkistusta käytöstä äläkä pakota heikompaa sisämenetelmää virheen ohittamiseksi. Se muuttaa käytäntöä ja poistaa palvelintodennusominaisuuden, joka alun perin nappasi vanhentuneen varmenteen. Vaihtaisit toimivan tarkistuksen toimivaan yhteyteen, ja seuraava vanhentunut varmenne saapuisi ilman mitään, mikä ilmoittaisi siitä.

Älä pidä toisen käyttöjärjestelmän onnistunutta yhteyttä todisteena siitä, että varmenne on hyväksyttävä. Se asiakas voi käyttää toista EAP-menetelmää, toista luottamusvarastoa tai ei lainkaan palvelinvalidointia, joten sen onnistuminen ei kerro mitään tässä epäonnistuneesta tarkistuksesta. Pidä yksi tarkoituksellinen negatiivinen testi, kuten väärän nimen varmenne tai epäluotettava ketju, joka epäonnistuu odotetusti. Jos tämä testi nyt menee läpi, poistit tarkistuksen etkä korjannut varmennetta. Kirjoita muistiin, mikä identiteetti epäonnistui, jotta seuraava henkilö ei aloita taas yhdyskäytävän varmenteesta.