Az Azure VPN Client 3.4 óránként bontja a kapcsolatot: bejelentkezési gyakoriság

Egy felhasználó csatlakozik, dolgozik, majd óránként megszakad a kapcsolata azzal az üzenettel, hogy a Microsoft Entra-hitelesítés lejárt. Az újracsatlakozás működik, és a ciklus stoppere szerint ismétlődik. Egy point-to-site átjárón, ahol semmit nem telepítettek, ez a minta a hitelesítő adatokra, nem az alagútra mutat. Az Azure VPN Client 3.4.0 elkezdte érvényesíteni a feltételes hozzáférés bejelentkezési gyakoriságát egy már létrejött munkamenet alatt – olyan házirendet, amelyet a korábbi kliensek csak bejelentkezéskor értékeltek.

Vegye sorra az alábbi hat ellenőrzést. Mindegyik megerősíti vagy kizárja az ütemezést, és a korai leállás az, ahogy egy átjárót feleslegesen újjáépítenek.

1. lépés: olvassa el a pontos üzenetet

A megfogalmazás elválasztja a rétegeket. Az Entra-hitelesítés lejáratáról szóló üzenet a tokenre vonatkozó állítás; az alagút- vagy biztonsági társítási hiba nem az. Jegyezze fel az eltelt időt is, a csatlakozástól a megszakadásig mérve, nem a munkanap kezdetétől.

Ha a felhasználó azonnal újra tud csatlakozni, és az átjáró továbbra is egészséges alagút mutat, tokánlejáratról van szó, nem halott peer-ről.

2. lépés: állapítsa meg a kliens verzióját

A verziót az alkalmazásból olvassa ki, ne a telepítési nyilvántartásból. A változás a 3.4.0-val érkezett, így a 3.3.1 és a korábbiak a házirendtől függetlenül életben tartják a létrejött alagút. Egy nem felügyelt laptop régebbi builddel tökéletesen működik, miközben a csapat többi tagja óránként kiesik: pont ez az a hasadás, amely visszaküldi az embereket az átjáróhoz. A verzió a kliens tulajdonsága, és az átjáró nem tudja, melyik build van csatlakozva.

Először egy teszteszközt frissítsen, és figyelje az órát. Az az eszköz, amely a frissítés után a házirend intervallumában kezd kiesni, igazolja a mechanizmust anélkül, hogy hozzányúlna az éles házirendhez.

3. lépés: keresse meg, hol lakik a házirend

A bejelentkezési gyakoriság a feltételes hozzáférés egy beállítása abban a házirendben, amely az Azure VPN vállalati alkalmazást célozza. Nincs a VPN-átjáró erőforráson, nincs a point-to-site konfigurációban és nincs a kliensprofilban. Keresse meg az Azure VPN alkalmazást a házirendek listáján, és olvassa el a munkamenet-vezérlőket.

Egy felhasználóra két házirend is vonatkozhat, és a szigorúbb nyer, így lehet, hogy egy Ön által soha be nem állított érték van érvényben. Ellenőrizze a bérlő szintű alap-házirendet és az alkalmazásspecifikusat is. A jelentés hatóköre is számít: egy csoportot kizáró házirend más viselkedésű populációt eredményez, kézenfekvő magyarázat nélkül.

4. lépés: számoljon utána

A megszakadás a bejelentkezési gyakoriság értéke után egy órával következik be abban a viselkedésben, amelyet a Microsoft ennek a kliensnek dokumentál, így egy hét órás gyakoriság nagyjából nyolc óra kapcsolatot ad. Ez az eltolás az oka, hogy egy nyolc órás munkanapra választott érték délután hibásnak tűnik, miközben egy kilenc órás teszt jónak látszik. Alakítsa számokká a panaszt, mielőtt bármit módosítana: csatlakozási idő, megszakadási idő, különbség, majd összehasonlítás a házirend értékével plusz egy óra.

Ha a különbség nem egyezik ezzel az összeggel, az ütemezési hipotézis hibás, és abba kell hagynia a házirend finomítását.

5. lépés: válassza szét az ütemezést és a rekey-t

Az IPsec-rekey, a halott peer észlelése és az inaktivitási időtúlépések szabálytalan kieséseket okoznak, amelyek a forgalom mennyiségéhez vagy a csendhez kötődnek, nem stopperhez. Egy átvitel közben kieső és egy inaktív ebéd után kieső felhasználó különböző mechanizmusokat ír le. Kérdezze meg, mit csinált a felhasználó a megszakadás előtti percben.

A tanúsítványproblémák megint másként néznek ki: a kliens nem tud csatlakozni ahelyett, hogy elveszítene egy működő munkamenetet, és a hiba azonnali. Az soha be nem fejeződő MFA-kérés lefagyásként jelenik meg, nem tiszta óránkénti kiesésként, amelyet sikeres újracsatlakozás követ.

6. lépés: vezesse be meglepetés nélkül

Hirdesse meg a kliensfrissítést, mielőtt az áruházon keresztül elérne a felhasználókhoz, mert a viselkedés változása a klienssel együtt érkezik. A gyakoriságot a követelményből válassza: a munkanapot lefedő értéket a használhatóság érdekében, vagy rövid értéket, ha egy elveszett laptopnak gyorsan el kell veszítenie a hozzáférést. Jegyezze fel, melyik követelmény győzött, mivel ugyanaz a beállítás adja a védelmet és a panaszt is. Utána erősítse meg a választást egy új buildet futtató eszközön, ahelyett hogy egy régi builddel futó pilotból extrapolálna.

Tartsa egy jegyzetben az üzenetet, a verziót, a házirend értékét és a mért intervallumot. Ez a feljegyzés egy perc alatt megválaszolja a következő bejelentést, újjáépítés helyett.