Always On VPN vai VPN On Demand iPhonessa: mitä ottaa käyttöön
On Demand avaa tunnelin, kun sen säännöt täyttyvät; hallittu Always On pitää kattavuuden pakotettuna valvotuissa laitteissa. Opas valintaan ja sen todistamiseen, että se toimii.
Kaksi iPhonea voivat molemmat sanoa VPN ja käyttäytyä täysin eri tavoin. On Demand avaa tunnelin, kun sääntö täyttyy, ja käyttäjä voi silti kytkeä sen pois Asetuksista. Hallittu Always On pitää kattavuuden pakotettuna valvotussa laitteessa, myös hetkinä jolloin tunneli ei nouse. Valitse kysymällä, mikä on oltava totta, kun käyttäjä ei tee mitään, ja testaa sitten siirtymät eikä vakaata tilaa. Alla olevat vaiheet etenevät siinä järjestyksessä, jossa käyttöönotto todella epäonnistuu.
Vaihe 1: selvitä, mitä laite voi pakottaa
Always On on valvottujen laitteiden ominaisuus. Jos laitekanta ei ole valvottu, keskustelu päättyy ennen alkuaan, eikä mikään payload-avain tee valvomattomasta puhelimesta pakotettua. Vahvista valvonta hallinnan puolelta ja laitteesta ja vahvista sitten, kuka profiilin allekirjoitti.
Puhelimessa: Asetukset, sitten Yleiset, sitten VPN ja laitehallinta. Profiilimerkintä nimeää omistajansa, ja käsin asennettu henkilökohtainen profiili näyttää erilaiselta kuin hallintapalvelun toimittama. Älä päättele pakotusta profiilin nimestä tai toimittajan markkinointitarrasta; tarra ei ole alustan käytäntö.
Kirjoita kolme tosiasiaa ennen kuin kosket asetuksia: valvottu vai ei, hallittu vai henkilökohtainen profiili ja mikä asiakasohjelma tunnelia kantaa. Jokainen myöhempi vaihe riippuu näistä kolmesta, ja käyttäytymisen siirtäminen henkilökohtaisesta puhelimesta hallittuun profiiliin on tapa hyväksyä käyttöönotto väärää perustaa vasten.
Vaihe 2: lue on-demand-säännöt, älä ominaisuuden nimeä
On Demand on järjestyksessä arvioitava sääntöluettelo. Jokainen sääntö nimeää toiminnon ja ehdot, jotka sen valitsevat, ja ehdot ovat kiinnostava osa: liitännän tyyppi, Wi-Fi-SSID, DNS-toimialueen pääte tai kokeilu-URL. Sääntöjoukko, joka ei koskaan täyty, on ominaisuus, joka ei koskaan yhdistä.
<key>OnDemandRules</key>
<array>
<dict>
<key>Action</key><string>EvaluateConnection</string>
<key>InterfaceTypeMatch</key><string>WiFi</string>
<key>SSIDMatch</key><array><string>Office-WiFi</string></array>
</dict>
</array>
Lue koko taulukko ja esitä jokaiselle säännölle kaksi kysymystä: voiko tämä ehto koskaan olla totta tässä laitekannassa, ja mitä tapahtuu, kun mikään sääntö ei täyty? Yritysverkot nimeävät tukiasemia uudelleen, yhdistävät SSID:itä ja vaihtavat DNS-päätteitä, ja jokainen sellainen muutos irrottaa säännön todellisuudesta hiljaa.
DNS-päätteen ehto on kentällä useimmin väärin, koska päätelaitteen vieraassa verkossa ilmoittama pääte ei ole se, jota yrityksen ratkaisija palvelee. Varmista nimi, jonka laite todella ratkaisee, ennen kuin luotat sääntöön.
Vaihe 3: testaa siirtymät, älä staattista yhteyttä
Tunneli, joka on pystyssä kun katsot sitä, todistaa hyvin vähän. Suorita jokainen siirtymä tarkoituksella ja kirjaa, mitä laite tekee, käyttäen joka kerta samaa yksityistä resurssia, jotta tulokset ovat vertailukelpoisia:
- Liity verkkoon, jossa säännön pitäisi täyttyä, pyydä sitten yksityistä resurssia ja vahvista, että se latautuu.
- Vaihda mobiiliverkkoon sovelluksen ollessa taustalla, tuo se sitten eteen ja toista pyyntö.
- Yhdistä Wi-Fiin, jossa on captive portal, ja katso, onko portaali tavoitettavissa vai estääkö pakotus sen ennen tunnistautumista.
- Kytke tunneli käsin pois valvotussa laitteessa ja tarkista, palaako se itsestään ja kuinka nopeasti.
Suorita sama luettelo valvomattomassa laitteessa, jos sellainen on. Kahden tuloksen ero on käyttöönoton todellinen käyttäytyminen, ja juuri sitä yhdistetyn tunnelin kuvakaappaus ei koskaan näytä.
Vaihe 4: tunne kaksi epäonnistumisen muotoa
Pakotettu kattavuus epäonnistuu estämällä. Kun tunnelia ei saada pystyyn, laite menettää tavallisen internetyhteyden yksityisten resurssien mukana, ja käyttäjä kokee puhelimen, joka on verkossa mutta ei voi selata. Yhdistäminen uudelleen ja estäminen ovat erillisiä havaintoja, joten kirjaa molemmat sen sijaan että käsittelisit internetin puuttumista yhtenä oireena.
On Demand epäonnistuu olemalla käynnistymättä. Sääntö ei täyty, tunnelia ei ilmesty ja yksityinen resurssi yksinkertaisesti vanhenee. Se on helppo diagnosoida väärin palvelinongelmaksi, koska asiakasohjelma käyttäytyy täsmälleen kuten on määritetty.
Captive portal on näiden kahden välissä: se tarvitsee yhteyden ennen kuin tunnelia on olemassa, joten käytäntö, joka estää kaiken kunnes tunneli nousee, tarvitsee dokumentoidun reitin portaalista. Päätä se suunnittelussa, älä tukipisteessä.
Vaihe 5: vahvista ja harjoittele sitten peruutus
Vahvistus kuuluu todelliselle polulle vaarattomalla liikenteellä: pyydä yksityistä resurssia, joka ei saa olla julkinen, vahvista minkä osoitteen laite näyttää ulospäin ja toista uudelleenkäynnistyksen jälkeen, jotta olet nähnyt käynnistysjakson eikä vain lämmintä tilaa.
Harjoittele sitten poistoa testilaitteessa ennen kuin tarvitset sitä tuotannossa. Profiilin poisto palauttaa laitteen aiempaan tilaansa, ja tieto siitä, kuinka kauan se kestää ja mitä käyttäjä näkee, on osa runbookia. Applen VPN-turvaopas on viite siihen, mitä alusta dokumentoi näistä käytännöistä, ja se kannattaa lukea ennen sellaisen kokoonpanon kirjoittamista, joka väittää enemmän kuin alusta.
Pidä ensimmäisen vaiheen kolme tosiasiaa sääntöjoukon ja testitulosten vieressä. Kun seuraava henkilö kysyy, miksi puhelin yhdistää yhdessä verkossa eikä toisessa, nuo muistiinpanot vastaavat minuutissa uudelleenrakentamisen sijaan.