Què cal preconfigurar abans de la primera connexió VPN d'un usuari

Una primera connexió VPN poques vegades falla al túnel. Falla quan un usuari corrent, en una xarxa no gestionada, segueix unes instruccions escrites per algú que ja tenia el certificat instal·lat. El perfil, la cadena de confiança i la credencial són configuració, i les tres es poden lliurar abans que l'usuari hi intervingui. El que ha de quedar per a aquest usuari han de ser quatre accions sense cap decisió a dins. Cada pas extra que deixeu al lliurament es converteix en una trucada a suport que comença amb algú llegint en veu alta un quadre de diàleg.

Què porta realment un perfil de connexió

Un perfil VPN no és una drecera ni un marcador. És un objecte amb nom al magatzem de connexions del sistema operatiu, que conté l'adreça del servidor, el tipus de túnel, el mètode d'autenticació i sovint les rutes, els sufixos DNS i les regles de desencadenament que decideixen quan es connecta. A Windows aquests camps corresponen als nodes del proveïdor de servei de configuració VPNv2, i per això un perfil pot arribar per Intune, Configuration Manager, un paquet de proveïment o un fitxer XML importat a mà.

El client aplica aquest objecte en un ordre fix: valida el certificat del servidor contra arrels de confiança, negocia el túnel i només després aplica l'encaminament i la resolució de noms abans que cap aplicació vegi una xarxa. Aquest ordre explica la majoria d'informes d'una connexió que diu que està activa mentre no carrega res: l'autenticació ha tingut èxit i el que ha fallat és el DNS o la llista de rutes. Llegiu el perfil com un sol objecte amb una seqüència, no com un conjunt d'interruptors independents. Una arrel de confiança absent falla al primer pas, abans que s'ofereixi cap credencial, i per això produeix un error genèric en lloc d'una petició d'inici de sessió.

El material de confiança és el camp que més sovint s'introdueix d'amagat a mà. El certificat de CA que signa la passarel·la ha de ser-hi abans del primer intent, i la validació del nom del servidor ha de romandre activa amb un nom que coincideixi; desactivar la validació per fer passar una prova converteix un problema d'autenticació en una intercepció silenciosa que cap usuari pot detectar.

Les quatre decisions que els usuaris no haurien de prendre mai

El protocol i el tipus de túnel van primer: trieu una combinació suportada per plataforma i documenteu el costat de la passarel·la, perquè un nom de marca conegut no és una declaració de compatibilitat. Després ve el punt final: un sol nom d'amfitrió que es resolgui públicament i coincideixi amb el certificat que presenta la passarel·la. L'autenticació pertany al sistema d'identitat, tant si és un certificat, un nom d'usuari amb un segon factor o tots dos. Cap d'aquestes és una preferència de l'usuari i cap no hauria d'aparèixer com una pregunta a les instruccions.

La quarta decisió és l'abast: túnel complet o túnel dividit, i quins prefixos i sufixos DNS hi viatgen. Un túnel dividit sense sufixos interns filtra la resolució de noms cap al resolutor que ofereixi la xarxa local, i un túnel complet sense un pla de recursos locals trenca impressores i portals captius. Totes dues són decisions de l'administrador amb efectes visibles per a l'usuari, i per això mateix l'usuari les ha de rebre ja resoltes.

Manteniu el nom de la connexió avorrit i estable. Els usuaris el diuen en veu alta a suport, el busquen en una llista del client i el recorden entre restabliments de contrasenya; canviar-lo a mig camí d'una migració crea un pic de suport que no té res a veure amb si la VPN funciona.

Lliureu la identitat per persona o per dispositiu

El perfil és públic i la clau privada no. Un error habitual de desplegament és exportar un perfil que funciona juntament amb el seu certificat i fer córrer el fitxer, cosa que fa que cada portàtil sigui un clon d'una sola identitat i converteix la revocació en una decisió de tot o res. En podeu registrar les credencials pel procés suportat: un certificat per dispositiu des del canal de gestió, o una credencial per usuari des del proveïdor d'identitat.

Els túnels de dispositiu i els túnels d'usuari s'autentiquen en moments diferents, i aquesta diferència decideix quina credencial necessiteu. Un túnel de dispositiu que es connecta abans de l'inici de sessió necessita un certificat de màquina i un perfil disponible per al sistema. Un túnel d'usuari que comença després de l'inici de sessió pot fer servir la credencial pròpia de l'usuari i no hauria d'exigir drets d'administrador. Afegir accés de xarxa a nivell de màquina només per treure un clic del matí d'algú és un mal intercanvi, perquè amplia què pot abastar un dispositiu desatès.

El registre és també on es decideix el camí de recuperació. Una renovació de certificat o un canvi de contrasenya ha d'arribar al dispositiu mentre el túnel està caigut, així que el proveïment, el proveïdor d'identitat i la passarel·la han de coincidir en com passa això; si l'única manera de reparar un perfil és a través del túnel que aquell perfil proporciona, la clau és tancada dins la caixa.

Feu coincidir el canal de lliurament amb el client

Els clients natius i de tercers es lliuren de manera diferent. Els perfils de Windows es poden lliurar com a VPNv2 ProfileXML mitjançant Intune o Configuration Manager, però no cada node s'exposa a cada superfície de gestió, i l'encaminament, el DNS i els paràmetres de desencadenament varien segons l'eina i la versió de Windows. Confirmeu quin camp és desplegable abans de prometre un desplegament sense intervenció, perquè la referència d'opcions de perfil documenta paràmetres que alguns camins de lliurament encara no poden definir.

Els clients de proveïdor afegeixen una segona capa, ja que el binari, el perfil i la política del cap de xarxa són artefactes separats. Cisco Secure Client, per exemple, admet predesplegar tant el paquet com el seu perfil, i la versió del client s'ha de coordinar amb la configuració de la passarel·la; instal·lar només el paquet deixa l'usuari dins d'un assistent.

Triï el canal que triï, manteniu una sola font de veritat per al perfil. Un perfil reparat que un paquet més antic sobreescriu a la següent comprovació és un incident recurrent, i la solució duradora és configuració versionada en lloc d'una edició manual a cada màquina.

Proveu el lliurament com un usuari nou i després proveu la recuperació

Feu una prova pilot amb un compte corrent en un dispositiu que mai s'hagi connectat, sense la sessió desada de l'administrador ni un certificat preregistrat. Confirmeu que el perfil apareix a la llista, que la petició d'inici de sessió coincideix amb les instruccions i que un recurs intern amb nom s'obre, i després comproveu la resolució de noms i l'abast de l'encaminament en lloc d'aturar-vos en una icona de connectat.

Consulteu el magatzem de perfils del dispositiu perquè la prova produeixi proves i no una impressió.

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

Després passeu pels esdeveniments que els usuaris troben de veritat: un restabliment forçat de contrasenya, un certificat renovat, una actualització del client empenyida i una xarxa que ningú del pilot ha fet servir abans. Cadascun hauria de funcionar o fallar de la manera que descriuen les instruccions. Proveu també una xarxa que bloqui el port de la VPN, perquè el primer intent en un Wi-Fi d'hotel és on l'èxit a casa deixa d'ajudar. Anoteu la versió del client i la compilació del sistema al costat de cada resultat, ja que el proper informe arribarà sense ells.

Manteniu el lliurament a l'usuari en quatre línies: el nom de la connexió, l'inici de sessió esperat, el recurs que demostra l'èxit i on enviar el text de l'error. A ningú no se li ha de demanar una contrasenya ni una clau exportada per demostrar una fallada. L'arquitectura, l'interior del perfil i el procediment de recuperació pertanyen al manual de l'administrador, arxivat al costat de la versió del client amb què es van provar.