Por que o nome de um adaptador VPN pode ocultar outro protocolo
O rótulo ao lado de um adaptador descreve o software que o criou, não os pacotes na rede. Verifique o cliente, o perfil e o par antes de escolher uma solução.
O rótulo ao lado de um adaptador VPN descreve o software que criou a interface, e isso está uma camada acima dos pacotes que realmente atravessam a rede. Um plug-in pode expor um adaptador cujo nome reflete a classificação do próprio plug-in e não o encapsulamento na rede. Ler o cliente, o perfil e o par responde ao que o nome não pode. Duas conexões que num menu de configurações parecem idênticas podem comportar-se de forma bem diferente numa captura.
O nome vem do provedor, não da rede
O Windows define uma lista curta de tipos de conexão para os seus clientes VPN integrados, e os produtos de terceiros instalam a própria pilha ao lado deles. O adaptador que aparece na lista de redes é criado pelo driver que possui a conexão, portanto o nome é uma prova sobre o driver, não uma garantia sobre o protocolo externo. É também por isso que desinstalar um cliente pode deixar para trás o nome de um adaptador.
A documentação da Microsoft sobre os tipos de conexão VPN é explícita ao dizer que o tipo descreve a configuração do cliente para essa conexão. Quando há um plug-in envolvido, o tipo exibido segue o que o plug-in registra, e o encapsulamento real pode ser algo completamente diferente.
A mesma sobreposição aparece noutros lugares. Um adaptador virtual num anfitrião Linux, um dispositivo TAP ou uma extensão de serviço VPN móvel são todas interfaces criadas por software, e o nome da interface é escolhido por esse software em vez de negociado com o servidor.
O que as portas e os endereços podem e não podem dizer
Cada camada deixa provas diferentes. Leia-as separadamente e um rótulo deixa de ser um 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 mais claro. Pode transportar SSTP, um túnel OpenVPN TCP, uma sessão SoftEther SSL-VPN ou tráfego web comum, e o número da porta por si só não consegue distingui-los. Por isso, uma regra de firewall que permite 443 não é prova de qual cliente está a ser usado. Uma captura na interface exterior resolve a questão, e resolve-a em segundos.
Leia o formato do perfil e o par
O ficheiro de configuração é uma pista mais forte do que o adaptador. Um perfil OpenVPN contém diretivas como remote, proto e ca; uma configuração WireGuard contém uma secção [Interface] com uma chave privada e secções [Peer] com IP permitidos; uma entrada da lista telefónica do Windows guarda o tipo de conexão no seu próprio formato. Cada sintaxe pertence a uma implementação.
Depois veja a documentação e os registos do par. O servidor sabe qual gestor de protocolo aceitou a sessão, e o seu registo nomeia a etapa concluída. Essa prova supera qualquer rótulo do ambiente de trabalho, porque é registada onde os pacotes foram realmente interpretados.
Escolha o manual pelo protocolo, não pelo rótulo
Uma diretiva OpenVPN pertence ao OpenVPN, as chaves e os IP permitidos do WireGuard pertencem ao WireGuard, e um perfil SSTP não é nem um nem outro. Colar a opção de um cliente noutro porque o nome de um adaptador soava compatível é a forma como uma configuração funcional se estraga.
Assim que o protocolo é identificado, escolha o caminho de resolução de problemas correspondente: o registo do próprio cliente, o registo do servidor específico do protocolo e uma captura que mostre a troca exterior. A partir daí, a falha tem um nome em vez de um rótulo.