Lloc NGINX només per a VPN: listener, tallafocs i llista d'accés HTTP

Tres decisions independents separen un lloc privat d'Internet: quin sòcol accepta la connexió, quin camí la pot lliurar i a quins clients HTTP respon el servidor seleccionat. El bloc de servidor només pren la primera decisió. Tracteu les altres dues com a controls separats, o el lloc semblarà privat mentre una entrada antiga continua oberta. La majoria de fallades de NGINX només per a VPN provenen de provar només la primera capa.

L'exemple pràctic utilitza una passarel·la Linux OpenVPN a 10.90.0.1 a tun0, clients a 10.90.0.0/24, fonts preservades i TCP 8443 reservat per a aquesta entrada. Ajusteu els valors, manteniu les capes.

Comenceu pel sòcol, no pel nom d'amfitrió

Lligueu l'oient HTTPS a l'adreça del túnel i a un port dedicat. Una adreça específica és més fàcil de raonar que un sòcol comodí més una comprovació de nom, perquè el nucli no lliurarà el port a una altra adreça 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 certificat ha de nomenar l'amfitrió del servei que els clients escriuen, i la vista DNS privada ha de resoldre aquest amfitrió a l'adreça lligada. server_name només tria un amfitrió virtual; no autentica ningú. Una entrada DNS absent produeix un error de certificat que sembla una fallada de TLS. Comproveu el nom abans de substituir el certificat.

Llegiu la configuració efectiva abans d'afegir el fitxer. Les inclusions i els oients comodí poden servir la mateixa arrel en un altre lloc, i un servidor per defecte pot respondre peticions que el bloc nou no veu mai.

Tanqueu tots els altres oients per a aquest contingut

Enumereu les directives listen i compareu les arrels que serveixen. Un bloc afegit per a una altra aplicació pot fer de proxy cap al mateix upstream, i un servidor per defecte antic pot continuar responent després que el nou estigui al seu lloc. Aquesta sortida és l'inventari real, no el fitxer que acabeu d'editar. Compareu cada arrel que serveix el mateix contingut.

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

Comproveu les dues famílies d'adreces. Una vinculació IPv4 deixa intacte un sòcol IPv6, i un registre A nou no retira una resposta AAAA antiga que encara apunta a un camí públic.

Retireu l'amfitrió virtual antic com a canvi separat. Eliminar el bessó públic del bloc nou sol ser el pas que tanca realment l'entrada; l'oient privat només afegeix la prevista.

Limiteu el camí d'entrada a l'amfitrió

L'adreça d'escolta limita el sòcol, no la interfície d'entrada. Un paquet encaminat a aquesta adreça des d'un altre lloc encara arriba com a entrada local, per això el tallafocs de l'amfitrió necessita la seva pròpia declaració sobre d'on pot venir la connexió. Per això una vinculació sola poques vegades satisfà una auditoria.

Amb una política d'entrada de denegació per defecte i sense cap permís més ampli per a aquest servei, una regla abastada nomena el túnel, el rang d'origen, la destinació i el port alhora:

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

Llegiu l'ordre efectiu del tallafocs abans d'aplicar-lo. Una acceptació àmplia anterior pot derrotar la restricció, i un descart terminal anterior pot impedir que aquest permís s'assoleixi mai. No buideu regles no relacionades ni apagueu el tallafocs per fer encaixar l'exemple.

Aquesta regla és entrada d'amfitrió, no una ruta a una altra màquina de la LAN, i l'oient OpenVPN exterior de la passarel·la continua sent un servei separat. Si el lloc abans era públic, planifiqueu com es retira l'entrada antiga i com es tracten les sessions existents.

Manteniu la llista HTTP intacta mentre canvien les ubicacions

NGINX avalua les entrades allow i deny en ordre, i la llista a nivell de servidor de dalt admet el conjunt declarat abans del deny final. El mòdul d'accés també registra que una ubicació que defineix qualsevol entrada d'accés utilitza la seva pròpia llista en lloc de la llista pare. L'ordre importa tant com les mateixes entrades.

Aquest reinici és la regressió habitual. Una ubicació nova de càrrega, API o salut que afegeix una entrada substitueix silenciosament la restricció a nivell de servidor, i el lloc es fa més ampli al camí afegit més recentment.

Reviseu cada ubicació, àlies i bloc alternatiu com a part de la mateixa política. Si les comprovacions IP es combinen amb autenticació NGINX, enteneu satisfy: un paràmetre any pot admetre un client per un mecanisme mentre l'altre no ha passat. Poseu la llista d'accés a la llista de verificació d'ubicacions.

Una denegació HTTP passa després que la connexió TCP arribi a NGINX. Complementa la restricció de xarxa, i l'autorització pròpia de l'aplicació continua aplicant-se a cada usuari.

Verifiqueu el camí viu i el cas de fallada

Executeu l'analitzador de configuració, inspeccioneu els sòcols que escolten i feu una petició nomenada nova des d'un client previst. Confirmeu que el certificat valida, que el nom DNS resol a l'adreça lligada i que la resposta ve de l'arrel esperada.

Proveu després una font exclosa i una entrada alternativa. Una petició permesa que funciona no diu res sobre els camins que volíeu tancar, i és a la prova exclosa on apareix un oient sobrant o una acceptació àmplia del tallafocs.

Repetiu el cas d'arrencada o de recuperació de VPN. Si NGINX s'inicia abans que existeixi l'adreça del túnel, la vinculació pot fallar fins i tot amb un fitxer perfecte. Coordineu la preparació de l'adreça i mantingueu un camí de recuperació local abans de canviar un servidor web compartit.

Registreu el sòcol, el port, el rang d'origen i la llista HTTP que han passat. El proper canvi de VPN o DNS pot moure qualsevol d'ells, i quatre valors nomenats són més fàcils de comparar que una pestanya de navegador que funciona.