VPN de Windows contra Cisco Secure Client: quin és el correcte?
Una marca no anomena cap protocol: Windows ofereix diversos tipus natius i el client de Cisco porta perfils per a més d’un mode. Llegeix el perfil.
Per a la mateixa passarel·la arriben dues instruccions: connecta’t amb la VPN de Windows o instal·la el client de Cisco. Cap de les dues no diu quin intercanvi espera la passarel·la, perquè Windows exposa diversos tipus de connexió natius i el client del fabricant porta perfils per a més d’un mode. Totes dues etiquetes descriuen programari, mentre que la passarel·la negocia protocol, autenticació i política. La resposta és al perfil, i es pot llegir sense connectar-s’hi.
L’etiqueta anomena programari, no un intercanvi
Una marca i un sistema operatiu són dos fets diferents, i cap dels dos no tria un format de cable. Windows inclou un conjunt de tipus natius, i el client de Cisco inclou un motor de perfils que pot fer anar SSL o IPsec/IKEv2. Confondre’ls produeix gràfics que comparen empreses en lloc de comparar intercanvis.
La taula següent substitueix la pregunta sobre el producte per tres llocs de lectura i el camp que guarda cadascun. Anota aquests camps i l’ambigüitat desapareix:
| Where to read it | Field name to record | What a mismatch looks like |
|---|---|---|
| Native Windows profile | TunnelType and AuthenticationMethod from Get-VpnConnection | The client offers IKEv2 while the gateway answers only on an SSL port |
| Vendor client profile | SSL or IPsec/IKEv2 mode, plus the client and headend version pair | The imported profile negotiates a mode this headend does not serve |
| Gateway configuration | Protocol, authentication policy and the certificate the headend presents | The client authenticates and then drops, because policy expects another method |
La referència de tipus de VPN de Windows que publica Microsoft enumera IKEv2 i SSTP entre els tipus natius, cosa que descarta la idea que un perfil natiu vol dir PPTP. La documentació de perfils de Cisco descriu tant el mode SSL com l’IPsec/IKEv2 amb la política corresponent del concentrador. Cada fabricant ofereix diverses opcions, així que cap dels noms no identifica un sol protocol.
Què posen els tipus natius al cable
IKEv2 negocia associacions de seguretat per UDP i porta el trànsit dins d’IPsec, cosa que el fa un igual d’altres implementacions d’IKEv2 i no un disseny específic de Microsoft. SSTP embolcalla PPP dins d’una sessió HTTPS, així que travessa servidors intermediaris que IKEv2 no pot i al cable sembla TLS sense ser un protocol VPN de TLS. Aquests dos fets expliquen bona part d’una incidència que diu que el túnel funciona en una xarxa i falla en una altra.
L2TP amb IPsec i l’entrada més antiga PPTP són al mateix desplegable, i la seva presència allà no diu res sobre el suport del servidor. Un desplegable és un menú del que el sistema operatiu pot intentar, no una declaració de capacitats de la passarel·la. Llegir-lo com una llista de suport és com comença una cacera de credencials de dues hores.
Els camps que importen d’un perfil natiu són el tipus de connexió, el mètode d’autenticació i la identitat del servidor. Un tipus equivocat falla en una etapa diferent que una contrasenya dolenta, i aquesta diferència és la pista que val la pena seguir.
Què afegeix un client de fabricant: perfils, no un protocol
El client de Cisco és un contenidor de perfils. Un mode SSL i un mode IPsec/IKEv2 difereixen en l’intercanvi, les expectatives de port i el text d’error, i el perfil importat tria entre tots dos. Per tant, instal·lar el client no demostra res sobre l’abastabilitat.
Les versions s’aparellen per una raó. Les funcions, els fluxos d’autenticació i les comprovacions de postura es negocien entre client i concentrador, així que un client antic contra un concentrador nou pot fallar d’una manera que es llegeix com una fallada de xarxa. Aquest aparellament pertany a la definició de connexió, no a una nota d’actualització.
Un perfil exportat d’una altra organització poques vegades encaixa amb el concentrador local, i importar-lo pot deixar el client oferint un mode que la passarel·la no serveix. Llegeix primer el mode del perfil i després compara’l amb el protocol i la política d’autenticació configurats a la passarel·la. Només quan coincideixen la xarxa es converteix en sospitosa. Aquest ordre estalvia una captura de paquets que hauria mostrat una sessió TLS sana apuntant al servei equivocat.
Llegeix el perfil local abans de canviar res
A Windows la configuració nativa es pot llegir sense marcar, i la sortida anomena el tipus i el mètode d’autenticació directament. Compara aquests valors amb el que el propietari de la passarel·la diu que accepta el concentrador. Si el tipus no concorda amb la incidència, corregeix primer la incidència, perquè és més barat que reinstal·lar un client que mai no s’havia equivocat.
Aquestes quatre ordres cobreixen el perfil, les seves rutes, l’intent de connexió i l’abastabilitat del port. Executa-les en aquest ordre en una màquina que ja tingui el perfil instal·lat:
Get-VpnConnection | Format-List Name,TunnelType,AuthenticationMethod,ServerAddress
Get-VpnConnection -Name 'Corp' | Select-Object -ExpandProperty Routes
rasdial
Test-NetConnection -ComputerName vpn.example.com -Port 443La prova del port és la que es llegeix massa. Un oient TCP 443 que serveix una pàgina d’inici de sessió i un que acaba IKEv2 semblen idèntics des de fora, perquè el port és un lloc i no un protocol.
Escriu el resultat com a tres camps, client, mode i passarel·la, i guarda’ls al costat de la incidència. Qualsevol cosa més curta deixa a la persona següent redescobrir la mateixa ambigüitat.