IKEv2-udveksling virker, så fejler godkendelsen: hvor

En klient, der modtager et IKEv2-svar, har bevist, at gatewayen kan nås, at begge parter kan forhandle et forslag, og at den indledende nøgleudveksling blev gennemført. Den har ikke bevist, at nogen er godkendt. Den næste udveksling bærer identiteter, certifikater eller EAP, og det er normalt der, forbindelsen stopper. At læse, hvilken af disse kontroller der fejlede, er hele diagnosen, og fejlmeddelelsen alene siger det sjældent.

Kontrol 1: læs fasen, ikke meddelelsen

Der er tre steder, en afvisning kan komme fra: klienten afviser serverens identitet, gatewayen afviser klientens bevis, og en ekstern godkendelsestjeneste afviser kontoen.

Hver giver en anden loglinje på en anden maskine, og hver har sin egen rettelse. En afvisning af servercertifikatet på klientsiden er et tillids- eller navneproblem på klienten; en afvisning af klientcertifikatet på gatewaysiden er et tillidsproblem på gatewayen; en EAP-fejl er et konto- eller backendproblem. Den meddelelse, du ser, er normalt klientens resumé af en af disse, og derfor er gatewayens log lige så vigtig som klientens.

Kontrol 2: hvilken identitet blev kontrolleret

En klient kan afvise serverens certifikat eller den forventede identitet, før nogen brugeroplysning tilbydes, og en fungerende serveradresse er ikke en erstatning for den kontrol. Den identifikator, klienten forventer, skal matche det, gatewayen præsenterer, hvilket er et konfigurationsforhold og ikke et netværksforhold.

I strongSwan-termer er det rightid på klienten og gatewayens egen identitet på den anden side, og en uoverensstemmelse fejler, før EAP overhovedet drøftes.

Gatewayen kan separat afvise klientens certifikat, dens nøglebevis eller dens kontogodkendelse, og de tre er ikke udskiftelige. Nulstilling af en brugeradgangskode fornyer ikke et enhedscertifikat, og geninstallation af et enhedscertifikat retter ikke en forkert serveridentitet. Ved certifikatfejl skal du først kontrollere uret, derefter tillidskæden, derefter den forventede identifikator; en klient, hvis ur går få minutter forkert, fejler en gyldighedskontrol, der ligner en tillidsfejl. swanctl --list-certs i begge ender viser, hvad hver side faktisk har.

Kontrol 3: hvis EAP er i spil

Klienten og serveren skal blive enige om en understøttet metode, og backenden skal acceptere den identitet, der leveres.

Et brugernavn kan kræve et domænesuffiks eller et bestemt kontoformat, som udrulningen kræver, og formatet er dokumenteret frem for gætteligt. At levere operatørens dokumenterede felter er hurtigere end at prøve varianter, og det undgår et andet problem: gentagne forsøg kan udløse en kontolåsning, som derefter skjuler den oprindelige fase bag en ny fejl. Hvis metoden er EAP-MSCHAPv2 mod en mappe, kan fejlen tilhøre mappen og slet ikke VPN’en.

Test ikke identitetsproblemer ved at slå identitetskontroller fra. Det gør en diagnosticerbar fejl til en udiagnosticerbar og efterlader forbindelsen svagere end før.

Kontrol 4: hvad der sker efter et vellykket login

Når IKE_AUTH er fuldført, afgør CHILD_SA-forhandlingen, hvilke trafikvælgere der installeres, og det er her, en forbindelse kan lykkes og stadig ikke sende noget.

Et nyt fungerende login afslører ofte et vælger- eller ruteproblem, der tidligere var skjult bag godkendelsesfejlen. Hvis tunnelen kommer op, og et program stadig ikke kan nå sit mål, så se på de forhandlede vælgere og ruterne i stedet for på identiteten igen. At ændre identitetsindstillinger på det tidspunkt rammer den forkerte fase og ødelægger normalt et fungerende login. Bekræft med swanctl --list-sas, som viser børnene og deres vælgere adskilt fra IKE SA.

Kontrol 5: hvad du skal give supporten

En renset tidslinje og den præcise afvisning er mere værd end en fuld diagnostisk eksport, og eksporten kan indeholde private nøgler eller legitimationsoplysninger, som du ikke bør dele.

Notér tiden med tidszonen, klientens og gatewayens versioner, metoden, den identitetsstreng, der blev tilbudt i stedet for adgangskoden, og den præcise fase, der afviste den. strongSwan-dokumentationen for IKEv2-konfiguration beskriver de identitets- og EAP-indstillinger, der afgør disse udfald, og det er den reference, du skal læse, før du ændrer et felt. Ændr derefter én ting, og test en ny forbindelse igen, for en cachet session vil fortælle dig om den gamle konfiguration.