IKEv1 me XAuth dhe OTP: çfarë kërkon secila kërkesë
Një PSK grupi, një shkëmbim XAuth i përdoruesit dhe një sfidë OTP janë tre hyrje të ndryshme. Përputhni secilën kërkesë me pronarin e saj përpara se të instaloni një klient tjetër.
IKEv1 me PSK, XAuth dhe OTP nuk kërkon një fjalëkalim të ndërlikuar të vetëm. Ai shton shtresa me një çelës të përbashkët mes peer-ave, një shkëmbim përdoruesi dhe një faktor të dytë për të cilin backend-i vendos si të kërkohet. Secila shtresë ka pronarin dhe mesazhin e vet të dështimit. Ngatërrimi i tyre i bën njerëzit të shkruajnë përsëri një kod njëpërdorimësh në një fushë që ruan një sekret grupi.
Përputhni secilën kërkesë me shtresën që e kërkon përpara se të instaloni një klient tjetër ose të rivendosni një kredencial.
Tre sekrete, tre pronarë
Çelësi i përbashkët i parapërcaktuar i përket marrëdhënies mes peer-ave dhe konfigurohet një herë nga kush zotëron të dy skajet. Kredenciali i përdoruesit i përket backend-it të autentikimit dhe validohet në çdo hyrje. Faktori i dytë i përket një sistemi token-ash, përgjigja e të cilit ndryshon në çdo provë. Asnjëri nuk zëvendëson tjetrin, dhe një vendosje që i trajton si një fjalëkalim të vetëm dështon në shtresën që askush nuk e dokumentoi.
Shkruani tre kolona: pronari, kohëzgjatja dhe mesazhi i dështimit që prodhon secili. Ajo tabelë është mjeti i diagnostikimit, jo emrat e fushave në klient.
| 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: e peer-it, jo e personit
Në këtë rregullim të vjetër, çelësi i përbashkët autentikon çiftin e gateway-ve, prandaj hyrja e përdoruesit nuk e zëvendëson kurrë atë. Është gjithashtu vlera që gabohet më shpesh në një mënyrë që prodhon një gabim të përgjithshëm negocimi në vend të një kërkese. Kur tuneli dështon përpara se të shfaqet ndonjë kërkesë përdoruesi, të dyshuarit janë çelësi ose propozimet.
Kredenciali i përdoruesit nuk mund të rregullojë një dështim të fazës së parë. Rrotullimi i tij harxhon kredencialin e vetëm që mund të rrotullohet me siguri dhe përforcon teorinë e gabuar.
XAuth: shkëmbimi i vjetër i përdoruesit
XAuth shton një shkëmbim autentikimi përdoruesi mbi autentikimin e peer-it në IKEv1, dhe gateway-i vendos cili backend e validon atë. Në varësi të atij backend-i, shkëmbimi mund të pranojë një fjalëkalim drejtorie, një kredencial RADIUS ose një përgjigje token-i. Fjala XAuth emërton transportin e shkëmbimit, jo llojin e kredencialit.
Kontrolloni drejt cilit backend tregon profili i gateway-it. Kjo ju tregon çfarë do t'i kërkohet përdoruesit dhe çfarë ndryshon në të vërtetë rivendosja e fjalëkalimit, dhe asnjëra nuk duket në një profil klienti.
OTP: çfarë të kërkojë backend-i
Disa vendosje kërkojnë një kod njëpërdorimësh të veçantë pas fjalëkalimit, ndërsa të tjera përcaktojnë një format të kombinuar hyrjeje me një ndarës të dokumentuar. Të dyja ekzistojnë, dhe profili përpara jush vendos cila. Shpikja e një bashkimi sepse funksionoi në një vend tjetër është mënyra më e zakonshme për të djegur një token regjistrimi. Vetëm dokumentacioni i gateway-it e zgjidh këtë.
Përdorni formatin e dokumentuar me një klient që mund të përfundojë shkëmbimin që ofron gateway-i.
Ku kafshon kufiri i klientit
Fortinet dokumenton se FortiClient 7.4.4 dhe më vonë nuk e mbështesin më IKEv1 për VPN-t IPsec, çka është një kufi produkti dhe versioni, jo një heqje universale, siç regjistron shënimi i përputhshmërisë i FortiClient. As klientët e tjerë nuk janë të këmbyeshëm: OpenConnect dhe openfortivpn flasin protokolle të caktuara gateway-i, jo profile arbitrare IKEv1. Kontrolloni veçmas versionin IKE, modalitetin PSK, mbështetjen XAuth dhe modelin e ndërveprimit të klientit të instaluar. Një klient që lidhet me një metodë tjetër nuk e ka provuar kërkesën origjinale.
IKEv1 është i vjetruar, prandaj një vendosje e re e ndërtuar mbi një klient të vjetër të pambështetur është zgjidhje jetëshkurtër. Kërkoni nga pronari i gateway-it një rrugë migrimi të mbështetur, përfshirë si do të trajtohet atje faktori i dytë.
Diagnostikim pa e fikur faktorin
Ndani fazat në regjistër: negocimi i peer-ave, shkëmbimi i përdoruesit, rezultati i faktorit të dytë, pastaj caktimi i adresës dhe rrugës. Shënoni komponentin dhe fazën në vend që të provoni kodin në çdo fushë. Fikja e faktorit që një test të kalojë prodhon një tunel që nuk provon asgjë për vendosjen.
Mbani sekretet e regjistrimit dhe çelësin e përbashkët në ruajtje të mbrojtur sipas procesit të organizatës. Një kod njëpërdorimësh në një skedar të përhershëm është një faktor që ka pushuar së qeni faktor.