Spletno mesto NGINX samo za VPN: poslušalec, požarni zid in seznam dovoljenj HTTP

Zasebno spletno mesto NGINX potrebuje vezan vtič VPN, omejeno pravilo vstopa na gostitelju in nepoškodovan seznam dostopa HTTP. Preizkusite vse tri, ne le en blok strežnika.

Med zasebnim spletnim mestom in internetom stojijo tri neodvisne odločitve: kateri vtič sprejme povezavo, katera pot jo lahko dostavi in katerim odjemalcem HTTP odgovarja izbrani strežnik. Blok strežnika sprejme le prvo odločitev. Z drugima dvema ravnajte kot z ločenima kontrolama, sicer bo mesto videti zasebno, stari vhod pa bo ostal odprt. Večina okvar NGINX, namenjenega samo VPN, izhaja iz preizkušanja le prvega sloja.

Primer uporablja prehod Linux OpenVPN na 10.90.0.1 na tun0, odjemalce v 10.90.0.0/24, ohranjene vire in TCP 8443, rezerviran za ta vhod. Prilagodite vrednosti, obdržite sloje.

Začnite z vtičem, ne z imenom gostitelja

Povežite poslušalec HTTPS z naslovom tunela in namenskim vratom. Konkreten naslov je lažje premišljati kot nadomestni vtič in preverjanje imena, ker jedro vrat ne bo predalo drugemu lokalnemu naslovu.

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

Potrdilo mora vsebovati ime gostitelja storitve, ki ga vnašajo odjemalci, in zasebni pogled DNS mora tega gostitelja razrešiti v vezani naslov. server_name le izbere navideznega gostitelja; nikogar ne overi. Manjkajoč zapis DNS ustvari napako potrdila, ki je videti kot okvara TLS. Preverite ime, preden zamenjate potrdilo.

Preberite veljavno konfiguracijo, preden dodate datoteko. Vključitve in nadomestni poslušalci lahko strežejo isti koren drugje, privzeti strežnik pa lahko odgovarja na zahteve, ki jih novi blok nikoli ne vidi.

Zaprite vsak drug poslušalec za to vsebino

Naštejte direktive listen in primerjajte korene, ki jih strežejo. Blok, dodan za drugo aplikacijo, lahko posreduje na isti upstream, stari privzeti strežnik pa lahko še naprej odgovarja, potem ko je novi nameščen. Ta izpis je pravi popis, ne datoteka, ki ste jo pravkar uredili. Primerjajte vsak koren, ki streže isto vsebino.

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

Preverite obe družini naslovov. Vezava IPv4 pusti vtič IPv6 nedotaknjen, nov zapis A pa ne umakne starega odgovora AAAA, ki še vedno kaže na javno pot.

Umaknite starega navideznega gostitelja kot ločeno spremembo. Odstranitev javnega dvojčka novega bloka je običajno korak, ki vhod res zapre; zasebni poslušalec doda le predvidenega.

Omejite dohodno pot na gostitelju

Naslov poslušanja omejuje vtič, ne vhodnega vmesnika. Paket, usmerjen na ta naslov od drugod, vseeno prispe kot lokalni vhod, zato požarni zid gostitelja potrebuje lastno izjavo o tem, od kod sme priti povezava. Zato samo vezava redko zadosti reviziji.

Ob privzeti politiki zavračanja dohodnega prometa in brez širšega dovoljenja za to storitev omejeno pravilo skupaj poimenuje tunel, obseg vira, cilj in vrata:

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

Preberite veljavni vrstni red požarnega zidu, preden ga uporabite. Prejšnje široko sprejetje lahko omejitev izniči, prejšnje končno zavrženje pa lahko prepreči, da bi do tega dovoljenja sploh prišlo. Ne praznite nepovezanih pravil in ne izklapljajte požarnega zidu, da bi se primer ujemal.

To pravilo je vstop na gostitelja, ne pot do drugega računalnika v LAN, zunanji poslušalec OpenVPN prehoda pa ostaja ločena storitev. Če je bilo mesto prej javno, načrtujte, kako se stari vhod umakne in kako se obravnavajo obstoječe seje.

Ohranite seznam HTTP nedotaknjen, ko se lokacije spreminjajo

NGINX vrednoti vnose allow in deny po vrsti, seznam na ravni strežnika zgoraj pa pred končnim deny spusti deklarirano skupino. Modul za dostop tudi zabeleži, da lokacija, ki določa kateri koli vnos dostopa, uporablja svoj seznam namesto nadrejenega. Vrstni red je enako pomemben kot vnosi sami.

Ta ponastavitev je običajna regresija. Nova lokacija za nalaganje, API ali zdravje, ki doda en vnos, tiho nadomesti omejitev na ravni strežnika in mesto postane širše na nazadnje dodani poti.

Preglejte vsako lokacijo, alias in nadomestni blok kot del iste politike. Če so preverjanja IP kombinirana z overjanjem NGINX, razumite satisfy: nastavitev any lahko spusti odjemalca skozi en mehanizem, medtem ko drugi še ni uspel. Vstavite seznam dostopa na kontrolni seznam za lokacije.

Zavrnitev HTTP se zgodi, ko TCP povezava doseže NGINX. Dopolnjuje omrežno omejitev, lastna avtorizacija aplikacije pa še vedno velja za vsakega uporabnika.

Preverite živo pot in primer okvare

Zaženite razčlenjevalnik konfiguracije, preglejte poslušajoče vtiče in nato opravite novo imenovano zahtevo s predvidenega odjemalca. Potrdite, da se potrdilo overi, da se ime DNS razreši na vezani naslov in da odgovor prihaja iz pričakovanega korena.

Nato preizkusite izključen vir in nadomestni vhod. Delujoča dovoljena zahteva ne pove ničesar o poteh, ki ste jih hoteli zapreti, in prav pri izključenem preizkusu se pokaže preostali poslušalec ali široko sprejetje požarnega zidu.

Ponovite primer zagona ali obnovitve VPN. Če se NGINX zažene, preden naslov tunela obstaja, lahko vezava spodleti tudi s popolno datoteko. Uskladite pripravljenost naslova in pred spremembo skupnega spletnega strežnika ohranite lokalno pot za obnovitev.

Zabeležite vtič, vrata, obseg vira in seznam HTTP, ki so uspeli. Naslednja sprememba VPN ali DNS lahko premakne katerega koli od njih, štiri imenovane vrednosti pa je lažje primerjati kot delujoč zavihek brskalnika.

Sorodni članki