Por qué una VPN TAP compartida sigue necesitando HTTPS en el portal

Dos dispositivos tienen credenciales VPN válidas y comparten un único segmento Ethernet puenteado. Solo uno de ellos debe responder por el portal de la oficina, y el otro todavía puede reclamar la dirección del portal en ese segmento. El túnel hizo su trabajo: autenticó a ambos pares y cifró cada ruta hasta el servidor. Lo que no hizo fue certificar cuál de ellos posee un nombre de servicio, y esa laguna es la razón por la que el portal sigue necesitando un certificado válido.

Qué autentica realmente la VPN

El saludo de la VPN responde a una pregunta: qué par completó este túnel y con qué material de clave. Esa respuesta es por par y por conexión, y no dice nada sobre los servicios que ese par expone después. En un segmento TAP el par ni siquiera es una sola dirección, porque puede presentar cualquier MAC y cualquier IP que el puente esté dispuesto a aprender. La autenticación se detiene en el extremo del túnel, no en la aplicación.

Separa las tres preguntas en lugar de fundirlas en una. Cada una tiene su propio mecanismo y su propio modo de fallo.

Un despliegue puede tener un túnel perfectamente autenticado y un servicio completamente no autenticado detrás. También puede tener un certificado validado en un host cuya dirección de segunda capa reclama otro par, y por eso ambos controles pertenecen al diseño en lugar de que uno sustituya al otro. La tabla es todo el argumento en tres filas.

ARP en un segmento compartido no es un directorio

ARP asigna una dirección IPv4 a una MAC en el enlace local y acepta respuestas de cualquiera en ese enlace. En un segmento puenteado permisivo, un par puede reclamar una dirección que pertenece a otro dispositivo, y el puente reenvía las tramas a quien respondió más recientemente. Cifrar cada ruta de cliente hasta el servidor no cambia eso, porque las tramas se descifran antes de llegar al puente. La frontera de confianza de ARP es el segmento, no el túnel.

Mira lo que el host ha aprendido realmente: ip neigh show lista las asignaciones actuales y su estado, y una entrada que alterna entre dos direcciones MAC durante el funcionamiento normal es un síntoma que merece investigarse en lugar de descartarse. En un segmento pequeño y sano esas entradas permanecen estables durante mucho tiempo.

El aislamiento de pares y la política del puente existen exactamente para este caso. Un diseño enrutado suele ser la mejor respuesta cuando el servicio es solo IP y los dispositivos no tienen ningún motivo para ver las tramas de los demás.

Mantén la validación del certificado donde está el servicio

El TLS de la aplicación responde a la pregunta que el túnel no puede: ¿es este el servicio al que quería llegar? El navegador comprueba el nombre de host contra el certificado, y esa comprobación es la única parte de la cadena que nombra al portal en lugar del par.

Inspecciona lo que presenta el servidor antes de decidir que la advertencia es cosmética. openssl s_client -connect portal.example.internal:443 -servername portal.example.internal imprime la cadena y los nombres alternativos del sujeto. Si el nombre que escribiste no está en esa lista, la advertencia es correcta y el certificado es lo que hay que arreglar. Enseñar a los usuarios a saltársela convierte un control funcional en decoración.

La guía de puenteo de OpenVPN describe el modelo Ethernet y las opciones de política que lo rodean, y es la referencia correcta para lo que el segmento debe permitir. Léela antes de relajar una regla de puente, porque el modelo que describe es lo que asume cada comprobación anterior.

Decide si esos pares deberían compartir un segmento

El remedio más barato suele ser dejar de compartir la segunda capa cuando el requisito es solo alcanzabilidad IP. Una VPN enrutada da a cada cliente su propia dirección, elimina el dominio de difusión compartido y convierte el tráfico entre pares en una decisión de política en lugar de un valor por defecto. El portal tiene entonces una dirección que proteger y ningún vecino que pueda reclamarla.

Si el segmento tiene que quedarse, comprueba el ajuste del lado del servidor que permite a los clientes alcanzarse: grep -n client-to-client /etc/openvpn/server.conf. Con él desactivado, el tráfico de los clientes pasa por el servidor y puede filtrarse allí. Con él activado, los pares intercambian tramas directamente a través del puente y tus puntos de filtrado son el puente y el cortafuegos del host.

Anota en qué protecciones confía realmente cada host: autenticación del túnel, aislamiento del segmento o TLS de la aplicación. Un host que depende de las tres está bien. Un host que depende de la primera y asume que las otras dos vinieron con ella es el que acaba sirviendo el contenido equivocado.