NGINX-nettsted bare for VPN: lytter, brannmur og HTTP-tillatelsesliste

Tre uavhengige beslutninger står mellom et privat nettsted og internett: hvilken socket som tar imot forbindelsen, hvilken vei som kan levere den, og hvilke HTTP-klienter den valgte serveren svarer. En serverblokk tar bare den første beslutningen. Behandle de to andre som separate kontroller, ellers vil nettstedet se privat ut mens en gammel inngang forblir åpen. De fleste NGINX-feil som bare gjelder VPN, kommer av å teste bare det første laget.

Eksempelet bruker en Linux-OpenVPN-gateway på 10.90.0.1 på tun0, klienter i 10.90.0.0/24, bevarede kilder og TCP 8443 reservert for denne inngangen. Juster verdiene, behold lagene.

Start med socketen, ikke vertsnavnet

Bind HTTPS-lytteren til tunneladressen og en egen port. En spesifikk adresse er lettere å tenke på enn en joker-socket pluss en navnekontroll, fordi kjernen ikke gir porten til en annen 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å angi tjenestevertsnavnet klientene skriver, og den private DNS-visningen må løse den verten til den bundne adressen. server_name velger bare en virtuell vert; det autentiserer ingen. En manglende DNS-oppføring gir en sertifikatfeil som ser ut som en TLS-feil. Kontroller navnet før sertifikatet byttes.

Les den effektive konfigurasjonen før filen legges til. Inkluderinger og joker-lyttere kan betjene samme rot andre steder, og en standardserver kan svare på forespørsler den nye blokken aldri ser.

Lukk alle andre lyttere for det innholdet

List opp listen-direktivene og sammenlign røttene de betjener. En blokk lagt til for et annet program kan proxy til samme upstream, og en gammel standardserver kan fortsette å svare etter at den nye er på plass. Den utskriften er den egentlige oversikten, ikke filen du nettopp redigerte. Sammenlign hver rot som betjener samme innhold.

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

Kontroller begge adressefamiliene. En IPv4-binding lar en IPv6-socket være urørt, og en ny A-oppføring trekker ikke tilbake et gammelt AAAA-svar som fortsatt peker på en offentlig vei.

Avvikle den gamle virtuelle verten som en egen endring. Å fjerne den nye blokkens offentlige tvilling er vanligvis trinnet som faktisk lukker inngangen; den private lytteren legger bare til den tiltenkte.

Avgrens den innkommende veien på verten

Lytteadressen begrenser socketen, ikke inngangsgrensesnittet. En pakke som rutes til den adressen fra et annet sted, ankommer fortsatt som lokal inngang, så vertens brannmur trenger sin egen erklæring om hvor forbindelsen kan komme fra. Derfor oppfyller en binding alene sjelden en revisjon.

Med en innkommende standardavvisningspolicy og uten en bredere tillatelse for denne tjenesten navngir en avgrenset regel tunnelen, kildeområdet, destinasjonen og porten samlet:

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

Les brannmurens effektive rekkefølge før den brukes. En tidligere bred aksept kan overvinne begrensningen, og en tidligere terminal dropp kan hindre at denne tillatelsen nås. Ikke tøm urelaterte regler og ikke slå av brannmuren for å få eksempelet til å passe.

Den regelen er vertsinngang, ikke en rute til en annen LAN-maskin, og gatewayens ytre OpenVPN-lytter forblir en egen tjeneste. Hvis nettstedet var offentlig før, planlegg hvordan den gamle inngangen avvikles og hvordan eksisterende sesjoner håndteres.

Hold HTTP-listen intakt når plasseringer endres

NGINX vurderer allow- og deny-oppføringer i rekkefølge, og listen på servernivå over slipper inn den erklærte gruppen før den endelige deny. Tilgangsmodulen registrerer også at en plassering som definerer en tilgangsoppføring, bruker sin egen liste i stedet for foreldrelisten. Rekkefølgen betyr like mye som oppføringene selv.

Den tilbakestillingen er den vanlige regresjonen. En ny opplastings-, API- eller helseplassering som legger til én oppføring, erstatter stille begrensningen på servernivå, og nettstedet blir bredere på veien som sist ble lagt til.

Gå gjennom hver plassering, alias og alternativ blokk som del av samme policy. Hvis IP-sjekker kombineres med NGINX-autentisering, forstå satisfy: en any-innstilling kan slippe en klient inn via én mekanisme mens den andre ikke er bestått. Sett tilgangslisten i sjekklisten for plasseringer.

En HTTP-avvisning skjer etter at TCP-forbindelsen når NGINX. Den utfyller nettverksbegrensningen, og applikasjonens egen autorisasjon gjelder fortsatt for hver bruker.

Verifiser den levende veien og feiltilfellet

Kjør konfigurasjonsparseren, inspiser de lyttende socketene, og lag deretter en ny navngitt forespørsel fra en tiltenkt klient. Bekreft at sertifikatet validerer, at DNS-navnet løses til den bundne adressen, og at svaret kommer fra den forventede roten.

Test deretter en utelukket kilde og en alternativ inngang. En fungerende tillatt forespørsel sier ingenting om veiene du ville lukke, og det er i den utelukkede testen en gjenværende lytter eller en bred brannmur-aksept dukker opp.

Gjenta oppstarts- eller VPN-gjenopprettingstilfellet. Hvis NGINX starter før tunneladressen finnes, kan bindingen mislykkes selv med en perfekt fil. Koordiner adresseberedskapen og hold en lokal gjenopprettingsvei før en delt webserver endres.

Registrer socketen, porten, kildeområdet og HTTP-listen som besto. Den neste VPN- eller DNS-endringen kan flytte hvilken som helst av dem, og fire navngitte verdier er lettere å sammenligne enn en fungerende nettleserfane.