NGINX-nettstad berre for VPN: lyttar, brannmur og HTTP-tillatingsliste

Tre uavhengige avgjerder står mellom ein privat nettstad og internett: kva sokkel som tek imot sambandet, kva veg som kan levere det, og kva HTTP-klientar den valde serveren svarar. Ei serverblokk tek berre den første avgjerda. Handsame dei to andre som separate kontrollar, elles ser nettstaden privat ut medan ein gammal inngang står open. Dei fleste NGINX-feil som berre gjeld VPN, kjem av å teste berre det første laget.

Dømet brukar ein Linux-OpenVPN-gateway på 10.90.0.1 på tun0, klientar i 10.90.0.0/24, bevarde kjelder og TCP 8443 reservert for denne inngangen. Juster verdiane, hald laga.

Start med sockelen, ikkje vertsnamnet

Bind HTTPS-lyttaren til tunneladressa og ein eigen port. Ei spesifikk adresse er lettare å tenkje på enn ein joker-sokkel pluss ein namnekontroll, fordi kjernen ikkje gjev porten til ei anna lokal adresse.

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

Sertifikatet må namngje tenestevertsnamnet klientane skriv, og den private DNS-visninga må løyse den verten til den bundne adressa. server_name vel berre ein virtuell vert; det autentiserer ingen. Ei manglande DNS-oppføring gjev ein sertifikatfeil som ser ut som ein TLS-feil. Kontroller namnet før sertifikatet vert bytt.

Les den effektive konfigurasjonen før fila vert lagd til. Inkluderingar og joker-lyttarar kan tene same rot andre stader, og ein standardserver kan svare på førespurnader den nye blokka aldri ser.

Lat alle andre lyttarar for det innhaldet stengje

List opp listen-direktiva og samanlikn røtene dei tener. Ei blokk lagd til for eit anna program kan proxy til same upstream, og ein gammal standardserver kan halde fram med å svare etter at den nye er på plass. Den utskrifta er den eigentlege oversikta, ikkje fila du nettopp redigerte. Samanlikn kvar rot som tener same innhald.

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

Kontroller begge adressefamiliane. Ei IPv4-binding lèt ein IPv6-sokkel vere urørd, og ei ny A-oppføring dreg ikkje attende eit gammalt AAAA-svar som framleis peikar på ein offentleg veg.

Avvikle den gamle virtuelle verten som ei eiga endring. Å fjerne den offentlege tvillingen til den nye blokka er vanlegvis trinnet som faktisk stenger inngangen; den private lyttaren legg berre til den tiltenkte.

Avgrens den innkomande vegen på verten

Lytteadressa avgrensar sockelen, ikkje inngangsgrensesnittet. Ein pakke som vert ruta til den adressa frå ein annan stad, kjem likevel inn som lokal inngang, så brannmuren til verten treng si eiga fråsegn om kvar sambandet kan kome frå. Difor oppfyller ei binding åleine sjeldan ein revisjon.

Med ein innkomande standardnekt-politikk og utan ei breiare løyve for denne tenesta namngjev ein avgrensa regel tunnelen, kjeldeområdet, destinasjonen og porten saman:

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

Les den effektive rekkjefølgja til brannmuren før han vert brukt. Ei tidlegare brei godtaking kan overvinne avgrensinga, og eit tidlegare terminalt dropp kan hindre at denne løyva vert nådd. Ikkje tøm urelaterte reglar og ikkje slå av brannmuren for å få dømet til å passe.

Den regelen er vertsinngang, ikkje ei rute til ein annan LAN-maskin, og den ytre OpenVPN-lyttaren til gatewayen er framleis ei eiga teneste. Viss nettstaden var offentleg før, planlegg korleis den gamle inngangen vert avvikla og korleis eksisterande økter vert handterte.

Hald HTTP-lista intakt når plasseringar endrar seg

NGINX vurderer allow- og deny-oppføringar i rekkjefølgje, og lista på servernivå over slepp inn den erklærte gruppa før den siste deny. Tilgangsmodulen registrerer òg at ein plassering som definerer ei tilgangsoppføring, brukar si eiga liste i staden for foreldrelista. Rekkjefølgja tel like mykje som oppføringane sjølve.

Den tilbakestillinga er den vanlege regresjonen. Ein ny opplastings-, API- eller helseplassering som legg til éi oppføring, erstattar stille avgrensinga på servernivå, og nettstaden vert breiare på vegen som sist vart lagd til.

Gå gjennom kvar plassering, alias og alternativ blokk som del av same policy. Viss IP-sjekkar vert kombinerte med NGINX-autentisering, forstå satisfy: ei any-innstilling kan sleppe ein klient inn via ein mekanisme medan den andre ikkje er bestått. Set tilgangslista i sjekklista for plasseringar.

Ei HTTP-avvising skjer etter at TCP-sambandet når NGINX. Ho utfyller nettverksavgrensinga, og eigen autorisasjon i programmet gjeld framleis for kvar brukar.

Stadfest den levande vegen og feiltilfellet

Køyr konfigurasjonsparsaren, inspiser dei lyttande soklane, og lag deretter ein ny namngjeven førespurnad frå ein tiltenkt klient. Stadfest at sertifikatet validerer, at DNS-namnet løyser til den bundne adressa, og at svaret kjem frå den venta rota.

Test deretter ei utelukka kjelde og ein alternativ inngang. Ein fungerande tillaten førespurnad seier ingenting om vegane du ville stengje, og det er i den utelukka testen ein attverande lyttar eller ei brei brannmur-godtaking dukkar opp.

Gjenta oppstarts- eller VPN-gjenopprettingstilfellet. Viss NGINX startar før tunneladressa finst, kan bindinga mislukkast sjølv med ei perfekt fil. Koordiner adresseberedskapen og hald ein lokal gjenopprettingsveg før ein delt nettserver vert endra.

Registrer sockelen, porten, kjeldeområdet og HTTP-lista som bestod. Den neste VPN- eller DNS-endringa kan flytte kva som helst av dei, og fire namngjevne verdiar er lettare å samanlikne enn ei fungerande nettlesarfane.