Gumagana ang IKEv2 exchange, tapos nabibigo ang authentication: saan titingin

Ang client na tumatanggap ng tugon ng IKEv2 ay nagpatunay na maaabot ang gateway, na makakapag-usap ang dalawang panig tungkol sa isang panukala at na natapos ang paunang key exchange. Ngunit hindi nito napatunayan na may na-authenticate. Dinadala ng susunod na palitan ang mga pagkakakilanlan, sertipiko o EAP, at doon karaniwang humihinto ang koneksyon. Ang pagbasa kung alin sa mga pagsusuring ito ang nabigo ay ang buong diagnosis, at bihirang sabihin ito ng mensahe ng error nang mag-isa.

Pagsusuri 1: basahin ang yugto, hindi ang mensahe

Maaaring magmula ang pagtanggi sa tatlong lugar: tinatanggihan ng client ang pagkakakilanlan ng server, tinatanggihan ng gateway ang patunay ng client, at tinatanggihan ng panlabas na serbisyo ng authentication ang account.

Bawat isa ay gumagawa ng ibang linya ng log sa ibang makina, at bawat isa ay may ibang solusyon. Ang pagtanggi ng sertipiko ng server sa panig ng client ay problema sa tiwala o pagpapangalan sa client; ang pagtanggi ng sertipiko ng client sa panig ng gateway ay problema sa tiwala sa gateway; ang pagkabigo ng EAP ay problema sa account o backend. Ang mensaheng nakikita mo ay karaniwang buod ng client tungkol sa isa sa mga iyon, kaya kasinghalaga ng log ng client ang log ng gateway.

Pagsusuri 2: aling pagkakakilanlan ang sinuri

Maaaring tanggihan ng client ang sertipiko ng server o ang inaasahang pagkakakilanlan bago pa man mag-alok ng anumang kredensyal ng user, at ang gumaganang address ng server ay hindi kapalit ng pagsusuring iyon. Dapat tumugma ang identifier na inaasahan ng client sa ipinapakita ng gateway, na katotohanan ng configuration at hindi ng network.

Sa mga termino ng strongSwan iyon ay rightid sa client at ang sariling pagkakakilanlan ng gateway sa kabilang panig, at nabibigo ang hindi pagkakatugma bago pa man pag-usapan ang EAP.

Maaaring tanggihan ng gateway nang hiwalay ang sertipiko ng client, ang patunay ng key nito o ang authentication ng account nito, at ang tatlong ito ay hindi mapagpapalit. Ang pag-reset ng password ng user ay hindi nagpapanibago ng sertipiko ng device, at ang muling pag-install ng sertipiko ng device ay hindi nag-aayos ng maling pagkakakilanlan ng server. Para sa mga pagkabigo ng sertipiko, tingnan muna ang orasan, pagkatapos ang tanikala ng tiwala, pagkatapos ang inaasahang identifier; ang client na ilang minuto ang diperensya ng orasan ay nabibigo sa pagsusuri ng bisa na mukhang pagkabigo ng tiwala. swanctl --list-certs sa dalawang dulo ay nagpapakita kung ano talaga ang hawak ng bawat panig.

Pagsusuri 3: kung may EAP

Kailangang magkasundo ang client at server sa isang sinusuportahang paraan, at kailangang tanggapin ng backend ang ibinigay na pagkakakilanlan.

Maaaring kailangan ng username ang suffix ng domain o partikular na format ng account na hinihingi ng deployment, at ang format ay dokumentado at hindi hinuhulaan. Ang pagbibigay ng mga dokumentadong field ng operator ay mas mabilis kaysa sa pagsubok ng mga variant, at iniiwasan nito ang pangalawang problema: ang paulit-ulit na pagtatangka ay maaaring magdulot ng lockout ng account, na pagkatapos ay nagtatago ng orihinal na yugto sa likod ng bagong pagkabigo. Kung ang paraan ay EAP-MSCHAPv2 laban sa isang direktoryo, maaaring pag-aari ng direktoryo ang pagkabigo at hindi ng VPN.

Huwag subukan ang mga problema sa pagkakakilanlan sa pamamagitan ng pag-disable ng mga pagsusuri ng pagkakakilanlan. Ginagawa nitong hindi ma-diagnose ang isang na-diagnose na pagkabigo at iniiwan ang koneksyon na mas mahina kaysa dati.

Pagsusuri 4: ano ang nangyayari pagkatapos ng matagumpay na pag-login

Kapag natapos ang IKE_AUTH, nagpapasya ang negosasyon ng CHILD_SA kung aling mga tagapili ng trapiko ang i-install, at doon maaaring magtagumpay ang koneksyon at wala pa ring maipasa.

Ang bagong gumaganang pag-login ay madalas na nagbubunyag ng problema sa tagapili o ruta na dating nakatago sa likod ng pagkabigo ng authentication. Kung bumangon ang tunnel at hindi pa rin maabot ng application ang destinasyon nito, tingnan ang napagkasunduang tagapili at ruta at hindi muli ang pagkakakilanlan. Ang pagbabago ng mga setting ng pagkakakilanlan sa puntong iyon ay tumatarget sa maling yugto at karaniwang sumisira ng gumaganang pag-login. Kumpirmahin gamit ang swanctl --list-sas, na nagpapakita ng mga anak at ng kanilang mga tagapili nang hiwalay sa IKE SA.

Pagsusuri 5: ano ang ibibigay sa support

Ang nalinis na timeline at ang tumpak na pagtanggi ay mas mahalaga kaysa sa buong diagnostic export, at ang export ay maaaring maglaman ng mga pribadong key o kredensyal na hindi mo dapat ibahagi.

Itala ang oras kasama ang time zone, ang mga bersyon ng client at gateway, ang paraan, ang string ng pagkakakilanlan na inalok at hindi ang password, at ang eksaktong yugto na tumanggi dito. Ang dokumentasyon ng configuration ng IKEv2 ng strongSwan ay naglalarawan ng mga setting ng pagkakakilanlan at EAP na nagpapasya sa mga resultang ito, at iyon ang sanggunian na dapat basahin bago baguhin ang isang field. Pagkatapos ay baguhin ang isang bagay at subukan muli ang bagong koneksyon, dahil ang naka-cache na session ay magsasabi sa iyo tungkol sa lumang configuration.