IKEv2-utvekslinga verkar, så mislukkast autentiseringa: kvar du skal leite

Ein klient som mottek eit IKEv2-svar, har prova at gatewayen er tilgjengeleg, at begge partar kan forhandle om eit framlegg, og at den første nøkkelutvekslinga er fullført. Han har ikkje prova at nokon er autentisert. Den neste utvekslinga ber identitetar, sertifikat eller EAP, og det er der sambandet vanlegvis stoppar. Å lese kva av desse sjekkane som mislukkast er heile diagnosen, og feilmeldinga åleine seier det sjeldan.

Sjekk 1: les trinnet, ikkje meldinga

Ei avvising kan kome frå tre stader: klienten som avviser identiteten til serveren, gatewayen som avviser beviset til klienten, og ein ekstern autentiseringsteneste som avviser kontoen.

Kvar produserer ei anna logglinje på ein annan maskin, og kvar har ei anna løysing. Ei avvising av serversertifikatet på klientsida er eit tillits- eller namnebolkproblem på klienten; ei avvising av klientsertifikatet på gatewaysida er eit tillitsproblem på gatewayen; ein EAP-feil er eit konto- eller backendproblem. Meldinga du ser er vanlegvis samandraget til klienten av ein av desse, og difor er gatewayloggen like viktig som klienten sin.

Sjekk 2: kva identitet vart sjekka

Ein klient kan avvise serversertifikatet eller den forventa identiteten før nokon brukarlegitimasjon vert tilboden, og ei fungerande serveradresse er ikkje ei erstatning for den sjekken. Identifikatoren klienten forventar må samsvare med det gatewayen presenterer, som er eit konfigurasjonsfaktum og ikkje eit nettverksfaktum.

I strongSwan-termar er det rightid på klienten og eigen identitet til gatewayen på den andre sida, og eit avvik mislukkast før EAP i det heile er nemnt.

Gatewayen kan separat avvise klientsertifikatet, nøkkelbeviset eller kontautentiseringa, og desse tre er ikkje utbyttbare. Å nullstille passordet til ein brukar fornyar ikkje eit einingssertifikat, og å installere eit einingssertifikat på nytt rettar ikkje ein feil serveridentitet. Ved sertifikatfeil, sjekk klokka fyrst, deretter tillitskjeda, så den forventa identifikatoren; ein klient der klokka avvik med nokre minutt, feilar ein gyldighetssjekk som ser ut som ein tillitsfeil. swanctl --list-certs i begge endar viser kva kvar side faktisk har.

Sjekk 3: om EAP er involvert

Klienten og serveren må bli samde om ein støtta metode, og backend må godta identiteten som vert oppgitt.

Eit brukarnamn kan trenge eit domenesuffiks eller eit bestemt kontoformat som utrullinga krev, og formatet er dokumentert og ikkje gjettbart. Å oppgi dei dokumenterte felta til operatøren er raskare enn å prøve variantar, og det unngår eit andre problem: gjentekne forsøk kan utløyse kontolåsing, som deretter skjuler det opphavlege trinnet bak ein ny feil. Om metoden er EAP-MSCHAPv2 mot ein katalog, kan feilen høyre til katalogen og ikkje til VPN-en.

Ikkje test identitetsproblem ved å slå av identitetssjekkar. Det gjer ein diagnostiserbar feil til ein udiagnostiserbar og lèt sambandet stå svakare enn før.

Sjekk 4: kva som skjer etter ei vellukka innlogging

Når IKE_AUTH er fullført, avgjer CHILD_SA-forhandlinga kva trafikkveljarar som vert installerte, og det er der eit samband kan lukkast og likevel ikkje sleppe noko gjennom.

Ei nyleg fungerande innlogging avdekkjer ofte eit veljar- eller ruteproblem som tidlegare var skjult bak autentiseringsfeilen. Om tunnelen kjem opp og eit program framleis ikkje når målet, sjå på dei forhandla veljarane og rutene i staden for identiteten igjen. Å endre identitetsinnstillingar på det tidspunktet treff feil trinn og øydelegg vanlegvis ei fungerande innlogging. Stadfest med swanctl --list-sas, som viser borna og veljarane deira separat frå IKE SA.

Sjekk 5: kva du skal gje til støtte

Ei reinska tidslinje og den presise avvisinga er verd meir enn ein full diagnostisk eksport, og eksporten kan innehalde private nøklar eller legitimasjon du ikkje bør dele.

Noter tida med tidssona, versjonane til klient og gateway, metoden, identitetsstrengen som vart tilboden i staden for passordet, og det nøyaktige trinnet som avviste han. strongSwan IKEv2-konfigurasjonsdokumentasjonen skildrar identitets- og EAP-innstillingane som avgjer desse resultata, og det er referansen du bør lese før du endrar eit felt. Endre så éin ting og test ein ny tilkopling på nytt, fordi ei bufra økt vil fortelje deg om den gamle konfigurasjonen.