IKEv1 ar PSK, XAuth un OTP neprasa vienu sarežģītu paroli. Tas slāņo koplietotu atslēgu starp vienaudžiem, lietotāja apmaiņu un otru faktoru, kura pieprasīšanas veidu nosaka backend. Katram slānim ir savs īpašnieks un savs kļūdas ziņojums. To sajaukšana liek cilvēkiem no jauna ievadīt vienreizēju kodu laukā, kurā glabājas grupas noslēpums.

Piesaistiet katru uzvedni slānim, kas to pieprasa, pirms instalējat citu klientu vai atiestatāt akreditācijas datus.

Trīs noslēpumi, trīs īpašnieki

Koplietotā atslēga pieder vienaudžu attiecībām un tiek konfigurēta vienreiz to, kas pārvalda abus galus. Lietotāja akreditācijas dati pieder autentifikācijas backendam un tiek pārbaudīti katrā pieteikumā. Otrais faktors pieder žetonu sistēmai, kuras atbilde mainās katrā mēģinājumā. Neviens neaizstāj citu, un izvietojums, kas tos uzskata par vienu paroli, sabrūk slānī, kuru neviens nav dokumentējis.

Pierakstiet trīs kolonnas: īpašnieks, darbības laiks un kļūdas ziņojums, ko katrs rada. Diagnostikas rīks ir šī tabula, nevis lauku nosaukumi klientā.

LayerOwnerLifetime
Pre-shared keyPeer configurationUntil operators change it
XAuth credentialAuthentication backendPer session, per policy
One-time codeToken systemSingle use

PSK: vienaudža, nevis personas

Šajā vecajā izkārtojumā koplietotā atslēga autentificē vārteju pāri, tāpēc lietotāja pieteikšanās to nekad neaizstāj. Tā ir arī vērtība, kas visbiežāk ir nepareiza tā, ka rodas vispārīga sarunu kļūda, nevis uzvedne. Kad tunelis sabrūk pirms jebkuras lietotāja uzvednes parādīšanās, aizdomās turamie ir atslēga vai priekšlikumi.

Lietotāja akreditācijas dati nevar salabot pirmās fāzes kļūmi. To rotācija iztērē vienīgos datus, ko varat droši rotēt, un pastiprina nepareizo teoriju.

XAuth: vecā lietotāja apmaiņa

XAuth pievieno lietotāja autentifikācijas apmaiņu virs IKEv1 vienaudža autentifikācijas, un vārteja izlemj, kurš backends to pārbauda. Atkarībā no šī backenda apmaiņa var pieņemt direktorija paroli, RADIUS akreditācijas datus vai žetona atbildi. Vārds XAuth nosauc apmaiņas transportu, nevis akreditācijas datu veidu.

Pārbaudiet, uz kuru backend vērsta vārtejas profils. Tas pasaka, kas lietotājam tiks prasīts un ko paroles atiestatīšana patiešām maina, un neviens no tiem nav redzams klienta profilā.

OTP: lai ko prasa backends

Daži izvietojumi pēc paroles prasa atsevišķu vienreizēju kodu, citi definē apvienotu ievades formātu ar dokumentētu atdalītāju. Pastāv abi, un profils jums priekšā izlemj, kurš. Savienošanas izgudrošana tāpēc, ka tā strādāja citur, ir visizplatītākais veids, kā iztērēt reģistrācijas žetonu. To izšķir tikai pašas vārtejas dokumentācija.

Izmantojiet dokumentēto formātu ar klientu, kas spēj pabeigt vārtejas piedāvāto apmaiņu.

Kur iekod klienta robeža

Fortinet dokumentē, ka FortiClient 7.4.4 un jaunākas versijas vairs neatbalsta IKEv1 IPsec VPN, kas ir produkta un versijas robeža, nevis vispārēja noņemšana, kā fiksē FortiClient saderības piezīme. Arī citi klienti nav savstarpēji aizstājami: OpenConnect un openfortivpn runā konkrētus vārtejas protokolus, nevis patvaļīgus IKEv1 profilus. Pārbaudiet atsevišķi instalētā klienta IKE versiju, PSK režīmu, XAuth atbalstu un mijiedarbības modeli. Klients, kas savienojas ar citu metodi, nav pierādījis sākotnējo prasību.

IKEv1 ir novecojis, tāpēc jauns ieviesums uz neatbalstīta veca klienta ir īslaicīgs risinājums. Lūdziet vārtejas īpašniekam atbalstītu migrācijas ceļu, tostarp to, kā tur tiks apstrādāts otrais faktors.

Diagnosticēšana, neizslēdzot faktoru

Atdaliet žurnālā posmus: vienaudžu sarunas, lietotāja apmaiņu, otrā faktora rezultātu, pēc tam adreses un maršruta piešķiršanu. Pierakstiet komponentu un posmu, nevis izmēģiniet kodu katrā laukā. Faktora izslēgšana, lai tests izietu, rada tuneli, kas neko nepierāda par izvietojumu.

Glabājiet reģistrācijas noslēpumus un koplietoto atslēgu aizsargātā krātuvē saskaņā ar organizācijas procesu. Vienreizējs kods pastāvīgā failā ir faktors, kas pārstājis būt faktors.

Saistītie raksti