Por que o nome dun adaptador VPN pode ocultar outro protocolo
A etiqueta xunto a un adaptador describe o software que o creou, non os paquetes na rede. Comprobe o cliente, o perfil e o par antes de elixir unha solución.
A etiqueta xunto a un adaptador VPN describe o software que creou a interface, e iso está unha capa por riba dos paquetes que realmente atravesan a rede. Un complemento pode expor un adaptador cuxo nome reflicte a clasificación propia do complemento e non a encapsulación na rede. Ler o cliente, o perfil e o par responde ao que o nome non pode. Dúas conexións que nun menú de axustes parecen idénticas poden comportarse de forma moi distinta nunha captura.
O nome vén do provedor, non da rede
Windows define unha lista curta de tipos de conexión para os seus clientes VPN integrados, e os produtos de terceiros instalan a súa propia pila xunto a eles. O adaptador que aparece na lista de redes créao o controlador que posúe a conexión, así que o seu nome é unha proba sobre o controlador, non unha garantía sobre o protocolo exterior. Por iso tamén desinstalar un cliente pode deixar atrás o nome dun adaptador.
A documentación de Microsoft sobre os tipos de conexión VPN é explícita en que o tipo describe a configuración do cliente para esa conexión. Cando hai un complemento, o tipo mostrado segue o que rexistra o complemento, e a encapsulación real pode ser algo completamente distinto.
A mesma superposición aparece noutros lugares. Un adaptador virtual nunha máquina Linux, un dispositivo TAP ou unha extensión de servizo VPN móbil son todas interfaces creadas por software, e o nome da interface elíxeo ese software en lugar de negociarlo co servidor.
Que poden e que non poden dicirlle os portos e os enderezos
Cada capa deixa probas distintas. Léaas por separado e unha etiqueta deixa de ser un veredicto:
| Evidence | What it establishes | Where it misleads |
|---|---|---|
| Adapter name | Which driver bound the interface | Plugins choose their own labels |
| Profile file | Which client consumes the configuration | Abstraction layers hide the transport |
| Outer port | Which port the peer accepts | 443 carries several protocols plus HTTPS |
| Tunnel address | The inner interface's network | Says nothing about encapsulation |
TCP 443 é o exemplo máis claro. Pode transportar SSTP, un túnel OpenVPN TCP, unha sesión SoftEther SSL-VPN ou tráfico web normal, e o número de porto por si só non pode distinguilos. Por tanto, unha regra de firewall que permite 443 non é unha proba de que cliente se está usando. Unha captura na interface exterior resólveo, e resólveo en segundos.
Lea o formato do perfil e o par
O ficheiro de configuración é unha pista máis forte que o adaptador. Un perfil OpenVPN contén directivas como remote, proto e ca; unha configuración WireGuard contén unha sección [Interface] cunha clave privada e seccións [Peer] con IP permitidas; unha entrada da axenda de teléfonos de Windows garda o tipo de conexión no seu propio formato. Cada sintaxe pertence a unha implementación.
Despois mire a documentación e os rexistros do par. O servidor sabe que xestor de protocolo aceptou a sesión, e o seu rexistro nomea a etapa que se completou. Esa proba supera calquera etiqueta do escritorio, porque se rexistra onde os paquetes se interpretaron realmente.
Elixa o manual por protocolo, non por etiqueta
Unha directiva OpenVPN pertence a OpenVPN, as claves e as IP permitidas de WireGuard pertencen a WireGuard, e un perfil SSTP non é nin unha cousa nin a outra. Pegar a opción dun cliente noutro porque o nome dun adaptador soaba compatible é como se rompe unha configuración que funcionaba.
Unha vez identificado o protocolo, elixa a ruta de solución de problemas correspondente: o rexistro propio do cliente, o rexistro do servidor específico do protocolo e unha captura que mostre o intercambio exterior. A partir de aí, o fallo ten un nome en lugar dunha etiqueta.