NGINX-websted kun til VPN: listener, firewall og HTTP-tilladelsesliste

Tre uafhængige beslutninger står mellem et privat websted og internettet: hvilken socket der accepterer forbindelsen, hvilken vej der kan levere den, og hvilke HTTP-klienter den valgte server svarer. En serverblok træffer kun den første beslutning. Behandl de to andre som separate kontroller, ellers vil webstedet se privat ud, mens en gammel indgang forbliver åben. De fleste NGINX-fejl, der kun er beregnet til VPN, kommer af kun at teste det første lag.

Eksemplet bruger en Linux-OpenVPN-gateway på 10.90.0.1 på tun0, klienter i 10.90.0.0/24, bevarede kilder og TCP 8443 reserveret til denne indgang. Juster værdierne, behold lagene.

Start med socketen, ikke værtsnavnet

Bind HTTPS-lytteren til tunneladressen og en dedikeret port. En specifik adresse er lettere at tænke over end en wildcard-socket plus et navnetjek, fordi kernen ikke giver porten til en anden 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;
    }
}

Certifikatet skal angive den tjenesteværtsnavn, klienterne skriver, og den private DNS-visning skal opløse værten til den bundne adresse. server_name vælger kun en virtuel vært; det godkender ingen. En manglende DNS-post giver en certifikatfejl, der ligner en TLS-fejl. Kontroller navnet, før certifikatet udskiftes.

Læs den effektive konfiguration, før filen tilføjes. Inkluderinger og wildcard-lyttere kan betjene samme rod andre steder, og en standardserver kan svare på anmodninger, som den nye blok aldrig ser.

Luk hver anden lytter for det indhold

List listen-direktiverne og sammenlign de rødder, de betjener. En blok tilføjet til en anden applikation kan proxy til den samme upstream, og en gammel standardserver kan blive ved med at svare, efter den nye er på plads. Det output er den egentlige fortegnelse, ikke den fil, du netop har redigeret. Sammenlign hver rod, der betjener samme indhold.

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

Kontroller begge adressefamilier. En IPv4-binding lader en IPv6-socket være urørt, og en ny A-post fjerner ikke et gammelt AAAA-svar, der stadig peger på en offentlig vej.

Afvikl den gamle virtuelle vært som en separat ændring. Fjernelsen af den nye bloks offentlige tvilling er normalt det trin, der faktisk lukker indgangen; den private lytter tilføjer kun den tilsigtede.

Afgræns den indgående vej på værten

Lytteadressen begrænser socketen, ikke indgangsgrænsefladen. En pakke, der rutes til den adresse fra et andet sted, ankommer stadig som lokalt input, så værtens firewall har brug for sin egen erklæring om, hvor forbindelsen må komme fra. Derfor opfylder en binding alene sjældent en revision.

Med en indgående standardafvisningspolitik og uden en bredere tilladelse til denne tjeneste navngiver en afgrænset regel tunnelen, kildeområdet, destinationen og porten samlet:

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

Læs firewallens effektive rækkefølge, før den anvendes. En tidligere bred accept kan ødelægge begrænsningen, og et tidligere terminalt drop kan forhindre, at denne tilladelse nogensinde nås. Skyl ikke urelaterede regler og slå ikke firewalling fra for at få eksemplet til at passe.

Den regel er værtsinput, ikke en rute til en anden LAN-maskine, og gatewayens ydre OpenVPN-lytter forbliver en separat tjeneste. Hvis webstedet tidligere var offentligt, planlæg hvordan den gamle indgang afvikles, og hvordan eksisterende sessioner håndteres.

Hold HTTP-listen intakt, når placeringer ændres

NGINX evaluerer allow- og deny-poster i rækkefølge, og listen på serverniveau ovenfor tillader den erklærede pulje før den endelige deny. Adgangsmodulet registrerer også, at en placering, der definerer en adgangspost, bruger sin egen liste i stedet for forældrelisten. Rækkefølgen betyder lige så meget som posterne selv.

Nulstillingen er den sædvanlige regression. En ny upload-, API- eller sundhedsplacering, der tilføjer én post, erstatter lydløst begrænsningen på serverniveau, og webstedet bliver bredere på den senest tilføjede vej.

Gennemgå hver placering, alias og alternativ blok som en del af samme politik. Hvis IP-tjek kombineres med NGINX-godkendelse, forstå satisfy: en any-indstilling kan lukke en klient ind via én mekanisme, mens den anden ikke er bestået. Sæt adgangslisten i tjeklisten for placeringer.

En HTTP-afvisning sker, efter TCP-forbindelsen når NGINX. Den supplerer netværksbegrænsningen, og applikationens egen autorisation gælder stadig for hver bruger.

Bekræft den levende vej og fejltilfældet

Kør konfigurationsparseren, undersøg de lyttende sockets, og lav derefter en frisk navngivet anmodning fra en tilsigtet klient. Bekræft, at certifikatet validerer, at DNS-navnet opløses til den bundne adresse, og at svaret kommer fra den forventede rod.

Test derefter en udelukket kilde og en alternativ indgang. En fungerende tilladt anmodning siger intet om de veje, du ville lukke, og det er i den udelukkede test, en resterende lytter eller en bred firewall-accept dukker op.

Gentag opstarts- eller VPN-genopretningstilfældet. Hvis NGINX starter, før tunneladressen findes, kan bindingen fejle selv med en perfekt fil. Koordiner adresseparathed og hold en lokal genopretningsvej, før en delt webserver ændres.

Registrer den socket, port, kildeområde og HTTP-liste, der bestod. Den næste VPN- eller DNS-ændring kan flytte enhver af dem, og fire navngivne værdier er lettere at sammenligne end en fungerende browservane.