Por que unha VPN TAP compartida segue necesitando HTTPS no portal
Unha VPN TAP autentica o par, non o servizo que hai detrás. Mantén a validación do nome de host no portal e illa os veciños nos que non confías.
Dous dispositivos teñen credenciais VPN válidas e comparten un único segmento Ethernet ponteado. Só un deles debe responder polo portal da oficina, e o outro aínda pode reclamar o enderezo do portal nese segmento. O túnel fixo o seu traballo: autenticou ambos os pares e cifrou cada ruta ata o servidor. O que non fixo foi certificar cal deles posúe un nome de servizo, e esa lagoa é a razón pola que o portal segue necesitando un certificado válido.
Que autentica realmente a VPN
O aperto de mans da VPN responde a unha pregunta: que par completou este túnel e con que material de chave. Esa resposta é por par e por conexión, e non di nada sobre os servizos que ese par expón despois. Nun segmento TAP o par nin sequera é un só enderezo, porque pode presentar calquera MAC e calquera IP que a ponte estea disposta a aprender. A autenticación detense no extremo do túnel, non na aplicación.
Separa as tres preguntas en lugar de fundilas nunha. Cada unha ten o seu propio mecanismo e o seu propio modo de fallo.
| Question | Answered by |
|---|---|
| Which peer sent this packet? | VPN transport authentication |
| Which device owns this IPv4 address? | ARP, trusted only as far as the segment |
| Which service am I talking to? | Application TLS and hostname validation |
Un despregamento pode ter un túnel perfectamente autenticado e un servizo completamente non autenticado detrás. Tamén pode ter un certificado validado nun host cuxo enderezo de segunda capa reclama outro par, e por iso ambos os controis pertencen ao deseño en lugar de que un substitúa o outro. A táboa é todo o argumento en tres filas.
ARP nun segmento compartido non é un directorio
ARP asigna un enderezo IPv4 a unha MAC na ligazón local e acepta respostas de calquera nesa ligazón. Nun segmento ponteado permisivo, un par pode reclamar un enderezo que pertence a outro dispositivo, e a ponte reenvía as tramas a quen respondeu máis recentemente. Cifrar cada ruta de cliente ata o servidor non cambia iso, porque as tramas descífranse antes de chegar á ponte. A fronteira de confianza de ARP é o segmento, non o túnel.
Mira o que o host aprendeu realmente: ip neigh show lista as asignacións actuais e o seu estado, e unha entrada que alterna entre dous enderezos MAC durante o funcionamento normal é un síntoma que merece investigarse en lugar de descartarse. Nun segmento pequeno e san esas entradas permanecen estables durante moito tempo.
O illamento de pares e a política da ponte existen exactamente para este caso. Un deseño encamiñado adoita ser a mellor resposta cando o servizo é só IP e os dispositivos non teñen ningún motivo para ver as tramas dos demais.
Mantén a validación do certificado onde está o servizo
O TLS da aplicación responde á pregunta que o túnel non pode: é este o servizo ao que quería chegar. O navegador comproba o nome de host contra o certificado, e esa comprobación é a única parte da cadea que nomea o portal en lugar do par.
Inspecciona o que presenta o servidor antes de decidir que o aviso é cosmético. openssl s_client -connect portal.example.internal:443 -servername portal.example.internal imprime a cadea e os nomes alternativos do suxeito. Se o nome que escribiches non está nesa lista, o aviso é correcto e o certificado é o que hai que arranxar. Ensinar os usuarios a saltalo converte un control funcional en decoración.
A guía de ponteo de OpenVPN describe o modelo Ethernet e as opcións de política que o rodean, e é a referencia correcta para o que o segmento debe permitir. Léaa antes de relaxar unha regra de ponte, porque o modelo que describe é o que asume cada comprobación anterior.
Decide se eses pares deben compartir un segmento
A solución máis barata adoita ser deixar de compartir a segunda capa cando o requisito é só a alcanzabilidade IP. Unha VPN encamiñada dá a cada cliente o seu propio enderezo, elimina o dominio de difusión compartido e converte o tráfico entre pares nunha decisión de política en lugar dun valor por defecto. O portal ten entón un enderezo que protexer e ningún veciño que poida reclamalo.
Se o segmento ten que quedar, comproba o axuste do lado do servidor que permite aos clientes alcanzarse: grep -n client-to-client /etc/openvpn/server.conf. Con el desactivado, o tráfico dos clientes pasa polo servidor e pode filtrarse alí. Con el activado, os pares intercambian tramas directamente a través da ponte e os teus puntos de filtrado son a ponte e o cortalumes do host.
Anota en que proteccións confía realmente cada host: autenticación do túnel, illamento do segmento ou TLS da aplicación. Un host que depende das tres está ben. Un host que depende da primeira e asume que as outras dúas viñeron con ela é o que acaba servindo o contido equivocado.