Web NGINX jen pro VPN: listener, firewall a seznam povolení HTTP

Soukromý web NGINX potřebuje vázaný VPN socket, omezené pravidlo vstupu na hostiteli a neporušený seznam přístupu HTTP. Testujte všechny tři, ne jeden blok serveru.

Mezi soukromým webem a internetem stojí tři nezávislá rozhodnutí: který socket přijme spojení, která cesta je může doručit a kterým klientům HTTP vybraný server odpovídá. Blok serveru rozhoduje jen o prvním. S ostatními dvěma zacházejte jako se samostatnými kontrolami, jinak bude web vypadat soukromě, zatímco starý vstup zůstane otevřený. Většina poruch NGINX určeného jen pro VPN pochází z testování pouze první vrstvy.

Příklad používá linuxovou bránu OpenVPN na 10.90.0.1 na tun0, klienty v 10.90.0.0/24, zachované zdroje a TCP 8443 vyhrazený pro tento vstup. Upravte hodnoty, vrstvy zachovejte.

Začněte socketem, ne názvem hostitele

Přivažte HTTPS listener k adrese tunelu a vyhrazenému portu. Konkrétní adresa se snáze uvažuje než divoký socket plus kontrola názvu, protože jádro port jiné místní adrese nepředá.

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

Certifikát musí obsahovat název hostitele služby, který klienti zadávají, a soukromé DNS zobrazení musí tento hostitel přeložit na přivázanou adresu. server_name pouze vybírá virtuálního hostitele; nikoho neověřuje. Chybějící DNS záznam vytváří chybu certifikátu, která vypadá jako porucha TLS. Zkontrolujte název, než certifikát vyměníte.

Přečtěte si účinnou konfiguraci, než soubor přidáte. Vložení a divocí listeneri mohou obsluhovat stejný kořen jinde a výchozí server může odpovídat na požadavky, které nový blok vůbec nevidí.

Zavřete každý jiný listener pro tento obsah

Vypište direktivy listen a porovnejte kořeny, které obsluhují. Blok přidaný pro jinou aplikaci může proxovat na stejný upstream a starý výchozí server může dál odpovídat i po nasazení nového. Tento výstup je skutečný inventář, ne soubor, který jste právě upravili. Porovnejte každý kořen, který obsluhuje stejný obsah.

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

Zkontrolujte obě rodiny adres. Vazba IPv4 nechává socket IPv6 nedotčený a nový záznam A neruší starou odpověď AAAA, která stále ukazuje na veřejnou cestu.

Vyřaďte starého virtuálního hostitele jako samostatnou změnu. Odstranění veřejného dvojčete nového bloku je obvykle krok, který vstup skutečně zavře; soukromý listener jen přidá zamýšlený.

Ohraničte příchozí cestu na hostiteli

Adresa pro naslouchání omezuje socket, ne vstupní rozhraní. Paket směrovaný na tuto adresu odjinud stále dorazí jako místní vstup, proto firewall hostitele potřebuje vlastní prohlášení o tom, odkud spojení může přijít. Proto samotná vazba audit málokdy uspokojí.

Při výchozí politice odmítání příchozího provozu a bez širšího povolení pro tuto službu ohraničené pravidlo pojmenuje tunel, rozsah zdroje, cíl i port společně:

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

Přečtěte si účinné pořadí firewallu, než je použijete. Dřívější široké přijetí může omezení zmařit a dřívější koncové zahození může zabránit tomu, aby se k tomuto povolení vůbec došlo. Nevyčerpávejte nesouvisející pravidla ani nevypínejte firewall, aby příklad seděl.

Toto pravidlo je vstup na hostitele, ne trasa k jinému stroji v LAN, a vnější OpenVPN listener brány zůstává samostatnou službou. Pokud byl web dříve veřejný, naplánujte, jak se starý vstup vyřadí a jak se naloží s existujícími relacemi.

Udržte seznam HTTP neporušený, i když se umístění mění

NGINX vyhodnocuje položky allow a deny v pořadí a seznam na úrovni serveru výše připouští deklarovaný fond před konečným deny. Modul přístupu také zaznamenává, že umístění definující jakoukoli položku přístupu používá vlastní seznam místo rodičovského. Pořadí je stejně důležité jako položky samotné.

Toto resetování je obvyklá regrese. Nové umístění pro nahrávání, API nebo zdraví, které přidá jednu položku, tiše nahradí omezení na úrovni serveru a web se rozšíří na naposledy přidané cestě.

Projděte každé umístění, alias a alternativní blok jako součást stejné politiky. Pokud se IP kontroly kombinují s ověřováním NGINX, pochopte satisfy: nastavení any může pustit klienta jedním mechanismem, zatímco druhý neprošel. Zařaďte seznam přístupu do kontrolního seznamu umístění.

Odmítnutí HTTP nastává poté, co TCP spojení dorazí do NGINX. Doplňuje síťové omezení a vlastní autorizace aplikace stále platí pro každého uživatele.

Ověřte živou cestu i případ selhání

Spusťte analyzátor konfigurace, prohlédněte naslouchající sockety a pak z cílového klienta odešlete nový pojmenovaný požadavek. Potvrďte, že certifikát projde validací, DNS název se přeloží na přivázanou adresu a odpověď přichází z očekávaného kořene.

Dále otestujte vyloučený zdroj a alternativní vstup. Fungující povolený požadavek nic neříká o cestách, které jste chtěli zavřít, a právě při vyloučeném testu se objeví zbylý listener nebo široké přijetí firewallu.

Zopakujte případ spuštění nebo obnovy VPN. Pokud NGINX startuje dřív, než adresa tunelu existuje, může vazba selhat i s bezvadným souborem. Koordinujte připravenost adresy a před změnou sdíleného webového serveru si ponechte místní cestu obnovy.

Zaznamenejte socket, port, rozsah zdroje a seznam HTTP, které prošly. Příští změna VPN nebo DNS může posunout kterýkoli z nich a čtyři pojmenované hodnoty se porovnávají snadněji než funkční karta prohlížeče.

Související články