Ejecutar una VPN y un sitio web en un solo host sin colisiones

Compartir un host entre un sitio público y una VPN hace que herede dos preguntas, no una: qué escucha dónde y quién autentica a quién. Responda ambas antes de tocar un archivo de configuración, porque los valores por defecto son erróneos de formas que solo aparecen bajo carga. Una página que carga por HTTPS demuestra que el escucha web responde y nada sobre el escucha de pares. Lo que sigue es un orden de decisiones que evita que los dos se coman entre sí.

Decida qué escucha en qué dirección y transporte

Escriba una tabla de tres columnas, dirección, transporte y puerto, y una fila por servicio, incluida la interfaz administrativa. TCP 443 para el sitio y UDP 443 para la VPN no son un conflicto aunque los números coincidan, porque el transporte es distinto. Dos servicios en la misma dirección, transporte y puerto necesitan un arreglo que la implementación documente, no uno que usted invente durante una caída. Esa tabla es también el artefacto que hace revisable el siguiente cambio.

Direcciones separadas o un segundo puerto hacen visible la propiedad en una captura de paquetes, y eso vale más que la elegancia. Algunas implementaciones de VPN permiten compartir un puerto con un servidor web, pero el mecanismo es específico: el demonio inspecciona los primeros bytes y reenvía el tráfico que no es su propio protocolo. Un proxy inverso HTTP genérico no hace eso, y reescribir las cabeceras no lo hará entender un apretón de manos de un túnel cifrado. Lea las notas de despliegue del protocolo, como la documentación del escucha de OpenVPN, y siga el arreglo que describe.

Decida qué identidad pertenece a qué servicio

Un certificado de navegador y una credencial de par de VPN son objetos distintos con modelos de confianza distintos. El certificado web lo valida una autoridad pública y nombra un nombre de host, mientras que la credencial de par autentica un dispositivo o un usuario ante el concentrador y puede ser autofirmada o emitida internamente. Reutilizar uno como el otro funciona en casos estrechos y rara vez merece el acoplamiento. Desactivar la verificación para que encaje un certificado compartido no es un plan de separación; elimina la comprobación que daba sentido a la credencial.

Mantenga los dos almacenes independientes y anote qué autoridad emite cada uno. Cuando se rota uno, el otro no debería necesitar cambios, y si los necesita, el acoplamiento es lo que hay que arreglar.

Decida dónde vive la administración

La interfaz administrativa de la VPN pertenece a una ruta de gestión, nunca al escucha público, incluso cuando el host ya sirve internet. Un servidor web en 443 no implica que la consola de pares deba ser accesible desde cualquier lugar, y la consola suele ser el objetivo de mayor valor. Líela a una dirección de bucle local o de gestión, restrínjala por origen y mantenga una ruta de recuperación que no dependa de que el túnel esté levantado. La ruta de recuperación importa porque el fallo habitual es quedarse fuera mientras se arregla el bloqueo.

Escriba reglas de cortafuegos estrechas, una por escucha, nombrando la interfaz o la cuenta de servicio donde la plataforma lo permita. Las reglas amplias que abren el host porque el sitio necesita 443 son la forma en que las interfaces administrativas acaban en los índices de los escáneres.

Revise esas reglas contra la tabla de escuchas siempre que se añada un servicio. La revisión es barata y atrapa la regla que alguien añadió a las dos de la madrugada.

Decida qué hacer cuando los dos compiten

Compartir un host significa compartir CPU, memoria, descriptores de archivo y ancho de banda, y el recurso disputado no siempre es el obvio. Un sitio ocupado puede llenar la tabla de conexiones, agotar las ranuras de trabajo o empujar la cola de disco lo bastante fuerte como para que el registro de la VPN se atasque. Mire el uso por servicio en lugar de los totales del host, porque una media oculta qué proceso pasa hambre. Si una carga de trabajo perturba repetidamente a la otra, aíslelas en vez de ajustar alrededor del síntoma.

El aislamiento puede ser un contenedor, un límite de cgroup, una cola separada o un segundo host, y la elección correcta depende de qué recurso compite. Un cambio de puerto no arregla nada aquí, y una instancia más grande no arregla nada si el límite es una cola saturada. Decida con una medición: nombre el recurso, cárguelo y luego elija el aislamiento más pequeño que elimine la competición.

Verifique desde fuera y luego otra vez tras un reinicio

Pruebe desde un dispositivo que no esté en la red del propio host: cargue el sitio, levante el túnel y alcance un recurso que lo requiera. Después reinicie cada servicio por separado y repita la otra prueba, porque un reinicio es cuando un arreglo de escucha compartido pierde su orden. Si la VPN arranca antes que el servidor web que posee el puerto compartido, el mecanismo de compartición puede no engancharse nunca, y el síntoma es un túnel que ayer funcionaba. Haga explícita la dependencia en el orden de las unidades.

Luego confirme los límites: el sitio responde en su puerto, la VPN responde en el suyo, y la interfaz administrativa responde solo desde la ruta de gestión. Anote el resultado junto a la tabla de escuchas con la fecha. Un host que pasa las tres comprobaciones después de un reinicio es un host que puede entregar a otra persona sin una sesión informativa.