Always On VPN ne estas LAN-aliro: kontrol-listo pri rimedoj

Always On estas vivociklo de konekto: la profilo konektiĝas ĉe aŭ antaŭ sin-ensaluto kaj rekonektiĝas sen ke la uzanto premu ion ajn. Tio ne signifas, ke ĉiu privata celo, protokolo kaj uzanto estas permesitaj. La praktika demando estas, kiujn rimedojn la deplojita profilo efektive liveras, kaj tiu respondo postulas kontrolon por ĉiu rimedo, ne rigardon al la insigno Connected.

Paŝo 1: Notu la rimedon antaŭ ol testi ĝin

Komencu per mallonga rikordo por ĉiu programo, prenita el la reala medio: nomo, cela prefikso, servo kaj pordo, rolo de la tunelo, identeca grupo kaj vojo de la solvilo.

Name: portal.corp.example
Destination: 10.20.5.0/24
Service: HTTPS 443
Tunnel role: user access after sign-in
Identity: assigned employee group
Resolver: corporate private DNS

La rikordo devigas kvar apartajn demandojn. Itinero decidas, kien iras la adreso; DNS-politiko decidas, kiel la kliento lernas la adreson; trafika filtrilo decidas, ĉu tiu trafiko rajtas uzi la konekton; fajroŝirmilo de la celo kaj permesoj de la programo decidas, ĉu la peto akceptiĝas. Neniu el la kvar devenas de konektita tunelo.

Paŝo 2: Difinu, kiu tunelo devas porti ĝin

Windows Always On VPN havas aparatan tunelon kaj uzantan tunelon, agorditajn kiel apartaj profilo kun apartaj atestiloj kaj ampleksoj. La aparata tunelo kutime portas nur la infrastrukturon bezonatan antaŭ ensaluto, ekzemple administradon kaj domajnajn servojn; la vasta programa aliro por laborantoj apartenas al la uzanta tunelo.

Trafikaj filtriloj estas funkcio de la aparata tunelo, tial la ekzemplo de Microsoft uzas ilin por administra trafiko. Kopii tiun ekzemplon en ĝeneralan rimedan profilon donas tunelon, kiu konektiĝas sed portas la malĝustan aron. Konfirmu la aktivan konekton per Get-VpnConnection kaj testu sub tiu konekto.

Paŝo 3: Kontrolu la itineron por la reala adreso

Solvu la nomon unufoje, poste kontrolu la itineron: Find-NetRoute -RemoteIPAddress 10.20.5.10 montras la elektitan interfacon, la sekvan salteton kaj la fontan adreson. Se la interfaco estas la fizika adaptilo, la prefikso mankas en la itinera aro de la tunelo aŭ la kliento ekskludis ĝin per dividita tunelado. Komparu kun la profila difino anstataŭ aldoni lokan itineron.

Loka route add povas igi la teston sukcesi kaj malaperi ĉe la sekva politika refreŝigo, do la ŝanĝo apartenas al la administrata profilo. Kontrolu la prefikson en la uzanta kaj aparata profilo, kaj la agordon de dividita tunelado: plena tunelo bezonas neniun itineron por prefikso, dividita tunelo bezonas unu por ĉiu privata prefikso.

Paŝo 4: Testu private nomosolvadon aparte

Privataj nomoj havas propran politikan vojon. La profilo povas liveri NRPT-regulojn kaj liston de DNS-sufiksaj serĉoj, validajn dum la tunelo estas aktiva. Legu per Get-DnsClientNrptPolicy kion la kliento efektive ricevis, poste testu nomon kaj adreson en la sama seanco. Nomoj falantaj dum adresoj funkcias montras la solvilon; ambaŭ falantaj montras la itineron.

Nomo ankaŭ povas solviĝi al adreso ekster la itineroj de la tunelo, kio miksas sukceson kaj templimon. Komparu la revenitan adreson kun la prefikso en via rikordo; se ili diferencas, la privata zono respondas per publika aŭ alternativa adreso kaj la kongrua itinero ne estas la projektita.

Paŝo 5: Kontrolu filtrilojn, identecon kaj la propran pordegon de la programo

Trafikaj filtriloj limigas, kiuj protokoloj kaj pordoj rajtas uzi la aparatan tunelon, kaj mallarĝa aro povas bloki rimedon, kiun la itinero portus. La profilo asignas la konekton al grupo, sed la rimedo havas sian propran rajtigon: uzanto, kiu povas konekti, ne aŭtomate akceptiĝas de la dosier-servilo.

Ŝanĝu la administrata profilon tra ĝia posedanto, ĉu Intune, ProfileXML-deplojo aŭ operacia skripto, poste retestu post normala rekonekto kaj post restarto: la kutima fiasko estas malnova loka itinero aŭ profilo aplikita unufoje. Tenu la profilan version apud la testa rezulto.