Sitio NGINX solo para VPN: listener, cortafuegos y lista de permisos HTTP

Un sitio NGINX privado necesita un socket VPN vinculado, una regla de entrada de host acotada y una lista de acceso HTTP intacta. Pruebe las tres cosas, no un solo bloque de servidor.

Tres decisiones independientes separan un sitio privado de internet: qué socket acepta la conexión, qué ruta puede entregarla y a qué clientes HTTP responde el servidor elegido. Un bloque de servidor solo toma la primera decisión. Trate las otras dos como controles separados, o el sitio parecerá privado mientras una entrada antigua sigue abierta. La mayoría de los fallos de NGINX solo para VPN proviene de probar únicamente la primera capa.

El ejemplo práctico usa una puerta de enlace Linux OpenVPN en 10.90.0.1 sobre tun0, clientes en 10.90.0.0/24, orígenes preservados y TCP 8443 reservado para esta entrada. Ajuste los valores, mantenga las capas.

Empiece por el socket, no por el nombre de host

Vincule el listener HTTPS a la dirección del túnel y a un puerto dedicado. Una dirección específica es más fácil de razonar que un socket comodín más una comprobación de nombre, porque el núcleo no entregará el puerto a otra dirección local.

server {
    listen 10.90.0.1:8443 ssl;
    server_name admin.corp.example;

    ssl_certificate     /etc/nginx/tls/admin-fullchain.pem;
    ssl_certificate_key /etc/nginx/tls/admin-key.pem;

    root /srv/private-site;

    allow 10.90.0.0/24;
    deny all;

    location / {
        try_files $uri $uri/ =404;
    }
}

El certificado debe nombrar el host del servicio que escriben los clientes, y la vista DNS privada debe resolver ese host a la dirección vinculada. server_name solo elige un host virtual; no autentica a nadie. Una entrada DNS ausente produce un error de certificado que parece una falla de TLS. Compruebe el nombre antes de sustituir el certificado.

Lea la configuración efectiva antes de añadir el archivo. Las inclusiones y los listeners comodín pueden servir la misma raíz en otro lugar, y un servidor predeterminado puede responder a solicitudes que el bloque nuevo nunca ve.

Cierre todos los demás listeners para ese contenido

Enumere las directivas listen y compare las raíces que sirven. Un bloque añadido para otra aplicación puede hacer proxy al mismo upstream, y un servidor predeterminado antiguo puede seguir respondiendo después de que el nuevo esté en su lugar. Esa salida es el inventario real, no el archivo que acaba de editar. Compare cada raíz que sirve el mismo contenido.

sudo nginx -T | grep -n "listen\|server_name\|root\|proxy_pass"

Compruebe ambas familias de direcciones. Una vinculación IPv4 deja intacto un socket IPv6, y un registro A nuevo no retira una respuesta AAAA antigua que aún apunta a una ruta pública.

Retire el host virtual antiguo como un cambio aparte. Eliminar el gemelo público del bloque nuevo suele ser el paso que realmente cierra la entrada; el listener privado solo añade la prevista.

Limite el alcance de la ruta entrante en el host

La dirección de escucha limita el socket, no la interfaz de entrada. Un paquete enrutado a esa dirección desde otro lugar sigue llegando como entrada local, por eso el cortafuegos del host necesita su propia declaración sobre de dónde puede venir la conexión. Por eso una vinculación sola rara vez satisface una auditoría.

Con una política de entrada de denegación por defecto y sin un permiso más amplio para este servicio, una regla acotada nombra el túnel, el rango de origen, el destino y el puerto a la vez:

sudo ufw allow in on tun0 proto tcp from 10.90.0.0/24 to 10.90.0.1 port 8443

Lea el orden efectivo del cortafuegos antes de aplicarlo. Una aceptación amplia anterior puede anular la restricción, y un descarte terminal anterior puede impedir que esta concesión llegue a alcanzarse. No vacíe reglas no relacionadas ni apague el cortafuegos para que encaje el ejemplo.

Esa regla es entrada del host, no una ruta a otra máquina de la LAN, y el listener OpenVPN exterior de la puerta de enlace sigue siendo un servicio aparte. Si el sitio era público antes, planifique cómo se retira la entrada antigua y cómo se manejan las sesiones existentes.

Mantenga intacta la lista HTTP mientras cambian las ubicaciones

NGINX evalúa las entradas allow y deny en orden, y la lista de nivel de servidor anterior admite el conjunto declarado antes del deny final. El módulo de acceso también registra que una ubicación que define cualquier entrada de acceso usa su propia lista en lugar de la lista padre. El orden importa tanto como las entradas mismas.

Ese reinicio es la regresión habitual. Una ubicación nueva de carga, API o salud que añade una entrada sustituye en silencio la restricción de nivel de servidor, y el sitio se vuelve más amplio en la ruta añadida más recientemente.

Revise cada ubicación, alias y bloque alternativo como parte de la misma política. Si las comprobaciones de IP se combinan con la autenticación de NGINX, entienda satisfy: un ajuste any puede admitir a un cliente por un mecanismo mientras el otro no ha pasado. Incluya la lista de acceso en la lista de verificación de ubicaciones.

Una denegación HTTP ocurre después de que la conexión TCP llega a NGINX. Complementa la restricción de red, y la autorización propia de la aplicación sigue aplicándose a cada usuario.

Verifique la ruta activa y el caso de fallo

Ejecute el analizador de configuración, inspeccione los sockets en escucha y haga después una petición con nombre nueva desde un cliente previsto. Confirme que el certificado valida, que el nombre DNS resuelve a la dirección vinculada y que la respuesta procede de la raíz esperada.

Pruebe a continuación un origen excluido y una entrada alternativa. Una petición permitida que funciona no dice nada sobre las rutas que quería cerrar, y es en la prueba excluida donde aparece un listener sobrante o una aceptación amplia del cortafuegos.

Repita el caso de arranque o de recuperación de VPN. Si NGINX arranca antes de que exista la dirección del túnel, la vinculación puede fallar incluso con un archivo perfecto. Coordine la preparación de la dirección y mantenga una ruta de recuperación local antes de cambiar un servidor web compartido.

Registre el socket, el puerto, el rango de origen y la lista HTTP que pasaron. El siguiente cambio de VPN o DNS puede mover cualquiera de ellos, y cuatro valores nombrados son más fáciles de comparar que una pestaña de navegador que funciona.

Artículos relacionados