Web NGINX len pre VPN: listener, firewall a zoznam povolení HTTP

Súkromný web NGINX potrebuje viazaný VPN socket, obmedzené pravidlo vstupu na hostiteľovi a neporušený zoznam prístupu HTTP. Testujte všetky tri, nie jeden blok servera.

Medzi súkromným webom a internetom stoja tri nezávislé rozhodnutia: ktorý socket prijme spojenie, ktorá cesta ho môže doručiť a ktorým klientom HTTP odpovedá zvolený server. Blok servera robí len prvé rozhodnutie. S ostatnými dvoma zaobchádzajte ako so samostatnými kontrolami, inak bude web vyzerať súkromne, zatiaľ čo starý vstup zostane otvorený. Väčšina porúch NGINX určeného len pre VPN pochádza z testovania iba prvej vrstvy.

Príklad používa linuxovú bránu OpenVPN na 10.90.0.1 na tun0, klientov v 10.90.0.0/24, zachované zdroje a TCP 8443 vyhradený pre tento vstup. Upravte hodnoty, vrstvy zachovajte.

Začnite socketom, nie názvom hostiteľa

Priraďte HTTPS listener k adrese tunela a vyhradenému portu. Konkrétna adresa sa ľahšie premýšľa než divoký socket plus kontrola názvu, pretože jadro port inej miestnej adrese neodovzdá.

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í obsahovať názov hostiteľa služby, ktorý klienti zadávajú, a súkromné zobrazenie DNS musí tohto hostiteľa preložiť na priradenú adresu. server_name iba vyberá virtuálneho hostiteľa; nikoho neoveruje. Chýbajúci DNS záznam vytvára chybu certifikátu, ktorá vyzerá ako porucha TLS. Skontrolujte názov pred výmenou certifikátu.

Prečítajte si účinnú konfiguráciu pred pridaním súboru. Vloženia a divokí listeneri môžu obsluhovať rovnaký koreň inde a predvolený server môže odpovedať na požiadavky, ktoré nový blok nikdy nevidí.

Zatvorte každý iný listener pre tento obsah

Vypíšte direktívy listen a porovnajte korene, ktoré obsluhujú. Blok pridaný pre inú aplikáciu môže proxovať na rovnaký upstream a starý predvolený server môže ďalej odpovedať po nasadení nového. Tento výstup je skutočný inventár, nie súbor, ktorý ste práve upravili. Porovnajte každý koreň, ktorý obsluhuje rovnaký obsah.

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

Skontrolujte obe rodiny adries. Väzba IPv4 necháva socket IPv6 nedotknutý a nový záznam A neruší starú odpoveď AAAA, ktorá stále ukazuje na verejnú cestu.

Vyraďte starého virtuálneho hostiteľa ako samostatnú zmenu. Odstránenie verejného dvojčaťa nového bloku je zvyčajne krok, ktorý vstup skutočne zavrie; súkromný listener iba pridá zamýšľaný.

Ohraničte prichádzajúcu cestu na hostiteľovi

Adresa počúvania obmedzuje socket, nie vstupné rozhranie. Paket smerovaný na túto adresu odinakiaľ stále prichádza ako miestny vstup, preto firewall hostiteľa potrebuje vlastné vyhlásenie o tom, odkiaľ spojenie môže prichádzať. Preto samotná väzba audit málokedy uspokojí.

Pri predvolenej politike odmietania prichádzajúcej prevádzky a bez širšieho povolenia pre túto službu ohraničené pravidlo pomenuje tunel, rozsah zdroja, cieľ aj port spoločne:

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

Prečítajte si účinné poradie firewallu pred jeho použitím. Skoršie široké prijatie môže obmedzenie zmaríť a skoršie koncové zahodenie môže zabrániť tomu, aby sa toto povolenie vôbec dosiahlo. Nevyprázdňujte nesúvisiace pravidlá a nevypínajte firewall, aby príklad sedel.

Toto pravidlo je vstup na hostiteľa, nie trasa k inému stroju v LAN, a vonkajší OpenVPN listener brány zostáva samostatnou službou. Ak bol web predtým verejný, naplánujte, ako sa starý vstup vyradí a ako sa naloží s existujúcimi reláciami.

Udržte zoznam HTTP neporušený, keď sa umiestnenia menia

NGINX vyhodnocuje položky allow a deny v poradí a zoznam na úrovni servera vyššie pripúšťa deklarovanú skupinu pred konečným deny. Modul prístupu tiež zaznamenáva, že umiestnenie definujúce akúkoľvek položku prístupu používa vlastný zoznam namiesto rodičovského. Poradie je rovnako dôležité ako samotné položky.

Toto resetovanie je obvyklá regresia. Nové umiestnenie nahrávania, API alebo stavu, ktoré pridá jednu položku, ticho nahradí obmedzenie na úrovni servera a web sa rozšíri na najnovšie pridanej ceste.

Prejdite každé umiestnenie, alias a alternatívny blok ako súčasť tej istej politiky. Ak sa IP kontroly kombinujú s overovaním NGINX, pochopte satisfy: nastavenie any môže pustiť klienta jedným mechanizmom, zatiaľ čo druhý neprešiel. Zaradte zoznam prístupu do kontrolného zoznamu umiestnení.

Odmietnutie HTTP nastáva po tom, čo TCP spojenie dorazí do NGINX. Doplňuje sieťové obmedzenie a vlastná autorizácia aplikácie stále platí pre každého používateľa.

Overte živú cestu aj prípad zlyhania

Spustite analyzátor konfigurácie, prezrite počúvajúce sockety a potom z cieľového klienta odošlite novú pomenovanú požiadavku. Potvrďte, že certifikát sa validuje, DNS názov sa preloží na priradenú adresu a odpoveď prichádza z očakávaného koreňa.

Ďalej otestujte vylúčený zdroj a alternatívny vstup. Fungujúca povolená požiadavka nič nehovorí o cestách, ktoré ste chceli zavrieť, a práve pri vylúčenom teste sa objaví zvyšný listener alebo široké prijatie firewallu.

Zopakujte prípad spustenia alebo obnovy VPN. Ak NGINX štartuje skôr, než adresa tunela existuje, väzba môže zlyhať aj s bezchybným súborom. Koordinujte pripravenosť adresy a pred zmenou zdieľaného webového servera si ponechajte miestnu cestu obnovy.

Zaznamenajte socket, port, rozsah zdroja a zoznam HTTP, ktoré prešli. Ďalšia zmena VPN alebo DNS môže posunúť ktorýkoľvek z nich a štyri pomenované hodnoty sa porovnávajú ľahšie než funkčná karta prehliadača.

Súvisiace články