IKEv2-utvekslingen virker, så mislykkes autentiseringen: hvor du skal lete

En klient som mottar et IKEv2-svar, har bevist at gatewayen er tilgjengelig, at begge parter kan forhandle om et forslag, og at den første nøkkelutvekslingen er fullført. Den har ikke bevist at noen er autentisert. Den neste utvekslingen bærer identiteter, sertifikater eller EAP, og det er der forbindelsen vanligvis stopper. Å lese hvilken av disse sjekkene som mislyktes er hele diagnosen, og feilmeldingen alene sier det sjelden.

Sjekk 1: les trinnet, ikke meldingen

En avvisning kan komme fra tre steder: klienten som avviser serverens identitet, gatewayen som avviser klientens bevis, og en ekstern autentiseringstjeneste som avviser kontoen.

Hver produserer en annen logglinje på en annen maskin, og hver har en annen løsning. En avvisning av serverens sertifikat på klientsiden er et tillits- eller navneproblem på klienten; en avvisning av klientens sertifikat på gatewaysiden er et tillitsproblem på gatewayen; en EAP-feil er et konto- eller backendproblem. Meldingen du ser er vanligvis klientens sammendrag av en av disse, og derfor er gatewayloggen like viktig som klientens.

Sjekk 2: hvilken identitet ble sjekket

En klient kan avvise serverens sertifikat eller den forventede identiteten før noen brukerlegitimasjon tilbys, og en fungerende serveradresse er ikke en erstatning for den sjekken. Identifikatoren klienten forventer må samsvare med det gatewayen presenterer, som er et konfigurasjonsfaktum og ikke et nettverksfaktum.

I strongSwan-termer er det rightid på klienten og gatewayens egen identitet på den andre siden, og et avvik mislykkes før EAP i det hele tatt diskuteres.

Gatewayen kan separat avvise klientens sertifikat, nøkkelbeviset eller kontautentiseringen, og disse tre er ikke utbyttbare. Å tilbakestille en brukers passord fornyer ikke et enhetssertifikat, og å installere et enhetssertifikat på nytt retter ikke en feil serveridentitet. Ved sertifikatfeil, sjekk klokken først, deretter tillitskjeden, så den forventede identifikatoren; en klient hvis klokke avviker med noen minutter, feiler en gyldighetssjekk som ser ut som en tillitsfeil. swanctl --list-certs i begge ender viser hva hver side faktisk har.

Sjekk 3: hvis EAP er involvert

Klienten og serveren må bli enige om en støttet metode, og backend må godta identiteten som oppgis.

Et brukernavn kan trenge et domenesuffiks eller et bestemt kontformat som utrullingen krever, og formatet er dokumentert og ikke gjettbart. Å oppgi operatørens dokumenterte felt er raskere enn å prøve varianter, og det unngår et andre problem: gjentatte forsøk kan utløse kontolåsing, som deretter skjuler det opprinnelige trinnet bak en ny feil. Hvis metoden er EAP-MSCHAPv2 mot en katalog, kan feilen tilhøre katalogen og ikke VPN-en.

Ikke test identitetsproblemer ved å slå av identitetssjekker. Det gjør en diagnostiserbar feil til en udiagnostiserbar og etterlater forbindelsen svakere enn før.

Sjekk 4: hva som skjer etter en vellykket innlogging

Når IKE_AUTH er fullført, avgjør CHILD_SA-forhandlingen hvilke trafikkvelgere som installeres, og det er der en forbindelse kan lykkes og likevel ikke slippe noe gjennom.

En nylig fungerende innlogging avdekker ofte et velger- eller ruteproblem som tidligere var skjult bak autentiseringsfeilen. Hvis tunnelen kommer opp og et program fortsatt ikke når målet, se på de forhandlede velgerne og rutene i stedet for identiteten igjen. Å endre identitetsinnstillinger på det tidspunktet treffer feil trinn og ødelegger vanligvis en fungerende innlogging. Bekreft med swanctl --list-sas, som viser barna og velgerne deres separat fra IKE SA.

Sjekk 5: hva du skal gi til support

En renset tidslinje og den presise avvisningen er verdt mer enn en full diagnostisk eksport, og eksporten kan inneholde private nøkler eller legitimasjon du ikke bør dele.

Noter tiden med tidssonen, klient- og gatewayversjonene, metoden, identitetsstrengen som ble tilbudt i stedet for passordet, og det nøyaktige trinnet som avviste den. strongSwan IKEv2-konfigurasjonsdokumentasjonen beskriver identitets- og EAP-innstillingene som avgjør disse resultatene, og det er referansen du bør lese før du endrer et felt. Endre så én ting og test en ny tilkobling på nytt, fordi en bufret økt vil fortelle deg om den gamle konfigurasjonen.