Azure VPN Client 3.4 bumabagsak bawat oras: dalas ng pag-sign in

Kumokonekta ang isang user, nagtatrabaho, at pagkatapos ay nadidiskonekta isang beses kada oras na may mensaheng nag-expire na ang authentication sa Microsoft Entra. Gumagana ang muling pagkonekta at paulit-ulit ang siklo na parang stopwatch. Sa gateway na point-to-site kung saan wala namang na-deploy, ang pattern na iyon ay tumuturo sa kredensyal at hindi sa tunnel. Sinimulan ng Azure VPN Client 3.4.0 na ipatupad ang dalas ng pag-sign in ng Conditional Access habang naka-established ang sesyon, isang patakarang sinusuri lang ng mga naunang kliyente sa pag-sign in.

Daanan ang anim na pagsusuri sa ibaba nang sunod-sunod. Ang bawat isa ay nagpapatibay o nag-aalis ng iskedyul, at ang masyadong maagang paghinto ang paraan ng walang saysay na muling pagtatayo ng gateway.

Hakbang 1: basahin ang eksaktong mensahe

Hinihiwalay ng pananalita ang mga layer. Ang mensahe tungkol sa pag-expire ng Entra authentication ay pahayag tungkol sa token; ang error sa tunnel o security association ay hindi. Isulat din ang lumipas na oras, sinusukat mula sa pagkonekta hanggang sa pagkadiskonekta at hindi mula sa simula ng araw ng trabaho.

Kung agad na makakonekta muli ang user at malusog pa rin ang tunnel sa gateway, pag-expire ng token ang nakikita mo at hindi patay na peer.

Hakbang 2: kunin ang bersyon ng kliyente

Basahin ang bersyon sa app, hindi sa talaan ng deployment. Dumating ang pagbabago sa 3.4.0, kaya pinananatiling buhay ng 3.3.1 at mas luma ang naka-established na tunnel anuman ang patakaran. Perpektong gumagana ang isang laptop na hindi pinamamahalaan na may lumang build habang bumabagsak bawat oras ang iba pang koponan: iyon ang uri ng paghahati na nagpapabalik sa mga tao sa gateway. Ang bersyon ay katangian ng kliyente, at hindi alam ng gateway kung aling build ang konektado.

I-update muna ang isang test device at bantayan ang orasan. Ang device na nagsisimulang bumagsak sa agwat ng patakaran pagkatapos ng update ay nagpapatibay ng mekanismo nang hindi hinahawakan ang patakaran sa produksyon.

Hakbang 3: hanapin kung saan nakatira ang patakaran

Ang dalas ng pag-sign in ay setting ng Conditional Access sa patakarang naka-target sa enterprise app na Azure VPN. Wala ito sa resource ng gateway ng VPN, wala sa point-to-site configuration, at wala sa profile ng kliyente. Hanapin ang Azure VPN app sa listahan ng patakaran at basahin ang mga session control.

Maaaring dalawang patakaran ang nalalapat sa isang user, at ang mas mahigpit ang nananaig, kaya ang halagang hindi mo kailanman itinakda ay maaaring siyang may bisa. Suriin ang baseline na patakaran para sa buong tenant at gayundin ang partikular sa app. Mahalaga rin ang saklaw ng ulat: ang patakarang nagbubukod ng isang grupo ay gumagawa ng populasyon na may ibang pag-uugali at walang malinaw na paliwanag.

Hakbang 4: gawin ang aritmetika

Dumarating ang pagkadiskonekta isang oras pagkatapos ng halaga ng dalas ng pag-sign in, sa pag-uugaling idinodokumento ng Microsoft para sa kliyenteng ito, kaya ang pitong oras na dalas ay nagbibigay ng humigit-kumulang walong oras na koneksyon. Dahil sa offset na iyon, ang halagang pinili para sa walong oras na araw ng trabaho ay mukhang sira sa hapon habang ang siyam na oras na pagsubok ay mukhang maayos. Gawing numero ang reklamo bago baguhin ang anuman: oras ng pagkonekta, oras ng pagkadiskonekta, pagkakaiba, pagkatapos ay ihambing sa halaga ng patakaran dagdag ng isang oras.

Kung hindi tumutugma ang pagkakaiba sa kabuuan na iyon, mali ang hypothesis ng iskedyul at dapat kang huminto sa pag-adjust ng patakaran.

Hakbang 5: paghiwalayin ang iskedyul sa rekey

Ang IPsec rekey, dead peer detection at idle timeout ay gumagawa ng iregular na pagbagsak na nauugnay sa dami ng trapiko o katahimikan, hindi sa stopwatch. Ang user na bumabagsak sa gitna ng transfer at ang user na bumabagsak pagkatapos ng tahimik na tanghalian ay naglalarawan ng magkaibang mekanismo. Itanong kung ano ang ginagawa ng user sa minutong bago ang pagkadiskonekta.

Iba na naman ang hitsura ng mga problema sa certificate: nabibigo ang kliyente na kumonekta sa halip na mawalan ng gumaganang sesyon, at agad ang pagkabigo. Ang MFA prompt na hindi natatapos ay lumilitaw na parang pagkakabitin, hindi bilang malinis na oras-oras na pagbagsak na sinusundan ng matagumpay na muling pagkonekta.

Hakbang 6: i-deploy nang walang sorpresa

Ipahayag ang update ng kliyente bago ito makarating sa mga user sa pamamagitan ng store, dahil kasama ng kliyente ang pagbabago sa pag-uugali. Piliin ang dalas batay sa pangangailangan: halagang sumasaklaw sa araw ng trabaho para sa gamit, o maikling halaga kung ang nawalang laptop ay dapat mabilis na mawalan ng access. Itala kung aling pangangailangan ang nanalo, dahil ang parehong setting ay gumagawa ng proteksyon at ng reklamo. Pagkatapos ay kumpirmahin ang pinili sa device na may bagong build sa halip na mag-extrapolate mula sa pilot na gumamit ng luma.

Itago ang mensahe, bersyon, halaga ng patakaran at sinusukat na agwat sa isang tala. Sinasagot ng rekord na iyon ang susunod na ulat sa isang minuto sa halip na isang muling pagtatayo.