NGINX-ejo nur por VPN: aŭskultanto, fajroŝirmilo kaj HTTP-permeslisto

Privata NGINX-ejo bezonas ligitan VPN-ingon, limigitan gastigan eniron kaj sendifektan HTTP-alirliston. Testu ĉiujn tri, ne nur unu servilblokon.

Tri sendependaj decidoj staras inter privata ejo kaj la interreto: kiu ingo akceptas la konekton, kiu vojo povas ĝin liveri kaj al kiuj HTTP-klientoj la elektita servilo respondas. Servilbloko faras nur la unuan decidon. Traktu la aliajn du kiel apartajn regilojn, alie la ejo aspektos privata dum malnova enirejo restas malfermita. Plej multaj NGINX-malsukcesoj nur por VPN venas de testado de nur la unua tavolo.

La ekzemplo uzas Linux-OpenVPN-pordegon ĉe 10.90.0.1 sur tun0, klientojn en 10.90.0.0/24, konservitajn fontojn kaj TCP 8443 rezervitan por ĉi tiu enirejo. Adaptu la valorojn, konservu la tavolojn.

Komencu per la ingo, ne per la gastnomo

Ligu la HTTPS-aŭskultanton al la tunela adreso kaj dediĉita pordo. Specifa adreso estas pli facile rezonebla ol ĵokera ingo plus nomkontrolo, ĉar la kerno ne donos la pordon al alia loka adreso.

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

La atestilo devas nomi la servan gastnomon, kiun klientoj tajpas, kaj la privata DNS-vido devas solvi tiun gaston al la ligita adreso. server_name nur elektas virtualan gaston; ĝi aŭtentikigas neniun. Mankanta DNS-rikordo produktas atestileraron, kiu aspektas kiel TLS-difekto. Kontrolu la nomon antaŭ ol anstataŭigi la atestilon.

Legu la efektivan agordon antaŭ ol aldoni la dosieron. Inkludoj kaj ĵokeraj aŭskultantoj povas servi la saman radikon aliloke, kaj implicita servilo povas respondi petojn, kiujn la nova bloko neniam vidas.

Fermu ĉiun alian aŭskultanton por tiu enhavo

Listigu la listen-direktivojn kaj komparu la radikojn, kiujn ili servas. Bloko aldonita por alia aplikaĵo povas prokuri al la sama upstream, kaj malnova implicita servilo povas daŭre respondi post kiam la nova estas en loko. Tiu eligo estas la vera inventaro, ne la dosiero, kiun vi ĵus redaktis. Komparu ĉiun radikon, kiu servas la saman enhavon.

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

Kontrolu ambaŭ adresfamiliojn. IPv4-ligo lasas IPv6-ingon netuŝita, kaj nova A-rikordo ne retiras malnovan AAAA-respondon, kiu ankoraŭ montras al publika vojo.

Eksigu la malnovan virtualan gaston kiel apartan ŝanĝon. Forigi la publikan ĝemelon de la nova bloko kutime estas la paŝo, kiu vere fermas la enirejon; la privata aŭskultanto nur aldonas la intencitan.

Limigu la envenan vojon ĉe la gasto

La aŭskulta adreso limigas la ingon, ne la envenan interfacon. Paketo direktita al tiu adreso de aliloke ankoraŭ alvenas kiel loka enigo, do la gastiga fajroŝirmilo bezonas sian propran deklaron pri tio, de kie la konekto rajtas veni. Tial ligo sola malofte kontentigas revizion.

Kun implicita rifuza envena politiko kaj sen pli larĝa permeso por ĉi tiu servo, limigita regulo nomas la tunelon, la fontan intervalon, la celon kaj la pordon kune:

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

Legu la efektivan ordon de la fajroŝirmilo antaŭ ol apliki ĝin. Pli frua larĝa akcepto povas venki la limigon, kaj pli frua fina forĵeto povas malhelpi atingi ĉi tiun permeson. Ne forviŝu nesociajn regulojn kaj ne malŝaltu la fajroŝirmilon por adapti la ekzemplon.

Tiu regulo estas gastiga enigo, ne itinero al alia LAN-maŝino, kaj la ekstera OpenVPN-aŭskultanto de la pordego restas aparta servo. Se la ejo antaŭe estis publika, planu kiel la malnova enirejo estas eksigata kaj kiel ekzistantaj sesioj estas traktataj.

Tenu la HTTP-liston sendifekta dum lokoj ŝanĝiĝas

NGINX taksas allow- kaj deny-rikordojn laŭ ordo, kaj la listo sur servila nivelo supre allasas la deklarita naĝejo antaŭ la fina deny. La alirmodulo ankaŭ registras, ke loko difinanta ajnan alirrikordon uzas sian propran liston anstataŭ la gepatran. Ordo gravas same kiel la rikordoj mem.

Tiu restarigo estas la kutima regreso. Nova alŝuta, API aŭ sano-loko, kiu aldonas unu rikordon, silentete anstataŭigas la limigon sur servila nivelo, kaj la ejo larĝiĝas ĉe la plej laste aldonita vojo.

Revizu ĉiun lokon, alinomon kaj alternativan blokon kiel parton de la sama politiko. Se IP-kontroloj estas kombinitaj kun NGINX-aŭtentikigo, komprenu satisfy: agordo any povas allasi klienton per unu mekanismo dum la alia ne pasis. Metu la alirliston en la kontrolan liston por lokoj.

HTTP-rifuzo okazas post kiam la TCP-konekto atingas NGINX. Ĝi kompletigas la retan limigon, kaj la propra rajtigo de la aplikaĵo ankoraŭ validas por ĉiu uzanto.

Kontrolu la vivan vojon kaj la malsukcesan kazon

Rulu la agordan analizilon, inspektu la aŭskultantajn ingojn, poste faru novan nomitan peton de intencita kliento. Konfirmu, ke la atestilo validas, ke la DNS-nomo solviĝas al la ligita adreso kaj ke la respondo venas de la atendita radiko.

Poste testu ekskluditan fonton kaj alternativan enirejon. Funkcianta permesita peto diras nenion pri la vojoj, kiujn vi intencis fermi, kaj ĝuste en la ekskludita testo aperas restinta aŭskultanto aŭ larĝa fajroŝirmila akcepto.

Ripetu la startan aŭ VPN-restarigan kazon. Se NGINX startas antaŭ ol ekzistas la tunela adreso, la ligo povas malsukcesi eĉ kun perfekta dosiero. Kunordigu la pretecon de la adreso kaj konservu lokan restarigan vojon antaŭ ol ŝanĝi kunhavatan retservilon.

Registru la ingon, pordon, fontan intervalon kaj HTTP-liston, kiuj pasis. La sekva VPN- aŭ DNS-ŝanĝo povas movi iun ajn el ili, kaj kvar nomitaj valoroj estas pli facile kompareblaj ol funkcianta retumila langeto.

Rilataj artikoloj