Mitä määrittää valmiiksi ennen käyttäjän ensimmäistä VPN-yhteyttä

Ensimmäinen VPN-yhteys harvoin epäonnistuu tunnelissa. Se epäonnistuu, kun tavallinen käyttäjä hallitsemattomassa verkossa seuraa ohjeita, jotka kirjoitti joku, jolla oli varmenne jo asennettuna. Profiili, luottamusketju ja tunnistetieto ovat kokoonpanoa, ja kaikki kolme voidaan toimittaa ennen kuin käyttäjä on mukana. Sille käyttäjälle pitäisi jäädä neljä toimintoa ilman päätöksiä niiden sisällä. Jokainen ylimääräinen vaihe, jonka luovutukseen jätät, muuttuu tukipuheluksi, joka alkaa siitä, että joku lukee dialogin ääneen.

Mikä yhteysprofiili oikeasti sisältää

VPN-profiili ei ole pikakuvake eikä kirjanmerkki. Se on nimetty objekti käyttöjärjestelmän yhteysvarastossa, ja se sisältää palvelimen osoitteen, tunnelin tyypin, todennusmenetelmän ja usein reitit, DNS-liitteet ja liipaisinsäännöt, jotka päättävät, milloin se yhdistää. Windowsissa nämä kentät vastaavat VPNv2-määrityspalveluntarjoajan solmuja, minkä vuoksi yksi profiili voi saapua Intunen, Configuration Managerin, valmistelupaketin tai käsin tuodun XML-tiedoston kautta.

Asiakasohjelma soveltaa tätä objektia kiinteässä järjestyksessä: se validoi palvelimen varmenteen luotettuja juuria vastaan, neuvottelee tunnelin ja soveltaa vasta sitten reititystä ja nimien ratkaisua ennen kuin sovellus näkee verkon. Tämä järjestys selittää useimmat raportit yhteydestä, joka väittää olevansa pystyssä, kun mikään ei lataudu: todennus onnistui ja DNS tai reittilista oli se, mikä todella epäonnistui. Lue profiili yhtenä objektina, jolla on järjestys, ei itsenäisten kytkimien joukkona. Puuttuva luottamusjuuri epäonnistuu ensimmäisessä vaiheessa, ennen kuin mitään tunnistetietoa tarjotaan, ja siksi se tuottaa yleisen virheen kirjautumiskehotteen sijaan.

Luottamusmateriaali on kenttä, joka useimmin salakuljetetaan käsin. Yhdyskäytävän allekirjoittava CA-varmenne on oltava paikalla ennen ensimmäistä yritystä, ja palvelimen nimen validoinnin on pysyttävä päällä vastaavan nimen kanssa; validoinnin poistaminen käytöstä testin läpäisemiseksi muuttaa todennusongelman hiljaiseksi sieppaukseksi, jota mikään käyttäjä ei voi havaita.

Neljä valintaa, joita käyttäjien ei pitäisi koskaan tehdä

Protokolla ja tunnelin tyyppi tulevat ensin: valitse yksi tuettu yhdistelmä alustaa kohden ja dokumentoi yhdyskäytävän puoli, koska tuttu tuotenimi ei ole yhteensopivuuslausunto. Seuraavaksi päätepiste: yksi isäntänimi, joka ratkeaa julkisesti ja vastaa varmennetta, jonka yhdyskäytävä esittää. Todennus kuuluu identiteettijärjestelmään, tarkoitti se sitten varmennetta, käyttäjätunnusta toisella tekijällä tai molempia. Mikään näistä ei ole käyttäjän mieltymys, eikä minkään pitäisi näkyä kysymyksenä ohjeissa.

Neljäs valinta on laajuus: täysi tunneli vai jaettu tunneli, ja mitkä etuliitteet ja DNS-liitteet kulkevat sen sisällä. Jaettu tunneli ilman sisäisiä liitteitä vuotaa nimien ratkaisun mille tahansa ratkaisijalle, jota paikallisverkko tarjoaa, ja täysi tunneli ilman paikallisten resurssien suunnitelmaa rikkoo tulostimet ja vangitut portaalit. Molemmat ovat ylläpitäjän päätöksiä, joilla on käyttäjälle näkyviä vaikutuksia, ja juuri siksi käyttäjän pitäisi saada ne jo ratkaistuina.

Pidä yhteyden nimi tylsänä ja vakaana. Käyttäjät lukevat sen ääneen tuelle, etsivät sitä asiakasluettelosta ja muistavat sen salasanan nollausten välillä; sen uudelleennimeäminen kesken siirtymän luo tukipiikin, jolla ei ole mitään tekemistä sen kanssa, toimiiko VPN.

Toimita identiteetti henkilöä tai laitetta kohden

Profiili on julkinen, yksityinen avain ei. Yleinen käyttöönoton virhe on viedä yksi toimiva profiili varmenteineen ja kierrättää tiedostoa, mikä tekee jokaisesta kannettavasta yhden identiteetin kloonin ja muuttaa peruutuksen kaikki-tai-ei-mitään-päätökseksi. Rekisteröi tunnistetiedot sen sijaan tuetun prosessin kautta: laitekohtainen varmenne hallintakanavasta tai käyttäjäkohtainen tunnistetieto identiteettipalveluntarjoajalta.

Laite- ja käyttäjätunnelit todentuvat eri hetkinä, ja tämä ero päättää, mitä tunnistetietoa tarvitset. Ennen kirjautumista yhdistyvä laitetunneli tarvitsee konepisteen varmenteen ja järjestelmälle saatavilla olevan profiilin. Kirjautumisen jälkeen alkava käyttäjätunneli voi käyttää käyttäjän omaa tunnistetietoa, eikä sen pitäisi vaatia ylläpitäjän oikeuksia. Verkkoyhteyden lisääminen konetasolla vain yhden napsautuksen poistamiseksi jonkun aamusta on huono vaihtokauppa, koska se laajentaa sitä, mihin valvomaton laite pääsee.

Rekisteröinti on myös paikka, jossa palautuspolku päätetään. Varmenteen uusinta tai salasanan vaihto täytyy saada laitteelle, kun tunneli on alhaalla, joten valmistelun, identiteettipalveluntarjoajan ja yhdyskäytävän on sovittava, miten se tapahtuu; jos ainoa tapa korjata profiili on sen profiilin tarjoaman tunnelin kautta, avain on lukittuna laatikon sisään.

Sovita toimitustie asiakasohjelmaan

Natiivit ja kolmannen osapuolen asiakasohjelmat toimitetaan eri tavoin. Windows-profiilit voidaan toimittaa VPNv2 ProfileXML:nä Intunen tai Configuration Managerin kautta, mutta kaikki solmut eivät ole näkyvissä kaikilla hallintapinnoilla, ja reititys-, DNS- ja liipaisinasetukset vaihtelevat työkalun ja Windows-version mukaan. Vahvista, mikä kenttä on käyttöön otettavissa, ennen kuin lupaat kosketuksettoman käyttöönoton, sillä profiilivalintojen viite dokumentoi asetuksia, joita jotkin toimitustiet eivät vieläkään pysty asettamaan.

Toimittajien asiakasohjelmat lisäävät toisen kerroksen, koska binääri, profiili ja pääsolmun käytäntö ovat erillisiä artefakteja. Cisco Secure Client esimerkiksi tukee sekä paketin että sen profiilin ennakkotoimitusta, ja asiakasohjelman versio on sovitettava yhdyskäytävän kokoonpanon kanssa; pelkän paketin asentaminen jättää käyttäjän ohjattuun toimintoon.

Minkä tahansa kanavan valitsetkin, pidä profiilille yksi totuuden lähde. Korjattu profiili, jonka vanhempi paketti ylikirjoittaa seuraavassa tarkistuksessa, on toistuva tapaus, ja kestävä ratkaisu on versioitu kokoonpano eikä käsin tehty muokkaus jokaisella koneella.

Testaa luovutus uutena käyttäjänä ja testaa sitten palautus

Pilotoi tavallisella tilillä laitteella, joka ei ole koskaan yhdistänyt, ilman ylläpitäjän tallennettua istuntoa tai ennalta rekisteröityä varmennetta. Vahvista, että profiili näkyy luettelossa, että kirjautumiskehote vastaa ohjeita ja että nimetty sisäinen resurssi avautuu, ja tarkista sitten nimien ratkaisu ja reitityksen laajuus sen sijaan, että pysähtyisit yhdistetty-kuvakkeeseen.

Kysy laitteen profiilivarastoa, jotta testi tuottaa todisteita eikä vaikutelmaa.

Get-VpnConnection -AllUserConnection | Select-Object Name, ServerAddress, TunnelType, AuthenticationMethod, SplitTunneling
Get-VpnConnection -Name "Corp VPN" | Format-List
Test-NetConnection intranet.example.com -Port 443

Käy sitten läpi tapahtumat, joita käyttäjät todella kohtaavat: pakotettu salasanan nollaus, uusittu varmenne, työnnetty asiakasohjelman päivitys ja verkko, jota kukaan pilottiryhmässä ei ole käyttänyt. Jokaisen pitäisi joko toimia tai epäonnistua niin kuin ohjeet kuvaavat. Kokeile myös verkkoa, joka estää VPN-portin, sillä ensimmäinen yritys hotellin Wi-Fi-verkossa on paikka, jossa kotona saatu onnistuminen lakkaa auttamasta. Kirjaa asiakasohjelman versio ja käyttöjärjestelmän build jokaisen tuloksen viereen, koska seuraava raportti saapuu ilman niitä.

Pidä käyttäjälle suunnattu luovutus neljässä rivissä: yhteyden nimi, odotettu kirjautuminen, onnistumisen todistava resurssi ja minne virheteksti lähetetään. Keneltäkään ei pitäisi pyytää salasanaa tai vietyä avainta epäonnistumisen osoittamiseksi. Arkkitehtuuri, profiilin sisäosat ja palautusmenettely kuuluvat ylläpitäjän käsikirjaan, arkistoituna sen asiakasohjelman version viereen, jolla ne testattiin.