IKEv1 met XAuth en OTP: wat elke aanwysing eintlik vra
’n Groep-PSK, ’n gebruikers-XAuth-uitruiling en ’n OTP-uitdaging is drie verskillende insette. Pas elke aanwysing by sy eienaar voordat jy nog ’n kliënt installeer.
IKEv1 met PSK, XAuth en OTP vra nie een ingewikkelde wagwoord nie. Dit stapel ’n gedeelde sleutel tussen eweknieë, ’n gebruikersuitruiling en ’n tweede faktor wat die backend besluit hoe om te vra. Elke laag het sy eie eienaar en sy eie foutboodskap. Om hulle te verwar, laat mense ’n eenmalige kode intik in ’n veld wat ’n groepsgeheim stoor.
Pas elke aanwysing by die laag wat dit vra voordat jy nog ’n kliënt installeer of ’n geloofsbrief herstel.
Drie geheime, drie eienaars
Die voorafgedeelde sleutel behoort aan die eweknie-verhouding en word een keer opgestel deur wie albei kante besit. Die gebruiker se geloofsbrief behoort aan die verifikasie-backend en word per aanmelding gevalideer. Die tweede faktor behoort aan ’n tekenstelsel waarvan die antwoord by elke poging verander. Nie een vervang ’n ander nie, en ’n ontplooiing wat hulle as een wagwoord behandel, misluk by die laag wat niemand gedokumenteer het nie.
Skryf drie kolomme neer: eienaar, leeftyd en die foutboodskap wat elkeen lewer. Daardie tabel is die diagnostiese instrument, en die kliënt se veldname is dit nie.
| 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: die eweknie, nie die persoon nie
Die voorafgedeelde sleutel verifieer die gw-paar in hierdie ou reëling, so die gebruiker se aanmelding vervang dit nooit nie. Dit is ook die waarde wat die waarskynlikste verkeerd is op ’n manier wat ’n algemene onderhandelingsfout eerder as ’n aanwysing lewer. Wanneer die tonnel misluk voordat enige gebruikersaanwysing verskyn, is die sleutel of die voorstelle die verdagtes.
’n Gebruikersgeloofsbrief kan nie ’n fase-een-fout herstel nie. Om dit te roteer mors die een geloofsbrief wat jy veilig kan roteer, en dit versterk die verkeerde teorie.
XAuth: die ou gebruikersuitruiling
XAuth voeg ’n gebruikersverifikasie-uitruiling bo-op die eweknie-verifikasie van IKEv1, en die gw besluit watter backend dit valideer. Afhangend van daardie backend kan die uitruiling ’n gids-wagwoord, ’n RADIUS-geloofsbrief of ’n tekenantwoord aanvaar. Die woord XAuth benoem die vervoer van die uitruiling, nie die tipe geloofsbrief nie.
Kyk na watter backend die gw-profiel wys. Dit sê vir jou waarvoor die gebruiker gevra sal word en wat ’n wagwoordherstel werklik verander, en nie een daarvan is in ’n kliëntprofiel sigbaar nie.
OTP: net wat die backend vra
Sommige ontplooiings vra ná die wagwoord ’n aparte eenmalige kode, en ander definieer ’n gekombineerde invoerformaat met ’n gedokumenteerde skeier. Albei bestaan, en die profiel voor jou besluit watter een. Om ’n samevoeging te bedink omdat dit by ’n ander werf gewerk het, is die algemeenste manier om ’n inskrywingsteken te verbrand. Die gw se eie dokumentasie is die enigste bron wat dit besleg.
Gebruik die gedokumenteerde formaat met ’n kliënt wat die uitruiling wat die gw bied, kan voltooi.
Waar die kliëntgrens byt
Fortinet dokumenteer dat FortiClient 7.4.4 en later IKEv1 vir IPsec-VPN's nie meer ondersteun nie, wat ’n produk- en weergawegrens is eerder as ’n universele verwydering, soos die FortiClient-versoenbaarheidsnota dit opteken. Ander kliënte is ook nie onderling verwisselbaar nie: OpenConnect en openfortivpn praat bepaalde gw-protokolle, nie willekeurige IKEv1-profiele nie. Kontroleer die geïnstalleerde kliënt se IKE-weergawe, PSK-modus, XAuth-ondersteuning en interaksiemodel afsonderlik. ’n Kliënt wat met ’n ander metode verbind, het nie die oorspronklike vereiste bewys nie.
IKEv1 is verouderd, so ’n nuwe uitrol op ’n onondersteunde ou kliënt is ’n kortstondige oplossing. Vra die gw-eienaar om ’n ondersteunde migrasiepad, insluitend hoe die tweede faktor daar hanteer sal word.
Diagnoseer sonder om die faktor af te skakel
Skei die fases in die log: eweknie-onderhandeling, die gebruikersuitruiling, die tweede-faktor-resultaat, dan adres- en roetetoekenning. Teken die komponent en die fase aan eerder as om die kode in elke veld te probeer. Om die faktor af te skakel sodat ’n toets slaag, lewer ’n tonnel wat niks oor die ontplooiing bewys nie.
Hou inskrywingsgeheime en die gedeelde sleutel in beskermde berging volgens die organisasie se proses. ’n Eenmalige kode in ’n blywende lêer is ’n faktor wat opgehou het om een te wees.