Sito NGINX solo per VPN: listener, firewall ed elenco dei permessi HTTP

Un sito NGINX privato richiede un socket VPN associato, una regola di ingresso dell'host circoscritta e un elenco di accesso HTTP intatto. Verificate tutti e tre, non un solo blocco server.

Tre decisioni indipendenti separano un sito privato da Internet: quale socket accetta la connessione, quale percorso può consegnarla e a quali client HTTP risponde il server scelto. Un blocco server prende solo la prima decisione. Trattate le altre due come controlli separati, altrimenti il sito sembrerà privato mentre un vecchio ingresso resta aperto. La maggior parte dei guasti NGINX riservati alla VPN deriva dal testare solo il primo livello.

L'esempio usa un gateway Linux OpenVPN su 10.90.0.1 su tun0, client in 10.90.0.0/24, sorgenti preservate e TCP 8443 riservato a questo ingresso. Adattate i valori, mantenete i livelli.

Iniziate dal socket, non dal nome host

Collegate il listener HTTPS all'indirizzo del tunnel e a una porta dedicata. Un indirizzo specifico è più facile da ragionare di un socket generico più un controllo del nome, perché il kernel non cederà la porta a un altro indirizzo locale.

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;
    }
}

Il certificato deve riportare il nome host del servizio che i client digitano, e la vista DNS privata deve risolvere quell'host all'indirizzo associato. server_name sceglie solo un host virtuale; non autentica nessuno. Una voce DNS mancante produce un errore di certificato che sembra un guasto TLS. Controllate il nome prima di sostituire il certificato.

Leggete la configurazione effettiva prima di aggiungere il file. Le inclusioni e i listener generici possono servire la stessa radice altrove, e un server predefinito può rispondere a richieste che il nuovo blocco non vede mai.

Chiudete ogni altro listener per quel contenuto

Elencate le direttive listen e confrontate le radici che servono. Un blocco aggiunto per un'altra applicazione può inoltrare allo stesso upstream, e un vecchio server predefinito può continuare a rispondere dopo che il nuovo è in posizione. Quell'output è l'inventario reale, non il file appena modificato. Confrontate ogni radice che serve lo stesso contenuto.

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

Controllate entrambe le famiglie di indirizzi. Un binding IPv4 lascia intatto un socket IPv6, e un nuovo record A non ritira una vecchia risposta AAAA che punta ancora a un percorso pubblico.

Ritirate il vecchio host virtuale come modifica separata. Rimuovere il gemello pubblico del nuovo blocco è di solito il passo che chiude davvero l'ingresso; il listener privato aggiunge solo quello previsto.

Limitate il percorso in ingresso sull'host

L'indirizzo di ascolto limita il socket, non l'interfaccia di ingresso. Un pacchetto instradato a quell'indirizzo da altrove arriva comunque come input locale, perciò il firewall dell'host ha bisogno della propria dichiarazione su da dove può venire la connessione. Per questo un binding da solo raramente soddisfa un audit.

Con una politica di ingresso negata per impostazione predefinita e senza un permesso più ampio per questo servizio, una regola circoscritta nomina insieme il tunnel, l'intervallo di origine, la destinazione e la porta:

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

Leggete l'ordine effettivo del firewall prima di applicarlo. Un'accettazione ampia precedente può vanificare la restrizione, e un rifiuto terminale precedente può impedire di raggiungere questa autorizzazione. Non svuotate regole non correlate e non spegnete il firewall per far combaciare l'esempio.

Quella regola è input dell'host, non una rotta verso un'altra macchina della LAN, e il listener OpenVPN esterno del gateway resta un servizio separato. Se il sito era pubblico prima, pianificate come viene ritirato il vecchio ingresso e come vengono gestite le sessioni esistenti.

Mantenete intatto l'elenco HTTP mentre cambiano le posizioni

NGINX valuta le voci allow e deny in ordine, e l'elenco a livello server qui sopra ammette l'insieme dichiarato prima del deny finale. Il modulo di accesso registra anche che una posizione che definisce una voce di accesso usa il proprio elenco invece dell'elenco padre. L'ordine conta quanto le voci stesse.

Quel reset è la regressione abituale. Una nuova posizione di caricamento, API o salute che aggiunge una voce sostituisce silenziosamente la restrizione a livello server, e il sito si allarga sul percorso aggiunto più di recente.

Esaminate ogni posizione, alias e blocco alternativo come parte della stessa politica. Se i controlli IP sono combinati con l'autenticazione NGINX, capite satisfy: un'impostazione any può ammettere un client tramite un meccanismo mentre l'altro non è passato. Inserite l'elenco di accesso nella checklist delle posizioni.

Un rifiuto HTTP avviene dopo che la connessione TCP raggiunge NGINX. Integra la restrizione di rete, e l'autorizzazione propria dell'applicazione vale ancora per ogni utente.

Verificate il percorso attivo e il caso di guasto

Eseguite l'analizzatore di configurazione, ispezionate i socket in ascolto, poi fate una nuova richiesta con nome da un client previsto. Confermate che il certificato validi, che il nome DNS risolva all'indirizzo associato e che la risposta provenga dalla radice attesa.

Provate poi un'origine esclusa e un ingresso alternativo. Una richiesta consentita funzionante non dice nulla sui percorsi che volevate chiudere, ed è nel test escluso che emerge un listener residuo o un'accettazione ampia del firewall.

Ripetete il caso di avvio o di ripristino VPN. Se NGINX parte prima che esista l'indirizzo del tunnel, il binding può fallire anche con un file perfetto. Coordinate la disponibilità dell'indirizzo e mantenete un percorso di ripristino locale prima di modificare un server web condiviso.

Registrate il socket, la porta, l'intervallo di origine e l'elenco HTTP che hanno superato la prova. Il prossimo cambiamento VPN o DNS può spostare chiunque di essi, e quattro valori nominati sono più facili da confrontare di una scheda del browser funzionante.

Articoli correlati