Potrdilo prehoda je v redu: zakaj se prijava IKEv2 PEAP še vedno ne uspe

Potrdilo vašega prehoda VPN je veljavno, veriga se preveri, in odjemalec IKEv2 vseeno zavrne prijavo s sporočilom o intervalu veljavnosti potrdila. Prvi impulz je, da potrdilo prehoda izdate znova ali spremenite metodo EAP, in oboje je običajno napačno. Poskus prijave nosi dve ločeni identiteti strežnika: potrdilo prehoda, ki ga uporablja IKE, in potrdilo, ki ga predstavi tisto, kar zaključi PEAP. Ena od njiju je v redu, druga pa je razlog, da se je odjemalec ustavil.

Dve identiteti, en poskus prijave

Potrdilo v profilu VPN pripada izmenjavi IKE: dokazuje, da je prehod tista stran, ki jo profil navaja, v skladu z nastavljeno politiko IKE. Potrdilo, ki tu ne uspe, pripada drugemu pogovoru, seji TLS, ki jo PEAP odpre s tistim, kar avtenticira uporabnika, kar je pogosto strežnik RADIUS, kot je NPS, in ne prehod sam. Tretje preverjanje, uporabnikove poverilnice, se zgodi znotraj te seje. Veljavno geslo ne more popraviti poteklega potrdila strežnika, veljavno potrdilo prehoda pa ne more jamčiti za končno točko PEAP.

To plastenje pojasnjuje, zakaj se napaka potrdila pojavi na mestu, kjer je bilo edino nastavljeno potrdilo tisto od prehoda. Pojasnjuje tudi, zakaj ponovna izdaja tega potrdila ničesar ne spremeni.

Berite vrstico dnevnika glede na stopnjo

Poiščite sporočilo, ki navaja razlog in datume. Pritožba o intervalu veljavnosti ob napaki subjekta pomeni, da je strežnik zavrnil potrdilo, ki ga je prejel, in ne, da je uporabnik zavrnil prijavo. Nato poiščite stopnjo: dnevnik charon v strongSwanu prikaže IKE_SA .* established preden se začne izmenjava EAP, zato napaka potrdila za to vrstico pripada identiteti EAP, medtem ko napaka pred njo kaže na prehod. Besedilo stopnje v podoknu povezave odjemalca Windows pove isto.

Preverite uro odjemalca, preden se dotaknete kateregakoli potrdila. Naprava, ki je za ure napačna, ustvari isto napako veljavnosti kot resnično poteklo potrdilo. Nastavitev ure je popravek za pet sekund, zamenjava potrdila, ki nikoli ni bilo težava, pa je izpad.

Ugotovite, katera končna točka zaključi PEAP

V zasnovi s prehodom in RADIUS-om prehod posreduje EAP in ga ne zaključi. Vtičnik eap-radius strongSwana izroči izmenjavo strežniku RADIUS, ki ima v lasti sejo TLS PEAP in njeno potrdilo. Povežite en neuspešen poskus v obeh dnevnikih in potrdite, kateri proces je dejansko izbral potrdilo za to sejo.

Za NPS mora biti potrdilo v shrambi lokalnega računalnika, imeti namen preverjanja pristnosti strežnika, ustrezati imenu, ki ga odjemalci pričakujejo, in biti berljivo za servisni račun. Microsoftove zahteve za potrdila za NPS naštevajo te pogoje. Drugi strežniki EAP imajo svoja pravila izbire, zato ne kopirajte posebnosti NPS v namestitev FreeRADIUS ali obratno. Pravilo, ki velja v obeh primerih, je, da končna točka, ki zaključi PEAP, poseduje potrdilo, ki ga boste spremenili.

Zamenjajte potrdilo tam, kjer se EAP konča

Obnovite ali zamenjajte potrdilo na končni točki, ki zaključi PEAP, s podprtim postopkom, ob ohranitvi namena preverjanja pristnosti strežnika in pričakovanega imena. Namestite celotno verigo tja, kjer jo storitev išče, in storitvi omogočite dostop do zasebnega ključa. Znova zaženite ali znova povežite storitev, ker mnoge storitve hranijo staro potrdilo v pomnilniku in ga še naprej predstavljajo. Datoteka, kopirana na stroj, ne dokazuje ničesar o tem, katero potrdilo storitev dejansko predstavi.

Spremembo potrdite tako, da naslednji poskus povežete z lastnim dnevnikom storitve, ali s pregledom potrdila, ki ga je predstavila seja. Če ta dnevnik še vedno kaže stari odtis, znova zagon ni učinkoval.

Ne predpostavljajte, da je najnovejša datoteka v mapi tista, ki se uporablja. Kopija s pravilnim imenom in napačnimi dovoljenji ne spremeni ničesar. Spremembo presojajte po predstavljeni identiteti, ne po časovnem žigu datoteke.

Česa ne storiti

Ne izklopite preverjanja PEAP in ne vsiljujte šibkejše notranje metode, da bi obšli napako. To spremeni politiko in odstrani lastnost preverjanja pristnosti strežnika, ki je poteklo potrdilo sploh ujela. Zamenjali bi delujoče preverjanje za delujočo povezavo, naslednje poteklo potrdilo pa bi prišlo brez česar koli, kar bi ga napovedalo.

Ne jemljite uspešne povezave drugega operacijskega sistema kot dokaz, da je potrdilo sprejemljivo. Tisti odjemalec morda uporablja drugo metodo EAP, drugo shrambo zaupanja ali sploh nobenega preverjanja strežnika, zato njegov uspeh ne pove ničesar o preverjanju, ki tu ni uspelo. Ohranite en nameren negativen test, na primer potrdilo z napačnim imenom ali nezaupanja vredno verigo, ki spodleti po pričakovanjih. Če ta test zdaj uspe, ste odstranili preverjanje, ne pa popravili potrdila. Zapišite, katera identiteta ni uspela, da naslednja oseba ne bi spet začela s potrdilom prehoda.