IKEv1 met XAuth en OTP: wat elk prompt vraagt
Een groeps-PSK, een XAuth-uitwisseling voor de gebruiker en een OTP-uitdaging zijn drie verschillende invoer. Koppel elke prompt aan zijn eigenaar voordat je nog een client installeert.
IKEv1 met PSK, XAuth en OTP vraagt niet om één ingewikkeld wachtwoord. Het stapelt een gedeelde sleutel tussen peers, een gebruikeruitwisseling en een tweede factor waarvan de backend bepaalt hoe die wordt gevraagd. Elke laag heeft zijn eigen eigenaar en zijn eigen foutmelding. Ze door elkaar halen zorgt dat mensen een eenmalige code opnieuw intypen in een veld dat een groepsgeheim opslaat.
Koppel elke prompt aan de laag die erom vraagt voordat je een andere client installeert of een referentie reset.
Drie geheimen, drie eigenaren
De vooraf gedeelde sleutel hoort bij de peer-relatie en wordt één keer ingesteld door wie beide uiteinden beheert. De gebruikersreferentie hoort bij de authenticatie-backend en wordt bij elke aanmelding gevalideerd. De tweede factor hoort bij een tokensysteem waarvan het antwoord bij elke poging verandert. Geen ervan vervangt een ander, en een implementatie die ze als één wachtwoord behandelt, faalt op de laag die niemand heeft gedocumenteerd.
Schrijf drie kolommen op: eigenaar, levensduur en de foutmelding die elk oplevert. Die tabel is het diagnosemiddel, niet de veldnamen van de client.
| 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: van de peer, niet van de persoon
In deze oude opzet authenticeert de vooraf gedeelde sleutel het gateway-paar, dus de aanmelding van de gebruiker vervangt hem nooit. Het is ook de waarde die het vaakst fout is op een manier die een algemene onderhandelingsfout geeft in plaats van een prompt. Als de tunnel faalt voordat er een gebruikersprompt verschijnt, zijn de sleutel of de voorstellen de verdachten.
Een gebruikersreferentie kan een fout in de eerste fase niet repareren. Hem roteren verspilt de enige referentie die je veilig kunt roteren en versterkt de verkeerde theorie.
XAuth: de oude gebruikeruitwisseling
XAuth voegt een gebruikersauthenticatie-uitwisseling toe bovenop de peer-authenticatie van IKEv1, en de gateway bepaalt welke backend die valideert. Afhankelijk van die backend kan de uitwisseling een directorywachtwoord, een RADIUS-referentie of een tokenantwoord accepteren. Het woord XAuth benoemt het transport van de uitwisseling, niet het type referentie.
Controleer naar welke backend het gateway-profiel wijst. Dat vertelt wat er van de gebruiker wordt gevraagd en wat een wachtwoordreset werkelijk verandert, en geen van beide is zichtbaar in een clientprofiel.
OTP: wat de backend ook vraagt
Sommige implementaties vragen na het wachtwoord om een aparte eenmalige code, andere definiëren een gecombineerd invoerformaat met een gedocumenteerd scheidingsteken. Beide bestaan, en het profiel voor je beslist welke. Een samenvoeging verzinnen omdat het op een andere locatie werkte, is de meest voorkomende manier om een inschrijvingstoken te verbranden. Alleen de documentatie van de gateway zelf beslist dit.
Gebruik het gedocumenteerde formaat met een client die de uitwisseling die de gateway biedt kan afronden.
Waar de grens van de client bijt
Fortinet documenteert dat FortiClient 7.4.4 en later IKEv1 voor IPsec-VPN's niet meer ondersteunen, wat een product- en versiegrens is en geen universele verwijdering, zoals de compatibiliteitsnotitie van FortiClient vastlegt. Ook andere clients zijn niet uitwisselbaar: OpenConnect en openfortivpn spreken specifieke gatewayprotocollen, geen willekeurige IKEv1-profielen. Controleer per stuk de IKE-versie, PSK-modus, XAuth-ondersteuning en het interactiemodel van de geïnstalleerde client. Een client die via een andere methode verbindt, heeft de oorspronkelijke eis niet bewezen.
IKEv1 is verouderd, dus een nieuwe uitrol op een niet-ondersteunde oude client is een kort leven beschoren. Vraag de gateway-eigenaar om een ondersteund migratiepad, inclusief hoe de tweede factor daar wordt afgehandeld.
Diagnose zonder de factor uit te schakelen
Scheid de fasen in het log: peer-onderhandeling, de gebruikeruitwisseling, het resultaat van de tweede factor en dan adres- en routetoewijzing. Noteer het component en de fase in plaats van de code in elk veld te proberen. De factor uitschakelen zodat een test slaagt, levert een tunnel op die niets bewijst over de implementatie.
Bewaar inschrijvingsgeheimen en de gedeelde sleutel in beschermde opslag volgens het proces van de organisatie. Een eenmalige code in een permanent bestand is een factor die opgehouden is er een te zijn.