Hvorfor Always On VPN slutter å utløses på kontornettverket

Den bærbare maskinen kobler seg til kontorets Wi-Fi, og Always On-profilen som koblet til hjemmefra blir stående nede. Ingenting i hendelsesloggen kaller det en feil, for fra klientens synspunkt er nettverket klarert og tunnelen unødvendig. Gjenkjenning av klarerte nettverk er funksjonen som tar den avgjørelsen, og den sammenligner bestemte verdier i stedet for å gjenkjenne en kjent SSID. Når avgjørelsen er feil, må du se hvilken sammenligning som gikk gjennom.

Hva utløseren faktisk sammenligner

Tre ting må stemme før klienten behandler et nettverk som klarert. For det første må det tilkoblingsspesifikke DNS-suffikset som Windows registrerer for den fysiske adapteren, stå på suffikslisten i profilen. For det andre må tilkoblingsprofilen Windows har for nettverket, være den policyen forventer, fordi samsvaret gjøres mot den profilen og ikke mot et navn en bruker skrev i en trådløs dialog. For det tredje må nettverket klassifiseres slik policyen krever, som i praksis betyr et domene- eller privatnettverk, eller en enhet hvis policy kom via administrasjon. Fjern én av dem, og utløseren slår til.

Dette er en smalere test enn å sammenligne VPN-ens offentlige utgangsadresse, og mye smalere enn å stole på en SSID. Et tilgangspunkt som gjentar firmanavnet oppfyller ikke suffiks- og profilsammenligningene på egen hånd. Det betyr også at funksjonen ikke sier noe om hvorvidt et nettverk er trygt; den sier om denne enheten mener den allerede er hjemme.

Les gjeldende tilstand før du endrer profilen

Start med det Windows mener akkurat nå. Cmdleten for tilkoblingsprofil rapporterer nettverksnavnet, grensesnittet og kategorien Windows tildelte, som er den tredje sammenligningen ovenfor. Les deretter VPN-profilen og se etter listen over klarerte suffikser, med en full egenskapsdump i stedet for å gjette egenskapsnavnene:

Get-NetConnectionProfile
Get-VpnConnection -Name "Corp VPN" | Format-List *

Hvis den dumpen ikke viser det klarerte suffikset på din versjon, gå tilbake til XML-en i profilen, som er den autoritative kopien når egenskapsoverflaten er forskjellig mellom versjoner. Les XML-en fra administrasjonspolicyen eller fra profillageret for alle brukere, og sammenlign suffiksoppføringene med adapterens suffiks som ble rapportert ovenfor. Noter begge verdiene før du rører noen av dem.

Test grensen i begge retninger

Test på den tiltenkte bedriftstilkoblingen og på ett annet godkjent nettverk, og skriv ned om tunnelen kom opp. Test deretter samme enhet etter at du har forlatt nettverket. En bærbar maskin som utløses hjemme og undertrykkes på kontoret, oppfører seg som designet, mens en som aldri utløses noe sted, har en annen feil. Kontroller at ressursene bak tunnelen er tilgjengelige når den utløses, fordi en startet tunnel ikke er bevis på en fungerende vei.

Ikke legg til et bredt suffiks bare for å få en varsling til å forsvinne. Et suffiks som dukker opp på mange nettverk, lærer klienten å undertrykke tunnelen nesten overalt, og støttebelastningen som følger, er verre enn varslingen. Endre kriteriene gjennom profileieren, som i en administrert flåte er MDM-administratoren og ikke personen ved maskinen.

Hold begge testnettverkene i journalen sammen med resultatet. En grense som aldri er testet, er bare en påstand.

Skill undertrykking fra blokkering

En tunnel som ikke ble startet, er ikke en blokkert tilkobling. Gjenkjenning av klarerte nettverk styrer den automatiske utløsningen, mens trafikkfiltrering og kill-switch-atferd er separate policyinnstillinger med egne feilmoduser. En enhet på et klarert nettverk kan lovlig sende trafikk utenfor tunnelen, og å kalle det en lekkasje uten å lese policyen blander to design. Kontroller profilens trafikkregler før du gir gjenkjenningen skylden for en lekkasje.

Den samme sondringen forklarer den motsatte klagen. Brukere som rapporterer at VPN-en stoppet tilfeldig, beskriver vanligvis en nettverksendring som oppfylte kriteriene, ikke en tjenestefeil. Det samsvarende suffikset og nettverkskategorien er bevisene som skal samles inn, og begge vises i utdataene ovenfor.

Samle disse bevisene før du endrer policyen. En bryter som skjuler symptomet, skjuler også årsaken.

Noter hva avgjørelsen bygget på

Skriv det samsvarende suffikset, navnet på tilkoblingsprofilen og nettverkskategorien i distribusjonsnotatene for hvert sted. Når tunnelen ikke kommer opp, gjør den journalen et mysterium om til en sammenligning: enten er en av de tre verdiene endret, eller policyen er det. Det gir også den neste ingeniøren en måte å bekrefte designet på i stedet for å deaktivere gjenkjenningen for å lukke saken.

Gå gjennom suffikslisten når et sted får nytt navn eller et domene konsolideres, fordi en utdatert oppføring fortsetter å undertrykke tunnelen i stillhet. Microsofts referanse for gjenkjenning av klarerte nettverk lister opp profilelementene og forutsetningene for distribusjon, og det er dokumentet som siteres når noen foreslår å utvide listen.