Csak VPN-hez használt NGINX-webhely: listener, tűzfal és HTTP-engedélylista

Egy privát NGINX-webhelyhez kötött VPN-socket, korlátozott gazdagép-bejövő szabály és ép HTTP-hozzáférési lista kell. Mind a hármat tesztelje, ne csak egy kiszolgálóblokkot.

Három független döntés áll a privát webhely és az internet között: melyik socket fogadja a kapcsolatot, melyik útvonal szállíthatja, és mely HTTP-klienseknek válaszol a kiválasztott kiszolgáló. A kiszolgálóblokk csak az első döntést hozza meg. Kezelje a másik kettőt külön vezérlőként, különben a webhely privátnak látszik, miközben egy régi bejárat nyitva marad. A csak VPN-hez szánt NGINX-hibák többsége abból ered, hogy csak az első réteget tesztelik.

A példa egy Linux OpenVPN átjárót használ 10.90.0.1 címen a tun0 interfészen, klienseket a 10.90.0.0/24 hálózatban, megőrzött forrásokat és az ehhez a bejárathoz fenntartott TCP 8443-at. Igazítsa az értékeket, tartsa meg a rétegeket.

A socketből induljon ki, ne a gazdagépnévből

Kösse a HTTPS listenert az alagút címéhez és egy dedikált porthoz. Egy konkrét cím könnyebben átgondolható, mint egy helyettesítő socket és egy névellenőrzés, mert a kernel nem adja át a portot egy másik helyi címnek.

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

A tanúsítványnak tartalmaznia kell a szolgáltatás gazdagépnevét, amelyet az ügyfelek beírkálnak, és a privát DNS-nézetnek erre a kötött címre kell feloldania azt. A server_name csak egy virtuális gazdagépet választ; senkit nem hitelesít. A hiányzó DNS-bejegyzés TLS-hibának látszó tanúsítványhibát okoz. A tanúsítvány cseréje előtt ellenőrizze a nevet.

A fájl hozzáadása előtt olvassa el a tényleges konfigurációt. A beillesztések és a helyettesítő listenerek máshol is kiszolgálhatják ugyanazt a gyökeret, és egy alapértelmezett kiszolgáló olyan kérésekre is válaszolhat, amelyeket az új blokk sosem lát.

Zárjon be minden más listenert ehhez a tartalomhoz

Listázza a listen utasításokat, és hasonlítsa össze az általuk kiszolgált gyökereket. Egy másik alkalmazáshoz hozzáadott blokk ugyanahhoz az upstreamhez továbbíthat, és egy régi alapértelmezett kiszolgáló az új telepítése után is válaszolhat. Az a kimenet a valódi leltár, nem a most szerkesztett fájl. Hasonlítson össze minden gyökeret, amely ugyanazt a tartalmat szolgálja ki.

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

Ellenőrizze mindkét címcsaládot. Az IPv4-kötés érintetlenül hagyja az IPv6-socketet, és egy új A-rekord nem vonja vissza a régi AAAA-választ, amely még nyilvános útvonalra mutat.

Vonja ki a régi virtuális gazdagépet külön változásként. Az új blokk nyilvános ikertestvérének eltávolítása általában az a lépés, amely valóban bezárja a bejáratot; a privát listener csak a szándékoltat adja hozzá.

Határolja be a bejövő útvonalat a gazdagépnél

A hallgató cím a socketet korlátozza, nem a bejövő interfészt. A máshonnan erre a címre irányított csomag továbbra is helyi bemenetként érkezik, ezért a gazdagép tűzfalának saját nyilatkozatra van szüksége arról, honnan jöhet a kapcsolat. Ezért ritkán elégít ki egy vizsgálatot pusztán a kötés.

Alapértelmezett elutasító bejövő szabály mellett és szélesebb engedély nélkül erre a szolgáltatásra egy behatárolt szabály együtt nevezi meg az alagutat, a forrástartományt, a célt és a portot:

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

A tűzfal tényleges sorrendjét az alkalmazás előtt olvassa el. Egy korábbi széles elfogadás hatástalaníthatja a korlátozást, és egy korábbi végleges eldobás megakadályozhatja, hogy ez az engedély egyáltalán elérhető legyen. Ne törölje a nem kapcsolódó szabályokat, és ne kapcsolja ki a tűzfalat, hogy a példa illeszkedjen.

Ez a szabály gazdagép-bemenet, nem útvonal egy másik LAN-géphez, és az átjáró külső OpenVPN listenere továbbra is külön szolgáltatás. Ha a webhely korábban nyilvános volt, tervezze meg, hogyan vonják ki a régi bejáratot, és hogyan kezelik a meglévő munkameneteket.

Tartsa épnek a HTTP-listát, miközben a helyek változnak

Az NGINX sorrendben értékeli az allow és deny bejegyzéseket, és a fenti kiszolgálószintű lista a végső deny előtt beengedi a deklarált csoportot. A hozzáférési modul azt is rögzíti, hogy a bármilyen hozzáférési bejegyzést meghatározó hely a saját listáját használja a szülőlista helyett. A sorrend ugyanolyan fontos, mint maguk a bejegyzések.

Ez az alaphelyzetbe állítás a szokásos regresszió. Egy új feltöltési, API- vagy állapothely, amely egy bejegyzést ad hozzá, csendesen lecseréli a kiszolgálószintű korlátozást, és a webhely a legutóbb hozzáadott útvonalon szélesedik.

Tekintse át az összes helyet, aliast és alternatív blokkot ugyanazon szabály részeként. Ha az IP-ellenőrzéseket NGINX-hitelesítéssel kombinálják, értse meg a satisfy beállítást: az any beállítás beengedhet egy klienst az egyik mechanizmuson, miközben a másik nem ment át. Tegye a hozzáférési listát a helyek ellenőrzőlistájára.

A HTTP-elutasítás azután történik, hogy a TCP-kapcsolat eléri az NGINX-et. Kiegészíti a hálózati korlátozást, és az alkalmazás saját engedélyezése továbbra is minden felhasználóra érvényes.

Ellenőrizze az élő útvonalat és a hibaesetet

Futtassa a konfigurációelemzőt, vizsgálja meg a hallgató socketeket, majd küldjön friss nevű kérést egy szándékolt kliensről. Erősítse meg, hogy a tanúsítvány érvényes, a DNS-név a kötött címre oldódik fel, és a válasz a várt gyökérből jön.

Ezután teszteljen egy kizárt forrást és egy alternatív bejáratot. Egy működő engedélyezett kérés semmit sem mond azokról az útvonalakról, amelyeket be akart zárni, és a kizárt teszt mutatja meg a maradék listenert vagy a széles tűzfal-elfogadást.

Ismételje meg az indítási vagy VPN-helyreállítási esetet. Ha az NGINX az alagút címének létezése előtt indul, a kötés tökéletes fájllal is meghiúsulhat. Hangolja össze a cím készenlétét, és a megosztott webszerver módosítása előtt tartson fenn helyi helyreállítási útvonalat.

Jegyezze fel a socketet, portot, forrástartományt és HTTP-listát, amelyek átmentek. A következő VPN- vagy DNS-változás bármelyiket elmozdíthatja, és négy megnevezett értéket könnyebb összehasonlítani, mint egy működő böngészőlapot.

Kapcsolódó cikkek