Executar unha VPN e un sitio web nun só host sen colisións

Compartir un host entre un sitio público e unha VPN fai que herde dúas preguntas, non unha: que escoita onde e quen autentica a quen. Responda ambas antes de tocar un ficheiro de configuración, porque os valores por defecto son erróneos de formas que só aparecen baixo carga. Unha páxina que carga por HTTPS demostra que o escoita web responde e nada sobre o escoita de pares. O que segue é unha orde de decisións que evita que os dous se coman entre si.

Decida que escoita en que enderezo e transporte

Escriba unha táboa de tres columnas, enderezo, transporte e porto, e unha fila por servizo, incluída a interface administrativa. TCP 443 para o sitio e UDP 443 para a VPN non son un conflito aínda que os números coincidan, porque o transporte difire. Dous servizos no mesmo enderezo, transporte e porto necesitan un acordo que a implementación documente, non un que vostede invente durante unha caída. Ese táboa é tamén o artefacto que fai revisable o seguinte cambio.

Enderezos separados ou un segundo porto fan visible a propiedade nunha captura de paquetes, e iso vale máis que a elegancia. Algunhas implementacións de VPN permiten compartir un porto cun servidor web, pero o mecanismo é específico: o daemon inspecciona os primeiros bytes e reenvía o tráfico que non é o seu propio protocolo. Un proxy inverso HTTP xenérico non fai iso, e reescribir as cabeceiras non o fará entender un aperto de mans dun túnel cifrado. Lea as notas de despregamento do protocolo, como a documentación do escoita de OpenVPN, e siga o acordo que describe.

Decida que identidade pertence a que servizo

Un certificado de navegador e unha credencial de par de VPN son obxectos distintos con modelos de confianza distintos. O certificado web valídao unha autoridade pública e nomea un nome de host, mentres que a credencial de par autentica un dispositivo ou un usuario ante o concentrador e pode ser autoasinada ou emitida internamente. Reutilizar un como o outro funciona en casos estreitos e raramente merece o acoplamento. Desactivar a verificación para que encaixe un certificado compartido non é un plan de separación; elimina a comprobación que daba sentido á credencial.

Manteña os dous almacéns independentes e anote que autoridade emite cada un. Cando se rota un, o outro non debería necesitar cambios, e se os necesita, o acoplamento é o que hai que arranxar.

Decida onde vive a administración

A interface administrativa da VPN pertence a unha ruta de xestión, nunca ao escoita público, mesmo cando o host xa serve internet. Un servidor web no 443 non implica que a consola de pares deba ser accesible desde calquera lugar, e a consola adoita ser o obxectivo de maior valor. Líea a un enderezo de bucle local ou de xestión, restrínxaa por orixe e manteña unha ruta de recuperación que non dependa de que o túnel estea levantado. A ruta de recuperación importa porque o fallo habitual é quedarse fóra mentres se arranxa o bloqueo.

Escriba regras de devasas estreitas, unha por escoita, nomeando a interface ou a conta de servizo onde a plataforma o permita. As regras amplas que abren o host porque o sitio necesita o 443 son a forma en que as interfaces administrativas acaban nos índices dos escáneres.

Revise esas regras contra a táboa de escoitas sempre que se engada un servizo. A revisión é barata e atrapa a regra que alguén engadiu ás dúas da madrugada.

Decida que facer cando os dous compiten

Compartir un host significa compartir CPU, memoria, descritores de ficheiro e ancho de banda, e o recurso disputado non sempre é o obvio. Un sitio ocupado pode encher a táboa de conexións, esgotar as rañuras de traballo ou empurrar a cola de disco o suficiente como para que o rexistro da VPN se atore. Mire o uso por servizo en lugar dos totais do host, porque unha media agocha que proceso pasa fame. Se unha carga de traballo perturba repetidamente a outra, illádeas en vez de axustar arredor do síntoma.

O illamento pode ser un contedor, un límite de cgroup, unha cola separada ou un segundo host, e a elección correcta depende de que recurso compite. Un cambio de porto non arranxa nada aquí, e unha instancia máis grande non arranxa nada se o límite é unha cola saturada. Decida cunha medición: nomee o recurso, cárgueo e despois escolla o illamento máis pequeno que elimine a competición.

Verifique desde fóra e despois outra vez tras un reinicio

Probe desde un dispositivo que non estea na rede do propio host: cargue o sitio, levante o túnel e acade un recurso que o requira. Despois reinicie cada servizo pola súa conta e repita a outra proba, porque un reinicio é cando un acordo de escoita compartido perde a súa orde. Se a VPN arrinca antes que o servidor web que posúe o porto compartido, o mecanismo de compartición pode non engancharse nunca, e o síntoma é un túnel que onte funcionaba. Faga explícita a dependencia na orde das unidades.

Despois confirme os límites: o sitio responde no seu porto, a VPN responde no seu, e a interface administrativa responde só desde a ruta de xestión. Anote o resultado xunto á táboa de escoitas coa data. Un host que pasa as tres comprobacións tras un reinicio é un host que pode entregar a outra persoa sen unha sesión informativa.