Always On on yhteyden elinkaari: profiili yhdistää kirjautumisen yhteydessä tai ennen sitä ja palauttaa yhteyden ilman, että käyttäjä painaa mitään. Tämä ei tarkoita, että jokainen yksityinen kohde, protokolla ja käyttäjä on sallittu. Käytännön kysymys on, mitä resursseja käyttöönotettu profiili todella toimittaa, ja vastaus vaatii tarkistuksen resurssi kerrallaan, ei vilkaisua Connected-merkkiin.

Vaihe 1: Kirjaa resurssi ennen testaamista

Aloita lyhyellä tietueella jokaisesta sovelluksesta ja ota arvot todellisesta ympäristöstä: nimi, kohdeprefiksi, palvelu ja portti, tunnelin rooli, identiteettiryhmä ja resolverin polku.

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

Tietue pakottaa neljään erilliseen kysymykseen. Reitti päättää, minne osoite menee; DNS-käytäntö päättää, miten asiakas oppii osoitteen; liikennesuodatin päättää, saako kyseinen liikenne käyttää yhteyttä; kohteen palomuuri ja sovelluksen käyttöoikeudet päättävät, hyväksytäänkö pyyntö. Mikään näistä neljästä ei seuraa yhdistetystä tunnelista.

Vaihe 2: Määritä, minkä tunnelin se pitää kuljettaa

Windows Always On VPN:ssä on laite- ja käyttäjätunneli, jotka määritetään erillisinä profiileina erillisillä varmenteilla ja laajuuksilla. Laite tunneli kuljettaa yleensä vain ennen kirjautumista tarvittavan infrastruktuurin, kuten hallinnan ja toimialueen palvelut; työntekijöiden laaja sovelluskäyttö kuuluu käyttäjätunneliin.

Liikennesuodattimet ovat laitetunnelin ominaisuus, minkä vuoksi Microsoftin esimerkki käyttää niitä hallintaliikenteeseen. Jos esimerkki kopioidaan yleiseen resurssiprofiiliin, saadaan tunneli, joka yhdistää mutta kuljettaa väärän joukon. Vahvista aktiivinen yhteys komennolla Get-VpnConnection ja testaa kyseisen yhteyden alla.

Vaihe 3: Varmista reitti todelliselle osoitteelle

Ratkaise nimi kerran ja tarkista sitten reitti: Find-NetRoute -RemoteIPAddress 10.20.5.10 näyttää valitun liitännän, seuraavan hypyn ja lähdeosoitteen. Jos liitäntä on fyysinen sovitin, prefiksi puuttuu tunnelin reittijoukosta tai asiakas on sulkenut sen pois jaetulla tunnelilla. Vertaa profiilin määritelmään sen sijaan, että lisäisit paikallisen reitin.

Paikallinen route add voi saada testin onnistumaan ja kadota seuraavassa käytäntöpäivityksessä, joten muutos kuuluu hallittuun profiiliin. Tarkista prefiksi sekä käyttäjä- että laiteprofiilista ja jaetun tunnelin asetus: täysi tunneli ei tarvitse reittiä per prefiksi, jaettu tunneli tarvitsee yhden jokaiselle yksityiselle prefiksille.

Vaihe 4: Testaa yksityisten nimien ratkaisu erikseen

Yksityisillä nimillä on oma käytäntöpolkunsa. Profiili voi toimittaa NRPT-säännöt ja DNS-liitteiden hakutulun, jotka ovat voimassa tunnelin ollessa ylhäällä. Lue komennolla Get-DnsClientNrptPolicy, mitä asiakas todella sai, ja testaa sitten nimi ja osoite samassa istunnossa. Jos nimet epäonnistuvat osoitteiden toimiessa, kyse on resolverista; jos molemmat, reitistä.

Nimi voi myös ratketa osoitteeksi tunnelin reittien ulkopuolella, mikä sekoittaa onnistumisen ja aikakatkaisun. Vertaa palautettua osoitetta tietueesi prefiksiin; jos ne eroavat, yksityinen vyöhyke vastaa julkisella tai vaihtoehtoisella osoitteella eikä täsmäävä reitti ole suunniteltu.

Vaihe 5: Tarkista suodattimet, identiteetti ja sovelluksen oma portti

Liikennesuodattimet rajaavat, mitkä protokollat ja portit saavat käyttää laitetunnelia, ja kapea joukko voi estää resurssin, jonka reitti kuljettaisi. Profiili osoittaa yhteyden ryhmälle, mutta resurssilla on oma valtuutuksensa: yhdistämään pystyvää käyttäjää ei automaattisesti hyväksytä tiedostopalvelimella.

Muuta hallittua profiilia sen omistajan kautta, oli se sitten Intune, ProfileXML-jakelu tai ylläpidon skripti, ja testaa uudelleen tavallisen uudelleenyhdistämisen ja uudelleenkäynnistyksen jälkeen: tavallinen vika on vanhentunut paikallinen reitti tai kerran sovellettu profiili. Pidä profiilin versio testituloksen vieressä.

Aiheeseen liittyvät artikkelit