Maayos ang sertipiko ng gateway: bakit nabibigo pa rin ang pag-login sa IKEv2 PEAP

Ang sertipiko ng iyong VPN gateway ay may bisa, ang chain ay nabibigyang-katwiran, at tinatanggihan pa rin ng IKEv2 client ang pag-login na may mensahe tungkol sa validity interval ng isang sertipiko. Ang unang udyok ay muling ilabas ang sertipiko ng gateway o palitan ang EAP method, at pareho ay karaniwang mali. Ang pagtatangkang mag-login ay nagdadala ng dalawang hiwalay na pagkakakilanlan ng server: ang sertipiko ng gateway na ginagamit ng IKE, at ang sertipiko na inihaharap ng kung anuman ang nagtatapos sa PEAP. Maayos ang isa sa kanila, at ang isa pa ang dahilan kung bakit huminto ang client.

Dalawang pagkakakilanlan, isang pagtatangkang mag-login

Ang sertipiko sa profile ng VPN ay kabilang sa palitan ng IKE: pinatutunayan nito na ang gateway ang kapares na pinangalanan ng profile, sa ilalim ng naka-configure na patakaran ng IKE. Ang sertipikong nabibigo dito ay kabilang sa ibang usapan, ang TLS session na binubuksan ng PEAP sa kung sino ang nagpapatunay sa user, na kadalasan ay isang RADIUS server tulad ng NPS at hindi ang gateway mismo. Ang ikatlong pagsusuri, ang kredensyal ng user, ay nangyayari sa loob ng session na iyon. Ang wastong password ay hindi kayang ayusin ang nag-expire na sertipiko ng server, at ang wastong sertipiko ng gateway ay hindi kayang garantiya ang PEAP endpoint.

Ipinapaliwanag ng pagsasapin na ito kung bakit lumilitaw ang error sa sertipiko sa lugar kung saan ang tanging naka-configure na sertipiko ay ang sa gateway. Ipinapaliwanag din nito kung bakit walang binabago ang muling paglabas ng sertipikong iyon.

Basahin ang linya ng log laban sa yugto

Hanapin ang mensaheng nagsasabi ng dahilan at ng mga petsa. Ang reklamo tungkol sa validity interval sa tabi ng error sa subject ay nangangahulugan na tinanggihan ng server ang sertipikong ibinigay dito, hindi na tinanggihan ng user ang pag-login. Pagkatapos hanapin ang yugto: ang charon log ng strongSwan ay nagpapakita ng IKE_SA .* established bago magsimula ang palitan ng EAP, kaya ang error sa sertipiko pagkatapos ng linyang iyon ay kabilang sa EAP identity, habang ang error bago iyon ay tumuturo sa gateway. Ang teksto ng yugto sa connection pane ng isang Windows client ay nagsasabi rin ng pareho.

Suriin ang orasan ng client bago hawakan ang anumang sertipiko. Ang device na ilang oras ang pagkakaiba ay gumagawa ng parehong error sa validity gaya ng tunay na nag-expire na sertipiko. Ang pag-reset ng orasan ay limang segundong pagwawasto, at ang pagpapalit ng sertipikong hindi naman kailanman ang problema ay isang outage.

Alamin kung aling endpoint ang nagtatapos sa PEAP

Sa disenyong gateway at RADIUS, ipinapasa ng gateway ang EAP at hindi ito tinatapos. Ibinibigay ng eap-radius plugin ng strongSwan ang palitan sa RADIUS server, na nagmamay-ari ng PEAP TLS session at ng sertipiko nito. Iugnay ang isang nabigong pagtatangka sa dalawang log at kumpirmahin kung aling proseso ang tunay na pumili ng sertipiko para sa session na iyon.

Para sa NPS ang sertipiko ay dapat nasa tindahan ng lokal na computer, may layuning server authentication, tumutugma sa pangalang inaasahan ng mga client, at nababasa ng service account. Ang mga kinakailangan sa sertipiko ng Microsoft para sa NPS ay naglilista ng mga kundisyong iyon. Ang ibang EAP server ay may sariling tuntunin sa pagpili, kaya huwag kopyahin ang mga detalye ng NPS sa isang deployment ng FreeRADIUS o kabaliktaran. Ang tuntuning nananatili sa dalawang kaso ay ang endpoint na nagtatapos sa PEAP ang may-ari ng sertipikong babaguhin mo.

Palitan ang sertipiko kung saan nagtatapos ang EAP

I-renew o palitan ang sertipiko sa endpoint na nagtatapos sa PEAP, sa pamamagitan ng sinusuportahang proseso, pinapanatili ang layuning server authentication at ang inaasahang pangalan. I-install ang buong chain kung saan ito hinahanap ng serbisyo at bigyan ang serbisyo ng access sa pribadong key. I-restart o i-rebind ang serbisyo, dahil maraming serbisyo ang nagtatago ng lumang sertipiko sa memory at patuloy itong inihaharap. Ang file na kinopya sa makina ay walang pinatutunayan tungkol sa kung aling sertipiko ang tunay na inihaharap ng serbisyo.

Kumpirmahin ang pagbabago sa pamamagitan ng pag-ugnay sa susunod na pagtatangka sa sariling log ng serbisyo, o sa pagsusuri sa sertipikong iniharap ng session. Kung ang log na iyon ay nagpapakita pa rin ng lumang thumbprint, hindi nagtagumpay ang restart.

Huwag ipagpalagay na ang pinakabagong file sa isang direktoryo ang ginagamit. Ang kopya na may tamang pangalan at maling pahintulot ay walang binabago. Hatulan ang pagbabago sa pamamagitan ng inihayag na pagkakakilanlan, hindi sa timestamp ng file.

Ano ang hindi dapat gawin

Huwag i-disable ang PEAP validation at huwag pilitin ang mas mahinang panloob na paraan para makalampas sa error. Binabago nito ang patakaran at tinatanggal ang server authentication property na humuli sa nag-expire na sertipiko sa simula pa lang. Ipapalit mo ang gumaganang pagsusuri para sa gumaganang koneksyon, at ang susunod na nag-expire na sertipiko ay darating na walang anumang magsasabi nito.

Huwag ituring ang matagumpay na koneksyon mula sa ibang operating system bilang patunay na katanggap-tanggap ang sertipiko. Maaaring gumamit ang client na iyon ng ibang EAP method, ibang trust store o walang server validation, kaya walang sinasabi ang tagumpay nito tungkol sa pagsusuring nabigo dito. Panatilihin ang isang sadyang negatibong test, tulad ng sertipikong maling pangalan o hindi pinagkakatiwalaang chain, na nabibigo ayon sa inaasahan. Kung ang test na iyon ay pumasa ngayon, inalis mo ang isang pagsusuri sa halip na inayos ang isang sertipiko. Isulat kung aling pagkakakilanlan ang nabigo, upang ang susunod na tao ay hindi magsimula muli sa sertipiko ng gateway.