IKEv1 kasama ang XAuth at OTP: ano ang hinihingi ng bawat prompt
Ang PSK ng grupo, pagpapalitan ng XAuth ng user at hamon ng OTP ay tatlong magkaibang input. Itugma ang bawat prompt sa may-ari nito bago mag-install ng isa pang kliyente.
Ang IKEv1 na may PSK, XAuth at OTP ay hindi humihingi ng isang kumplikadong password. Pinapatong nito ang isang ibinahaging susi sa pagitan ng mga peer, isang pagpapalitan ng user, at isang pangalawang factor na ang backend ang nagpapasya kung paano hihingin. Bawat patong ay may sariling may-ari at sariling mensahe ng pagkabigo. Ang paghahalo sa kanila ay nagtutulak sa mga tao na i-type muli ang one-time code sa isang patlang na nag-iimbak ng group secret.
Itugma ang bawat prompt sa patong na humihingi nito bago mag-install ng isa pang kliyente o i-reset ang isang kredensyal.
Tatlong sikreto, tatlong may-ari
Ang pre-shared key ay pag-aari ng ugnayan ng mga peer at isinasagawa nang isang beses ng may hawak ng dalawang dulo. Ang kredensyal ng user ay pag-aari ng backend ng pagpapatunay at bineberipika sa bawat pag-login. Ang pangalawang factor ay pag-aari ng token system na nagbabago ang tugon sa bawat pagtatangka. Walang humahalili sa isa pa, at ang deployment na itinuturing silang isang password ay nabibigo sa patong na walang nagdokumento.
Isulat ang tatlong hanay: may-ari, habang-buhay, at ang mensahe ng pagkabigo na nililikha ng bawat isa. Ang talahanayang iyon ang kasangkapan sa pag-diagnose, hindi ang mga pangalan ng patlang sa kliyente.
| 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: pag-aari ng peer, hindi ng tao
Sa lumang kaayusang ito, ang pre-shared key ang nagpapatunay sa pares ng gateway, kaya hindi ito napapalitan ng pag-login ng user. Ito rin ang value na pinakamadalas magkamali sa paraang gumagawa ng pangkalahatang error sa negosasyon sa halip na prompt. Kapag nabigo ang tunnel bago lumitaw ang anumang prompt ng user, ang susi o ang mga panukala ang pinaghihinalaan.
Hindi kayang ayusin ng kredensyal ng user ang pagkabigo sa unang yugto. Ang paikutin ito ay nagsasayang lamang ng nag-iisang kredensyal na ligtas na paikutin, at nagpapatibay ito ng maling teorya.
XAuth: ang lumang pagpapalitan ng user
Nagdaragdag ang XAuth ng pagpapalitan ng pagpapatunay ng user sa ibabaw ng peer authentication ng IKEv1, at ang gateway ang nagpapasya kung aling backend ang magbeberipika nito. Depende sa backend na iyon, maaaring tumanggap ang pagpapalitan ng password ng direktoryo, kredensyal ng RADIUS o tugon ng token. Pinangalanan ng salitang XAuth ang transport ng pagpapalitan, hindi ang uri ng kredensyal.
Suriin kung aling backend ang tinutukoy ng profile ng gateway. Sinasabi niyon kung ano ang hihingin sa user at kung ano ang aktuwal na binabago ng pag-reset ng password, at wala sa dalawa ang nakikita sa profile ng kliyente.
OTP: kahit ano ang hilingin ng backend
May mga deployment na humihingi ng hiwalay na one-time code pagkatapos ng password, at may iba namang naglalarawan ng pinagsamang format ng input na may dokumentadong separator. Umiiral ang dalawa, at ang profile sa harap mo ang magpapasya kung alin. Ang pag-imbento ng paraan ng pagsasama dahil gumana ito sa ibang site ay ang pinakakaraniwang paraan ng pagsunog ng enrollment token. Ang dokumentasyon mismo ng gateway ang nag-iisang mapagkukunan na nagtatakda nito.
Gamitin ang dokumentadong format sa isang kliyenteng kayang tapusin ang pagpapalitang inaalok ng gateway.
Kung saan kumakagat ang hangganan ng kliyente
Itinatala ng Fortinet na ang FortiClient 7.4.4 at mas bago ay hindi na sumusuporta sa IKEv1 para sa IPsec VPN, na hangganan ng produkto at bersyon sa halip na pangkalahatang pagtanggal, gaya ng nakatala sa tala ng pagiging tugma ng FortiClient. Hindi rin mapagpapalit ang ibang kliyente: ang OpenConnect at openfortivpn ay nagsasalita ng partikular na gateway protocol, hindi ng kahit anong IKEv1 profile. Suriin nang isa-isa ang bersyon ng IKE, mode ng PSK, suporta sa XAuth at modelo ng interaksyon ng naka-install na kliyente. Ang kliyenteng kumokonekta sa ibang paraan ay hindi nagpatunay na natugunan ang orihinal na pangangailangan.
Hindi na sinusuportahan ang IKEv1, kaya ang bagong rollout na itinatag sa lumang kliyenteng hindi na sinusuportahan ay panandaliang solusyon. Hilingin sa may-ari ng gateway ang sinusuportahang landas ng paglipat, kabilang kung paano hahawakan doon ang pangalawang factor.
Pag-diagnose nang hindi pinapatay ang factor
Paghiwalayin ang mga yugto sa log: negosasyon ng peer, pagpapalitan ng user, resulta ng pangalawang factor, pagkatapos ang pagtatalaga ng address at ruta. Itala ang component at ang yugto sa halip na subukan ang code sa bawat patlang. Ang patayin ang factor para pumasa ang isang test ay gumagawa ng tunnel na walang pinapatunayang anuman tungkol sa deployment.
Itago ang mga sikreto ng enrollment at ang shared key sa protektadong imbakan ayon sa proseso ng organisasyon. Ang one-time code sa permanenteng file ay factor na tumigil nang maging factor.