IKEv1 med XAuth og OTP: hvad hvert felt spørger om
En gruppe-PSK, en bruger-XAuth-udveksling og en OTP-udfordring er tre forskellige input. Knyt hvert felt til sin ejer, før du installerer endnu en klient.
IKEv1 med PSK, XAuth og OTP beder ikke om én kompliceret adgangskode. Den lægger en fælles nøgle mellem parterne, en brugerudveksling og en anden faktor oven på hinanden, og backend bestemmer, hvordan den anden faktor skal efterspørges. Hvert lag har sin egen ejer og sin egen fejlmeddelelse. Forveksler man dem, ender folk med at skrive en engangskode i et felt, der gemmer en gruppehemmelighed.
Knyt hvert felt til det lag, der spørger efter det, før du installerer endnu en klient eller nulstiller en legitimationsoplysning.
Tre hemmeligheder, tre ejere
Den fordelte nøgle hører til partforholdet og konfigureres én gang af den, der ejer begge ender. Brugerens legitimationsoplysning hører til godkendelses-backenden og valideres ved hvert login. Den anden faktor hører til et tokensystem, hvis svar ændrer sig ved hvert forsøg. Ingen af dem erstatter en anden, og en udrulning, der behandler dem som én adgangskode, fejler i det lag, ingen har dokumenteret.
Skriv tre kolonner ned: ejer, levetid og den fejlmeddelelse, hver især giver. Den tabel er diagnostikværktøjet, og klientens feltnavne er det ikke.
| Layer | Owner | Lifetime |
|---|---|---|
| Pre-shared key | Peer configuration | Until operators change it |
| XAuth credential | Authentication backend | Per session, per policy |
| One-time code | Token system | Single use |
PSK: parten, ikke personen
Den fordelte nøgle godkender gateway-parret i denne ældre opsætning, så brugerens login erstatter den aldrig. Det er også den værdi, der oftest er forkert på en måde, der giver en generisk forhandlingsfejl i stedet for et felt. Når tunnelen fejler, før noget brugerfelt vises, er nøglen eller forslagene de mistænkte.
En brugers legitimationsoplysning kan ikke reparere en fejl i fase et. At rotere den spilder den ene legitimationsoplysning, du sikkert kan rotere, og styrker den forkerte teori.
XAuth: den ældre brugerudveksling
XAuth tilføjer en brugerautentificeringsudveksling oven på partautentificeringen i IKEv1, og gatewayen bestemmer, hvilken backend der validerer den. Afhængigt af den backend kan udvekslingen acceptere en mappe-adgangskode, en RADIUS-legitimationsoplysning eller et tokensvar. Ordet XAuth navngiver udvekslingens transport, ikke typen af legitimationsoplysning.
Kontroller, hvilken backend gateway-profilen peger på. Det fortæller, hvad brugeren bliver spurgt om, og hvad en nulstilling af adgangskoden faktisk ændrer, og ingen af delene ses i en klientprofil.
OTP: hvad end backenden beder om
Nogle udrulninger beder om en separat engangskode efter adgangskoden, og andre definerer et kombineret inputformat med en dokumenteret separator. Begge findes, og profilen foran dig afgør hvilket. At opfinde en sammenkædning, fordi den virkede et andet sted, er den mest almindelige måde at brænde et tilmeldings-token. Gatewayens egen dokumentation er den eneste kilde, der afgør det.
Brug det dokumenterede format med en klient, der kan gennemføre den udveksling, gatewayen tilbyder.
Hvor klientgrænsen bider
Fortinet dokumenterer, at FortiClient 7.4.4 og nyere ikke længere understøtter IKEv1 til IPsec VPN, hvilket er en produkt- og versionsgrænse og ikke en universel fjernelse, som FortiClient-kompatibilitetsnotat registrerer. Andre klienter er heller ikke udskiftelige: OpenConnect og openfortivpn taler bestemte gateway-protokoller, ikke vilkårlige IKEv1-profiler. Kontroller den installerede klients IKE-version, PSK-tilstand, XAuth-understøttelse og interaktionsmodel hver for sig. En klient, der forbinder med en anden metode, har ikke bevist det oprindelige krav.
IKEv1 er forældet, så en ny udrulning på en ikke-understøttet gammel klient er en kortvarig løsning. Bed gatewayens ejer om en understøttet migreringsvej, inklusive hvordan den anden faktor håndteres der.
Diagnose uden at slå faktoren fra
Adskil stadierne i loggen: partforhandling, brugerudvekslingen, resultatet af den anden faktor, derefter tildeling af adresse og rute. Notér komponenten og stadiet i stedet for at prøve koden i hvert felt. At slå faktoren fra, så en test består, giver en tunnel, der ikke beviser noget om udrulningen.
Opbevar tilmeldingshemmeligheder og den fælles nøgle i beskyttet lager efter organisationens proces. En engangskode i en vedvarende fil er en faktor, der er holdt op med at være det.