Sitio NGINX só para VPN: listener, cortalumes e lista de permisos HTTP

Tres decisións independentes separan un sitio privado de internet: que socket acepta a conexión, que ruta pode entregala e a que clientes HTTP responde o servidor elixido. Un bloque de servidor só toma a primeira decisión. Trate as outras dúas como controis separados, ou o sitio parecerá privado mentres unha entrada antiga segue aberta. A maioría dos fallos de NGINX só para VPN proveñen de probar unicamente a primeira capa.

O exemplo práctico usa unha pasarela Linux OpenVPN en 10.90.0.1 sobre tun0, clientes en 10.90.0.0/24, orixes preservadas e TCP 8443 reservado para esta entrada. Axuste os valores, manteña as capas.

Comece polo socket, non polo nome de host

Vincule o listener HTTPS á dirección do túnel e a un porto dedicado. Unha dirección específica é máis doada de razoar que un socket comodín máis unha comprobación de nome, porque o núcleo non entregará o porto a outra 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;
    }
}

O certificado debe nomear o host do servizo que escriben os clientes, e a vista DNS privada debe resolver ese host á dirección vinculada. server_name só escolle un host virtual; non autentica a ninguén. Unha entrada DNS ausente produce un erro de certificado que parece unha falla de TLS. Comprobe o nome antes de substituír o certificado.

Lea a configuración efectiva antes de engadir o ficheiro. As inclusións e os listeners comodín poden servir a mesma raíz noutro lugar, e un servidor predeterminado pode responder a solicitudes que o bloque novo nunca ve.

Pecha todos os demais listeners para ese contido

Enumere as directivas listen e compare as raíces que serven. Un bloque engadido para outra aplicación pode facer proxy ao mesmo upstream, e un servidor predeterminado antigo pode seguir respondendo despois de que o novo estea no seu sitio. Esa saída é o inventario real, non o ficheiro que acaba de editar. Compare cada raíz que serve o mesmo contido.

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

Comprobe ambas as familias de direccións. Unha vinculación IPv4 deixa intacto un socket IPv6, e un rexistro A novo non retira unha resposta AAAA antiga que aínda apunta a unha ruta pública.

Retire o host virtual antigo como un cambio aparte. Eliminar o xemelgo público do bloque novo adoita ser o paso que realmente pecha a entrada; o listener privado só engade a prevista.

Limite o alcance da ruta entrante no host

A dirección de escoita limita o socket, non a interface de entrada. Un paquete encamiñado a esa dirección desde outro lugar segue chegando como entrada local, por iso o cortalumes do host necesita a súa propia declaración sobre de onde pode vir a conexión. Por iso unha vinculación soa raramente satisfai unha auditoría.

Cunha política de entrada de denegación por defecto e sen un permiso máis amplo para este servizo, unha regra acoutada nomea o túnel, o rango de orixe, o destino e o porto á vez:

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

Lea a orde efectiva do cortalumes antes de aplicala. Unha aceptación ampla anterior pode anular a restrición, e un descarte terminal anterior pode impedir que este permiso chegue a alcanzarse. Non baleire regras non relacionadas nin apague o cortalumes para que encaixe o exemplo.

Esa regra é entrada do host, non unha ruta a outra máquina da LAN, e o listener OpenVPN exterior da pasarela segue sendo un servizo aparte. Se o sitio era público antes, planifique como se retira a entrada antiga e como se manexan as sesións existentes.

Manteña intacta a lista HTTP mentres cambian as localizacións

NGINX avalía as entradas allow e deny en orde, e a lista de nivel de servidor anterior admite o conxunto declarado antes do deny final. O módulo de acceso tamén rexistra que unha localización que define calquera entrada de acceso usa a súa propia lista en lugar da lista nai. A orde importa tanto como as entradas mesmas.

Ese reinicio é a regresión habitual. Unha localización nova de carga, API ou saúde que engade unha entrada substitúe silenciosamente a restrición de nivel de servidor, e o sitio vólvese máis amplo na ruta engadida máis recentemente.

Revise cada localización, alias e bloque alternativo como parte da mesma política. Se as comprobacións de IP se combinan coa autenticación de NGINX, entenda satisfy: un axuste any pode admitir un cliente por un mecanismo mentres o outro non pasou. Inclúa a lista de acceso na lista de verificación de localizacións.

Unha denegación HTTP ocorre despois de que a conexión TCP chega a NGINX. Complementa a restrición de rede, e a autorización propia da aplicación segue aplicándose a cada usuario.

Verifique a ruta activa e o caso de fallo

Execute o analizador de configuración, inspeccione os sockets en escoita e faga despois unha petición con nome nova desde un cliente previsto. Confirme que o certificado valida, que o nome DNS resolve á dirección vinculada e que a resposta procede da raíz esperada.

Probe a continuación unha orixe excluída e unha entrada alternativa. Unha petición permitida que funciona non di nada sobre as rutas que quería pechar, e é na proba excluída onde aparece un listener sobrante ou unha aceptación ampla do cortalumes.

Repita o caso de arranque ou de recuperación de VPN. Se NGINX arrinca antes de que exista a dirección do túnel, a vinculación pode fallar incluso cun ficheiro perfecto. Coordine a preparación da dirección e manteña unha ruta de recuperación local antes de cambiar un servidor web compartido.

Rexiste o socket, o porto, o rango de orixe e a lista HTTP que pasaron. O seguinte cambio de VPN ou DNS pode mover calquera deles, e catro valores nomeados son máis doados de comparar que unha lapela de navegador que funciona.