Por que uma VPN TAP compartilhada ainda precisa de HTTPS no portal

Dois dispositivos têm credenciais VPN válidas e compartilham um único segmento Ethernet com ponte. Apenas um deles deve responder pelo portal do escritório, e o outro ainda pode reivindicar o endereço do portal nesse segmento. O túnel fez o seu trabalho: autenticou os dois pares e cifrou cada caminho até o servidor. O que ele não fez foi certificar qual deles possui um nome de serviço, e essa lacuna é a razão pela qual o portal ainda precisa de um certificado válido.

O que a VPN realmente autentica

O handshake da VPN responde a uma pergunta: qual par concluiu este túnel, e com qual material de chave. Essa resposta é por par e por conexão, e não diz nada sobre os serviços que aquele par expõe depois. Em um segmento TAP o par nem sequer é um único endereço, porque pode apresentar qualquer MAC e qualquer IP que a ponte esteja disposta a aprender. A autenticação para no ponto final do túnel, não na aplicação.

Separe as três perguntas em vez de fundi-las em uma. Cada uma tem seu próprio mecanismo e seu próprio modo de falha.

Uma implantação pode ter um túnel perfeitamente autenticado e um serviço completamente não autenticado por trás dele. Também pode ter um certificado validado em um host cujo endereço de segunda camada é reivindicado por outro par, e é por isso que os dois controles pertencem ao projeto em vez de um substituir o outro. A tabela é todo o argumento em três linhas.

ARP em um segmento compartilhado não é um diretório

O ARP mapeia um endereço IPv4 para um MAC no link local e aceita respostas de qualquer um nesse link. Em um segmento com ponte permissivo, um par pode reivindicar um endereço que pertence a outro dispositivo, e a ponte encaminha quadros para quem respondeu mais recentemente. Cifrar cada caminho de cliente até o servidor não muda isso, porque os quadros são decifrados antes de chegar à ponte. A fronteira de confiança do ARP é o segmento, não o túnel.

Veja o que o host realmente aprendeu: ip neigh show lista os mapeamentos atuais e seu estado, e uma entrada que alterna entre dois endereços MAC durante a operação normal é um sintoma que merece investigação em vez de descarte. Em um segmento pequeno e saudável, essas entradas permanecem estáveis por muito tempo.

O isolamento de pares e a política da ponte existem exatamente para este caso. Um projeto roteado costuma ser a resposta melhor quando o serviço é apenas IP e os dispositivos não têm motivo algum para ver os quadros uns dos outros.

Mantenha a validação do certificado onde o serviço está

O TLS da aplicação responde à pergunta que o túnel não consegue: é este o serviço que eu queria alcançar. O navegador verifica o nome do host contra o certificado, e essa verificação é a única parte da cadeia que nomeia o portal em vez do par.

Inspecione o que o servidor apresenta antes de decidir que o aviso é cosmético. openssl s_client -connect portal.example.internal:443 -servername portal.example.internal imprime a cadeia e os nomes alternativos do sujeito. Se o nome digitado não estiver nessa lista, o aviso está correto e o certificado é o que precisa ser corrigido. Ensinar os usuários a ignorá-lo transforma um controle funcional em decoração.

O guia de ponte do OpenVPN descreve o modelo Ethernet e as opções de política ao redor dele, e é a referência correta para o que o segmento deve permitir. Leia-o antes de relaxar uma regra de ponte, porque o modelo que ele descreve é o que cada verificação acima pressupõe.

Decida se esses pares deveriam compartilhar um segmento

A correção mais barata costuma ser parar de compartilhar a segunda camada quando o requisito é apenas alcançabilidade IP. Uma VPN roteada dá a cada cliente seu próprio endereço, remove o domínio de broadcast compartilhado e transforma o tráfego entre pares em uma decisão de política em vez de um padrão. O portal passa a ter um endereço a proteger e nenhum vizinho que possa reivindicá-lo.

Se o segmento tiver de permanecer, verifique a configuração do lado do servidor que permite aos clientes alcançar uns aos outros: grep -n client-to-client /etc/openvpn/server.conf. Quando ela está desativada, o tráfego dos clientes passa pelo servidor e pode ser filtrado ali. Quando está ativada, os pares trocam quadros diretamente pela ponte, e seus pontos de filtragem são a ponte e o firewall do host.

Anote em quais proteções cada host realmente se apoia: autenticação do túnel, isolamento do segmento ou TLS da aplicação. Um host que depende das três está bem. Um host que depende da primeira e presume que as outras duas vieram com ela é o que acaba servindo o conteúdo errado.