IKEv1 cu XAuth și OTP: ce cere fiecare prompt
O PSK de grup, un schimb XAuth de utilizator și o provocare OTP sunt trei intrări diferite. Asociază fiecare prompt proprietarului său înainte de a instala alt client.
IKEv1 cu PSK, XAuth și OTP nu cere o singură parolă complicată. Suprapune o cheie partajată între peeri, un schimb de utilizator și un al doilea factor a cărui modalitate de solicitare este decisă de backend. Fiecare strat are proprietarul și mesajul său de eșec. Confundarea lor îi face pe oameni să reintroducă un cod de unică folosință într-un câmp care stochează un secret de grup.
Asociază fiecare prompt stratului care îl cere înainte de a instala alt client sau de a reseta o acreditare.
Trei secrete, trei proprietari
Cheia prepartajată aparține relației dintre peeri și este configurată o singură dată de cine administrează ambele capete. Acreditarea utilizatorului aparține backendului de autentificare și este validată la fiecare autentificare. Al doilea factor aparține unui sistem de tokenuri al cărui răspuns se schimbă la fiecare încercare. Niciunul nu îl înlocuiește pe altul, iar o implementare care le tratează ca o singură parolă eșuează la stratul pe care nimeni nu l-a documentat.
Notează trei coloane: proprietar, durată de viață și mesajul de eșec pe care îl produce fiecare. Acel tabel este instrumentul de diagnostic, nu numele câmpurilor din 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: al peerului, nu al persoanei
În această aranjare veche, cheia prepartajată autentifică perechea de gateway-uri, așa că autentificarea utilizatorului nu o înlocuiește niciodată. Este și valoarea cel mai probabil greșită într-un mod care produce o eroare generică de negociere în loc de un prompt. Când tunelul eșuează înainte să apară vreun prompt de utilizator, suspecții sunt cheia sau propunerile.
O acreditare de utilizator nu poate repara un eșec al primei faze. Rotirea ei irosește singura acreditare pe care o poți roti în siguranță și întărește teoria greșită.
XAuth: schimbul vechi de utilizator
XAuth adaugă un schimb de autentificare a utilizatorului peste autentificarea de peer din IKEv1, iar gateway-ul decide care backend îl validează. În funcție de acel backend, schimbul poate accepta o parolă de director, o acreditare RADIUS sau un răspuns de token. Cuvântul XAuth numește transportul schimbului, nu tipul de acreditare.
Verifică spre ce backend indică profilul gateway-ului. Asta îți spune ce i se va cere utilizatorului și ce schimbă de fapt resetarea parolei, iar niciuna dintre ele nu se vede într-un profil de client.
OTP: orice cere backendul
Unele implementări cer un cod de unică folosință separat după parolă, iar altele definesc un format de intrare combinat cu un separator documentat. Ambele există, iar profilul din fața ta decide care. Inventarea unei concatenări pentru că a funcționat în altă parte este cea mai obișnuită cale de a consuma un token de înrolare. Documentația gateway-ului însuși este singura sursă care lămurește.
Folosește formatul documentat cu un client care poate finaliza schimbul oferit de gateway.
Unde mușcă granița clientului
Fortinet documentează că FortiClient 7.4.4 și versiunile ulterioare nu mai acceptă IKEv1 pentru VPN-urile IPsec, ceea ce este o graniță de produs și versiune, nu o eliminare universală, după cum consemnează nota de compatibilitate FortiClient. Nici ceilalți clienți nu sunt interschimbabili: OpenConnect și openfortivpn vorbesc protocoale de gateway anume, nu profiluri IKEv1 arbitrare. Verifică individual versiunea IKE, modul PSK, suportul XAuth și modelul de interacțiune al clientului instalat. Un client care se conectează prin altă metodă nu a dovedit cerința inițială.
IKEv1 este învechit, așa că o lansare nouă construită pe un client vechi neacceptat este o soluție de scurtă durată. Cere proprietarului gateway-ului o cale de migrare acceptată, inclusiv cum va fi tratat acolo al doilea factor.
Diagnosticarea fără a dezactiva factorul
Separă etapele în jurnal: negocierea peerilor, schimbul de utilizator, rezultatul celui de-al doilea factor, apoi alocarea adresei și a rutei. Notează componenta și etapa în loc să încerci codul în fiecare câmp. Dezactivarea factorului ca să treacă un test produce un tunel care nu dovedește nimic despre implementare.
Păstrează secretele de înrolare și cheia partajată în stocare protejată, conform procesului organizației. Un cod de unică folosință într-un fișier permanent este un factor care a încetat să mai fie factor.