Azure VPN Client 3.4 malkonektiĝas ĉiun horon: ensaluta ofteco
Ne la enirejo: la kliento nun plenumas la ensalutan oftecon meze de sesio, do la tunelo mortas laŭ la horloĝo de la politiko. Versio, ŝoviĝo kaj kontroloj.
Unu uzanto konektiĝas, laboras, kaj poste estas malkonektita unufoje hore kun mesaĝo, ke la aŭtentigo ĉe Microsoft Entra eksvalidiĝis. Rekonektiĝo funkcias kaj la ciklo ripetiĝas kiel laŭ klikhorloĝo. Sur point-to-site-enirejo, kie nenio estis deplojita, tiu ŝablono montras al la akreditaĵo kaj ne al la tunelo. Azure VPN Client 3.4.0 komencis plenumi la ensalutan oftecon de Kondiĉa Aliro dum jam establita sesio, politiko, kiun pli fruaj klientoj taksis nur ĉe ensaluto.
Trairu la ses kontrolojn sube en ordo. Ĉiu konfirmas aŭ ekskludas la horaron, kaj antaŭtempa halto estas la maniero rekonstrui enirejon senkaŭze.
Paŝo 1: legu la precizan mesaĝon
La vortigo apartigas la tavolojn. Mesaĝo pri eksvalidiĝanta Entra-aŭtentigo estas aserto pri la ĵetono; tunela aŭ sekureca-asocia eraro ne estas. Notu ankaŭ la pasintan tempon, mezuritan de konekto ĝis malkonekto, ne de la komenco de la labora tago.
Se la uzanto povas tuj rekonektiĝi kaj la enirejo ankoraŭ montras sanan tunelon, vi rigardas ĵetonan eksvalidiĝon, ne mortan samtavolan.
Paŝo 2: eltrovu la klientan version
Legu la version en la apo, ne en la deploja registro. La ŝanĝo alvenis kun 3.4.0, do 3.3.1 kaj pli fruaj tenas establitan tunelon viva sendepende de la politiko. Unu neadministrita tekkomputilo kun pli malnova versio funkcias perfekte, dum la resto de la teamo falas ĉiun horon: ĝuŝi tia divido resendas homojn al la enirejo. La versio estas eco de la kliento, kaj la enirejo ne scias, kiu versio estas konektita.
Unue ĝisdatigu unu testan aparaton kaj observu la horloĝon. Aparato, kiu post la ĝisdatigo komencas fali je la politika intervalo, konfirmas la mekanismon sen tuŝi la produktopolitikon.
Paŝo 3: trovu, kie loĝas la politiko
Ensaluta ofteco estas agordo de Kondiĉa Aliro en la politiko celanta la entreprenan apon Azure VPN. Ĝi ne estas sur la VPN-enireja rimedo, nek en la point-to-site-agordo, nek en la klienta profilo. Serĉu la apon Azure VPN en la politika listo kaj legu la sesiajn regilojn.
Du politikoj povas validi por unu uzanto, kaj la pli strikta venkas, do valoro, kiun vi neniam agordis, povas esti la valida. Kontrolu kaj teneran bazan politikon kaj la apspecifan. Ankaŭ la amplekso de la raporto gravas: politiko, kiu ekskludas grupon, produktas loĝantaron kun alia konduto kaj sen evidenta klarigo.
Paŝo 4: kalkulu
La malkonekto okazas unu horon post la valoro de ensaluta ofteco, laŭ la konduto, kiun Microsoft dokumentas por ĉi tiu kliento, do ofteco de sep horoj donas proksimume ok horojn da konekteco. Tiu ŝoviĝo klarigas, kial valoro elektita por okhora labora tago aspektas difektita posttagmeze, dum naŭhora testo aspektas bone. Konvertu la plendon al nombroj antaŭ ol ŝanĝi ion: konekta tempo, malkonekta tempo, diferenco, kaj poste komparo kun la politika valoro plus unu horo.
Se la diferenco ne kongruas kun tiu sumo, la horara hipotezo estas malĝusta kaj vi devus ĉesi ĝustigi la politikon.
Paŝo 5: apartigu horaron de rekey
IPsec-rekey, detekto de morta samtavolo kaj senokupaj tempolimoj produktas neregulajn falojn ligitajn al trafika volumeno aŭ silento, ne al klikhorloĝo. Uzanto faligita meze de transdono kaj uzanto faligita post senokupa tagmanĝo priskribas malsamajn mekanismojn. Demandu, kion la uzanto faris en la minuto antaŭ la malkonekto.
Atestilaĵaj problemoj aspektas denove alie: la kliento malsukcesas konekti anstataŭ perdi funkciantan sesion, kaj la fiasko estas tuja. MFA-peto, kiu neniam finiĝas, aperas kiel blokiĝo, ne kiel pura hora falo sekvata de sukcesa rekonekto.
Paŝo 6: deploju sen surprizo
Anoncu la klientan ĝisdatigon antaŭ ol ĝi atingos la uzantojn per la butiko, ĉar la konduta ŝanĝo venas kun la kliento. Elektu la oftecon laŭ la postulo: valoro kovranta la laboran tagon por usebleco, aŭ mallonga valoro se perdita tekkomputilo devas rapide perdi aliron. Notu, kiu postulo venkis, ĉar la sama agordo produktas kaj la protekton kaj la plendon. Poste konfirmu la elekton sur aparato kun la nova versio anstataŭ ekstrapoli el piloto, kiu uzis la malnovan.
Konservu la mesaĝon, la version, la politikan valoron kaj la mezuritan intervalon en unu noto. Tiu registro respondas al la sekva raporto en unu minuto anstataŭ per rekonstruo.