IKEv1 med XAuth og OTP: hva hver ledetekst spør om

IKEv1 med PSK, XAuth og OTP ber ikke om ett komplisert passord. Det stabler en delt nøkkel mellom peers, en brukerutveksling og en andre faktor som backend bestemmer hvordan den skal spørres om. Hvert lag har sin egen eier og sin egen feilmelding. Å blande dem gjør at folk skriver inn en engangskode på nytt i et felt som lagrer en gruppehemmelighet.

Koble hver ledetekst til laget som spør om den, før du installerer en annen klient eller tilbakestiller en påloggingsinformasjon.

Tre hemmeligheter, tre eiere

Den forhåndsdelt nøkkelen tilhører peer-forholdet og konfigureres én gang av den som styrer begge ender. Brukerens påloggingsinformasjon tilhører autentiseringsbackend og valideres ved hver innlogging. Den andre faktoren tilhører et tokensystem der svaret endres ved hvert forsøk. Ingen erstatter en annen, og en utrulling som behandler dem som ett passord, feiler på laget ingen har dokumentert.

Skriv ned tre kolonner: eier, levetid og feilmeldingen hver av dem gir. Den tabellen er diagnoseverktøyet, ikke feltnavnene i klienten.

PSK: peerens, ikke personens

I denne eldre ordningen autentiserer den forhåndsdelt nøkkelen gateway-paret, så brukerens innlogging erstatter den aldri. Det er også verdien som oftest er feil på en måte som gir en generell forhandlingsfeil i stedet for en ledetekst. Når tunnelen feiler før noen brukerledetekst vises, er nøkkelen eller forslagene de mistenkte.

Brukerens påloggingsinformasjon kan ikke reparere en feil i første fase. Å rotere den sløser bort den eneste påloggingsinformasjonen du trygt kan rotere, og forsterker den gale teorien.

XAuth: den eldre brukerutvekslingen

XAuth legger til en utveksling for brukerautentisering oppå peer-autentiseringen i IKEv1, og gatewayen avgjør hvilken backend som validerer den. Avhengig av den backend kan utvekslingen godta et katalogpassord, en RADIUS-påloggingsinformasjon eller et tokensvar. Ordet XAuth navngir transporten i utvekslingen, ikke typen påloggingsinformasjon.

Sjekk hvilken backend gatewayprofilen peker på. Det forteller hva brukeren blir spurt om og hva en passordtilbakestilling faktisk endrer, og ingen av delene er synlige i en klientprofil.

OTP: akkurat det backend ber om

Noen utrullinger ber om en egen engangskode etter passordet, andre definerer et kombinert inndataformat med en dokumentert separator. Begge finnes, og profilen foran deg avgjør hvilken. Å finne opp en sammenslåing fordi den virket på et annet sted, er den vanligste måten å brenne et registreringstoken. Bare gatewayens egen dokumentasjon avgjør saken.

Bruk det dokumenterte formatet med en klient som kan fullføre utvekslingen gatewayen tilbyr.

Der klientgrensen biter

Fortinet dokumenterer at FortiClient 7.4.4 og nyere ikke lenger støtter IKEv1 for IPsec-VPN, noe som er en produkt- og versjonsgrense og ikke en universell fjerning, slik FortiClients kompatibilitetsmerknad registrerer. Heller ikke andre klienter er utskiftbare: OpenConnect og openfortivpn snakker bestemte gatewayprotokoller, ikke vilkårlige IKEv1-profiler. Sjekk IKE-versjon, PSK-modus, XAuth-støtte og interaksjonsmodell for den installerte klienten hver for seg. En klient som kobler til med en annen metode, har ikke bevist det opprinnelige kravet.

IKEv1 er utdatert, så en ny utrulling bygget på en gammel klient uten støtte er en kortlivet løsning. Be gatewayeieren om en støttet migreringsvei, inkludert hvordan den andre faktoren skal håndteres der.

Diagnostisere uten å slå av faktoren

Skill trinnene i loggen: peer-forhandling, brukerutvekslingen, resultatet av den andre faktoren og deretter tildeling av adresse og rute. Noter komponenten og trinnet i stedet for å prøve koden i hvert felt. Å slå av faktoren så en test går gjennom, gir en tunnel som ikke beviser noe om utrullingen.

Oppbevar registreringshemmeligheter og den delte nøkkelen i beskyttet lagring etter organisasjonens prosess. En engangskode i en permanent fil er en faktor som har sluttet å være en faktor.