IKEv2-utbytet fungerar, sedan misslyckas autentiseringen: var du ska leta

En klient som får ett IKEv2-svar har bevisat att gatewayen är nåbar, att båda parter kan förhandla om ett förslag och att det första nyckelutbytet slutfördes. Den har inte bevisat att någon är autentiserad. Nästa utbyte bär identiteter, certifikat eller EAP, och det är där anslutningen vanligtvis stannar. Att läsa vilken av dessa kontroller som misslyckades är hela diagnosen, och felmeddelandet ensamt säger det sällan.

Kontroll 1: läs fasen, inte meddelandet

Ett avvisande kan komma från tre ställen: klienten som avvisar serverns identitet, gatewayen som avvisar klientens bevis och en extern autentiseringstjänst som avvisar kontot.

Var och en producerar en annan logglinje på en annan maskin, och var och en har en annan åtgärd. Ett avvisande av serverns certifikat på klientsidan är ett förtroende- eller namngivningsproblem på klienten; ett avvisande av klientens certifikat på gatewaysidan är ett förtroendeproblem på gatewayen; ett EAP-fel är ett konto- eller backendproblem. Meddelandet du ser är vanligtvis klientens sammanfattning av ett av dessa, och därför är gatewayloggen lika viktig som klientens.

Kontroll 2: vilken identitet kontrollerades

En klient kan avvisa serverns certifikat eller den förväntade identiteten innan några användaruppgifter erbjuds, och en fungerande serveradress ersätter inte den kontrollen. Den identitet klienten förväntar sig måste stämma med det gatewayen presenterar, vilket är ett konfigurationsfaktum och inte ett nätverksfaktum.

I strongSwan-termer är det rightid på klienten och gatewayens egen identitet på andra sidan, och en avvikelse misslyckas innan EAP ens diskuteras.

Gatewayen kan separat avvisa klientens certifikat, dess nyckelbevis eller kontots autentisering, och dessa tre är inte utbytbara. Att återställa en användares lösenord förnyar inte ett enhetscertifikat, och att installera om ett enhetscertifikat åtgärdar inte en felaktig serveridentitet. Vid certifikatfel, kontrollera klockan först, sedan förtroendekedjan och till sist den förväntade identiteten; en klient vars klocka avviker några minuter misslyckas i en giltighetskontroll som ser ut som ett förtroendefel. swanctl --list-certs i båda ändar visar vad varje sida faktiskt har.

Kontroll 3: om EAP är inblandat

Klienten och servern måste komma överens om en metod som stöds, och backend måste acceptera den identitet som anges.

Ett användarnamn kan behöva ett domänsuffix eller ett specifikt kontformat som distributionen kräver, och formatet är dokumenterat och inte gissningsbart. Att ange operatörens dokumenterade fält är snabbare än att prova varianter, och det undviker ett andra problem: upprepade försök kan utlösa kontolåsning, som sedan döljer det ursprungliga steget bakom ett nytt fel. Om metoden är EAP-MSCHAPv2 mot en katalog kan felet tillhöra katalogen och inte VPN:en.

Testa inte identitetsproblem genom att stänga av identitetskontroller. Det gör ett diagnostiserbart fel odiagnostiserbart och lämnar anslutningen svagare än tidigare.

Kontroll 4: vad som händer efter en lyckad inloggning

När IKE_AUTH är klart avgör CHILD_SA-förhandlingen vilka trafikväljare som installeras, och det är där en anslutning kan lyckas och ändå inte släppa igenom något.

En nyligen fungerande inloggning avslöjar ofta ett väljar- eller routproblem som tidigare var dolt bakom autentiseringsfelet. Om tunneln kommer upp och ett program fortfarande inte når sitt mål, titta på de förhandlade väljarna och rutterna i stället för identiteten igen. Att ändra identitetsinställningar vid det laget träffar fel steg och bryter vanligtvis en fungerande inloggning. Bekräfta med swanctl --list-sas, som visar barnen och deras väljare separat från IKE SA.

Kontroll 5: vad du ska ge till supporten

En rensad tidslinje och det exakta avvisandet är värda mer än en fullständig diagnostisk export, och exporten kan innehålla privata nycklar eller inloggningsuppgifter som du inte bör dela.

Anteckna tiden med tidszonen, klient- och gatewayversionerna, metoden, identitetssträngen som erbjöds i stället för lösenordet, och det exakta steget som avvisade den. strongSwan IKEv2-konfigurationsdokumentationen beskriver identitets- och EAP-inställningarna som avgör dessa utfall, och det är referensen du bör läsa innan du ändrar ett fält. Ändra sedan en sak och testa en ny anslutning igen, eftersom en cachad session berättar om den gamla konfigurationen.