En användare ansluter, arbetar och kopplas sedan ner en gång i timmen med ett meddelande om att autentiseringen mot Microsoft Entra har gått ut. Återanslutningen fungerar och cykeln upprepas som på ett stoppur. På en point-to-site-gateway där inget har distribuerats pekar mönstret på uppgifterna och inte på tunneln. Azure VPN Client 3.4.0 började tillämpa inloggningsfrekvensen i villkorlig åtkomst under en etablerad session, en policy som tidigare klienter bara utvärderade vid inloggning.

Gå igenom de sex kontrollerna nedan i ordning. Var och en bekräftar eller utesluter schemat, och att stanna för tidigt är hur en gateway byggs om helt i onödan.

Steg 1: läs det exakta meddelandet

Formuleringen skiljer lagren. Ett meddelande om att Entra-autentiseringen går ut är ett påstående om token; ett tunnel- eller säkerhetsassociationsfel är det inte. Skriv också upp den förflutna tiden, mätt från anslutning till frånkoppling och inte från arbetsdagens början.

Om användaren kan återansluta direkt och gatewayen fortfarande visar en frisk tunnel handlar det om tokenutgång och inte om en död peer.

Steg 2: hämta klientversionen

Läs versionen i appen, inte i distributionsposten. Ändringen kom med 3.4.0, så 3.3.1 och äldre håller en etablerad tunnel vid liv oavsett policyn. En ohanterad laptop med äldre version fungerar perfekt medan resten av teamet tappar anslutningen varje timme: det är den sortens splittring som får folk att gå tillbaka till gatewayen. Versionen är en egenskap hos klienten, och gatewayen vet inte vilken version som är ansluten.

Uppdatera först en testenhet och bevaka klockan. En enhet som börjar tappa anslutningen vid policyintervallet efter uppdateringen bekräftar mekanismen utan att röra produktionspolicyn.

Steg 3: hitta var policyn bor

Inloggningsfrekvens är en inställning för villkorlig åtkomst i policyn som riktar sig mot företagsappen Azure VPN. Den finns inte på VPN-gatewayresursen, inte i point-to-site-konfigurationen och inte i klientprofilen. Sök efter Azure VPN-appen i policylistan och läs sessionskontrollerna.

Två policyer kan gälla för en användare, och den strängare vinner, så ett värde du aldrig har angett kan vara det som gäller. Kontrollera både en klientomfattande baspolicy och den appspecifika. Rapportens omfång spelar också roll: en policy som utesluter en grupp ger en population med annat beteende och utan uppenbar förklaring.

Steg 4: räkna efter

Frånkopplingen inträffar en timme efter värdet för inloggningsfrekvens, i det beteende Microsoft dokumenterar för den här klienten, så en frekvens på sju timmar ger ungefär åtta timmars anslutning. Den förskjutningen är varför ett värde valt för en åtta timmar lång arbetsdag verkar trasigt på eftermiddagen medan ett test på nio timmar ser bra ut. Omvandla klagomålet till siffror innan du ändrar något: anslutningstid, frånkopplingstid, skillnad och jämför sedan med policyvärdet plus en timme.

Om skillnaden inte stämmer med summan är schemahypotesen fel och du bör sluta justera policyn.

Steg 5: skilj ett schema från en rekey

IPsec-rekey, döda-peer-detektering och inaktiva timeouts ger oregelbundna avbrott kopplade till trafikvolym eller tystnad, inte till ett stoppur. En användare som tappas mitt i en överföring och en som tappas efter en inaktiv lunch beskriver olika mekanismer. Fråga vad användaren gjorde i minuten före frånkopplingen.

Certifikatproblem ser annorlunda ut igen: klienten misslyckas med att ansluta i stället för att tappa en fungerande session, och felet är omedelbart. En MFA-förfrågan som aldrig slutförs visar sig som en hängning, inte som en ren timvis frånkoppling följd av en lyckad återanslutning.

Steg 6: rulla ut utan överraskning

Meddela klientuppdateringen innan den når användarna via butiken, eftersom beteendeändringen levereras med klienten. Välj frekvens utifrån kravet: ett värde som täcker arbetsdagen för användbarhet, eller ett kort värde om en förlorad laptop snabbt måste förlora åtkomst. Anteckna vilket krav som vann, eftersom samma inställning ger både skyddet och klagomålet. Bekräfta sedan valet på en enhet med den nya versionen i stället för att extrapolera från en pilot med den gamla.

Förvara meddelandet, versionen, policyvärdet och det uppmätta intervallet i en enda anteckning. Den posten besvarar nästa rapport på en minut i stället för med en ombyggnad.

Relaterade artiklar