NGINX-site alleen voor VPN: listener, firewall en HTTP-toegangslijst

Drie onafhankelijke beslissingen staan tussen een privésite en het internet: welke socket de verbinding accepteert, welk pad die kan afleveren en welke HTTP-clients de gekozen server antwoordt. Een serverblok neemt alleen de eerste beslissing. Behandel de andere twee als afzonderlijke controles, anders lijkt de site privé terwijl een oude ingang open blijft. De meeste NGINX-fouten voor alleen VPN komen doordat alleen de eerste laag wordt getest.

Het voorbeeld gebruikt een Linux-OpenVPN-gateway op 10.90.0.1 op tun0, clients in 10.90.0.0/24, bewaarde bronnen en TCP 8443 dat voor deze ingang is gereserveerd. Pas de waarden aan, houd de lagen.

Begin bij de socket, niet bij de hostnaam

Bind de HTTPS-listener aan het tunneladres en een eigen poort. Een specifiek adres is makkelijker te doordenken dan een joker-socket plus naamcontrole, omdat de kernel de poort niet aan een ander lokaal adres geeft.

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

Het certificaat moet de diensthostnaam bevatten die clients typen, en de privé-DNS-weergave moet die host naar het gebonden adres oplossen. server_name kiest alleen een virtuele host; het authenticeert niemand. Een ontbrekende DNS-regel levert een certificaatfout die op een TLS-fout lijkt. Controleer de naam voordat het certificaat wordt vervangen.

Lees de effectieve configuratie voordat het bestand wordt toegevoegd. Includes en joker-listeners kunnen dezelfde root elders bedienen, en een standaardserver kan verzoeken beantwoorden die het nieuwe blok nooit ziet.

Sluit elke andere listener voor die inhoud

List de listen-richtlijnen op en vergelijk de roots die ze bedienen. Een blok dat voor een andere toepassing is toegevoegd, kan naar dezelfde upstream proxyen, en een oude standaardserver kan blijven antwoorden nadat de nieuwe staat. Die uitvoer is de echte inventaris, niet het bestand dat je net hebt bewerkt. Vergelijk elke root die dezelfde inhoud bedient.

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

Controleer beide adresfamilies. Een IPv4-binding laat een IPv6-socket ongemoeid, en een nieuwe A-record trekt geen oud AAAA-antwoord terug dat nog naar een openbaar pad wijst.

Haal de oude virtuele host als aparte wijziging uit gebruik. Het verwijderen van de openbare tweeling van het nieuwe blok is meestal de stap die de ingang echt sluit; de privé-listener voegt alleen de bedoelde toe.

Beperk het inkomende pad op de host

Het luisteradres beperkt de socket, niet de ingress-interface. Een pakket dat van elders naar dat adres wordt gerouteerd, komt nog steeds als lokale invoer aan, daarom heeft de firewall van de host zijn eigen verklaring nodig over waar de verbinding vandaan mag komen. Daarom voldoet een binding alleen zelden aan een audit.

Met een inkomend standaard weigerbeleid en zonder ruimere toestemming voor deze dienst noemt een beperkte regel de tunnel, het bronbereik, de bestemming en de poort samen:

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

Lees de effectieve firewallvolgorde voordat je die toepast. Een eerdere brede acceptatie kan de beperking tenietdoen, en een eerdere terminale drop kan verhinderen dat deze toestemming ooit wordt bereikt. Maak geen niet-gerelateerde regels leeg en zet de firewall niet uit om het voorbeeld te laten passen.

Die regel is host-invoer, geen route naar een andere LAN-machine, en de externe OpenVPN-listener van de gateway blijft een aparte dienst. Als de site eerder openbaar was, plan dan hoe de oude ingang wordt uitgefaseerd en hoe bestaande sessies worden afgehandeld.

Houd de HTTP-lijst intact terwijl locaties veranderen

NGINX evalueert allow- en deny-regels in volgorde, en de lijst op serverniveau hierboven laat de gedeclareerde groep door vóór de laatste deny. De toegangsmodule registreert ook dat een locatie die een toegangsregel definieert, zijn eigen lijst gebruikt in plaats van de bovenliggende lijst. De volgorde is net zo belangrijk als de regels zelf.

Die reset is de gebruikelijke regressie. Een nieuwe upload-, API- of gezondheidslocatie die één regel toevoegt, vervangt stil de beperking op serverniveau, en de site wordt breder op het laatst toegevoegde pad.

Beoordeel elke locatie, alias en alternatief blok als onderdeel van hetzelfde beleid. Als IP-controles worden gecombineerd met NGINX-authenticatie, begrijp satisfy: een any-instelling kan een client via één mechanisme toelaten terwijl het andere niet is geslaagd. Zet de toegangslijst op de checklist voor locaties.

Een HTTP-weigering gebeurt nadat de TCP-verbinding NGINX bereikt. Die vult de netwerkbeperking aan, en de eigen autorisatie van de toepassing geldt nog steeds voor elke gebruiker.

Verifieer het live pad en het foutgeval

Voer de configuratieparser uit, inspecteer de luisterende sockets en doe daarna een nieuwe benoemde aanvraag vanaf een bedoelde client. Bevestig dat het certificaat valideert, de DNS-naam naar het gebonden adres resolvet en het antwoord van de verwachte root komt.

Test daarna een uitgesloten bron en een alternatieve ingang. Een werkend toegestaan verzoek zegt niets over de paden die je wilde sluiten, en in de uitgesloten test komt een overgebleven listener of een brede firewall-acceptatie boven water.

Herhaal het opstart- of VPN-herstelgeval. Als NGINX start voordat het tunneladres bestaat, kan de binding mislukken zelfs met een perfect bestand. Coördineer de adresgereedheid en houd een lokaal herstelpad voordat een gedeelde webserver wordt gewijzigd.

Noteer de socket, poort, bronbereik en HTTP-lijst die zijn geslaagd. De volgende VPN- of DNS-wijziging kan elk daarvan verschuiven, en vier benoemde waarden zijn makkelijker te vergelijken dan een werkend browsertabblad.