NGINX svetainė tik VPN: klausytojas, ugniasienė ir HTTP leidimų sąrašas

Privačiai NGINX svetainei reikia susieto VPN lizdo, apribotos prieglobos įvesties taisyklės ir nepažeisto HTTP prieigos sąrašo. Tikrinkite visus tris, o ne vieną serverio bloką.

Trys nepriklausomi sprendimai skiria privačią svetainę nuo interneto: kuris lizdas priima ryšį, kuris kelias gali jį pristatyti ir kuriems HTTP klientams atsako pasirinktas serveris. Serverio blokas priima tik pirmąjį sprendimą. Kitus du traktuokite kaip atskirus valdiklius, kitaip svetainė atrodys privati, o senas įėjimas liks atviras. Dauguma tik VPN skirtų NGINX gedimų kyla tikrinant tik pirmąjį sluoksnį.

Pavyzdyje naudojamas Linux OpenVPN šliuzas adresu 10.90.0.1 sąsajoje tun0, klientai 10.90.0.0/24 tinkle, išsaugoti šaltiniai ir šiam įėjimui rezervuotas TCP 8443. Koreguokite reikšmes, išlaikykite sluoksnius.

Pradėkite nuo lizdo, o ne nuo prieglobos vardo

Susiekite HTTPS klausytoją su tunelio adresu ir atskiru prievadu. Konkretus adresas yra lengviau apgalvojamas nei pakaitinis lizdas ir vardo patikra, nes branduolys neperduos prievado kitam vietiniam adresui.

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

Sertifikate turi būti nurodytas paslaugos prieglobos vardas, kurį įveda klientai, o privati DNS peržiūra turi išspręsti tą prieglobą į susietą adresą. server_name tik pasirenka virtualią prieglobą; jis nieko neautentifikuoja. Trūkstamas DNS įrašas sukelia sertifikato klaidą, kuri atrodo kaip TLS gedimas. Patikrinkite vardą prieš keisdami sertifikatą.

Perskaitykite galiojančią konfigūraciją prieš pridėdami failą. Įtraukimai ir pakaitiniai klausytojai gali aptarnauti tą pačią šaknį kitur, o numatytasis serveris gali atsakyti į užklausas, kurių naujas blokas niekada nemato.

Uždarykite visus kitus to turinio klausytojus

Išvardykite listen direktyvas ir palyginkite jų aptarnaujamas šaknis. Blokas, pridėtas kitai programai, gali perduoti į tą patį upstream, o senas numatytasis serveris gali toliau atsakyti, kai naujasis jau įdiegtas. Ta išvestis yra tikrasis inventorius, o ne ką tik redaguotas failas. Palyginkite kiekvieną šaknį, kuri aptarnauja tą patį turinį.

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

Patikrinkite abi adresų šeimas. IPv4 susiejimas palieka IPv6 lizdą nepaliestą, o naujas A įrašas neatšaukia seno AAAA atsakymo, kuris vis dar nurodo viešą kelią.

Išimkite seną virtualią prieglobą kaip atskirą pakeitimą. Naujo bloko viešo dvynio pašalinimas paprastai yra tas žingsnis, kuris iš tikrųjų uždaro įėjimą; privatus klausytojas tik prideda numatytąjį.

Apribokite įeinantį kelią priegloboje

Klausymo adresas riboja lizdą, o ne įėjimo sąsają. Paketas, nukreiptas į tą adresą iš kitur, vis tiek atvyksta kaip vietinė įvestis, todėl prieglobos ugniasienei reikia savo pareiškimo apie tai, iš kur ryšys gali ateiti. Todėl vien susiejimas retai tenkina auditą.

Esant numatytajai atmetimo įeinamajai politikai ir neturint platesnio leidimo šiai paslaugai, apribota taisyklė kartu įvardija tunelį, šaltinio diapazoną, paskirties vietą ir prievadą:

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

Perskaitykite galiojančią ugniasienės tvarką prieš ją taikydami. Ankstesnis platus priėmimas gali panaikinti apribojimą, o ankstesnis galutinis atmetimas gali neleisti pasiekti šio leidimo. Nevalykite nesusijusių taisyklių ir neišjunkite ugniasienės, kad pavyzdys tilptų.

Ši taisyklė yra prieglobos įvestis, o ne maršrutas į kitą LAN mašiną, o išorinis šliuzo OpenVPN klausytojas lieka atskira paslauga. Jei svetainė anksčiau buvo vieša, suplanuokite, kaip senas įėjimas išimamas ir kaip tvarkomos esamos sesijos.

Išlaikykite HTTP sąrašą nepažeistą, kai keičiasi vietos

NGINX vertina allow ir deny įrašus eilės tvarka, o aukščiau esantis serverio lygio sąrašas įleidžia deklaruotą grupę prieš galutinį deny. Prieigos modulis taip pat įrašo, kad vieta, apibrėžianti bet kurį prieigos įrašą, naudoja savo sąrašą, o ne pirminį. Tvarka yra tokia pat svarbi kaip ir patys įrašai.

Tas atstatymas yra įprasta regresija. Nauja įkėlimo, API ar sveikatos vieta, kuri prideda vieną įrašą, tyliai pakeičia serverio lygio apribojimą, ir svetainė tampa platesnė naujausiame kelyje.

Peržiūrėkite kiekvieną vietą, slapyvardį ir alternatyvų bloką kaip tos pačios politikos dalį. Jei IP patikros derinamos su NGINX autentifikavimu, supraskite satisfy: any nustatymas gali įleisti klientą per vieną mechanizmą, kol kitas dar nepraėjo. Įtraukite prieigos sąrašą į vietų peržiūros kontrolinį sąrašą.

HTTP atmetimas įvyksta po to, kai TCP ryšys pasiekia NGINX. Jis papildo tinklo apribojimą, o pačios programos autorizacija vis dar taikoma kiekvienam naudotojui.

Patikrinkite veikiantį kelią ir gedimo atvejį

Paleiskite konfigūracijos analizatorių, apžiūrėkite klausančius lizdus, tada atlikite naują įvardytą užklausą iš numatyto kliento. Patvirtinkite, kad sertifikatas validuojamas, DNS vardas išsprendžiamas į susietą adresą, o atsakymas ateina iš laukiamos šaknies.

Toliau išbandykite neįtrauktą šaltinį ir alternatyvų įėjimą. Veikianti leidžiama užklausa nieko nesako apie kelius, kuriuos norėjote uždaryti, ir būtent neįtrauktame bandyme pasirodo likęs klausytojas ar platus ugniasienės priėmimas.

Pakartokite paleidimo ar VPN atkūrimo atvejį. Jei NGINX paleidžiamas prieš atsirandant tunelio adresui, susiejimas gali nepavykti net su tobula failu. Suderinkite adreso pasirengimą ir prieš keisdami bendrinamą žiniatinklio serverį palikite vietinį atkūrimo kelią.

Užrašykite lizdą, prievadą, šaltinio diapazoną ir HTTP sąrašą, kurie praėjo. Kitas VPN ar DNS pakeitimas gali perkelti bet kurį iš jų, o keturias įvardytas reikšmes lengviau palyginti nei veikiančią naršyklės kortelę.

Susiję straipsniai