NGINX-webbplats endast för VPN: lyssnare, brandvägg och HTTP-tillåtelselista

En privat NGINX-webbplats behöver en bunden VPN-socket, en avgränsad värdinmatningsregel och en intakt HTTP-åtkomstlista. Testa alla tre, inte bara ett serverblock.

Tre oberoende beslut står mellan en privat webbplats och internet: vilken socket som tar emot anslutningen, vilken väg som kan leverera den och vilka HTTP-klienter den valda servern svarar. Ett serverblock fattar bara det första beslutet. Behandla de andra två som separata kontroller, annars ser webbplatsen privat ut medan en gammal ingång förblir öppen. De flesta NGINX-fel som bara gäller VPN kommer av att bara testa det första lagret.

Exemplet använder en Linux-OpenVPN-gateway på 10.90.0.1 på tun0, klienter i 10.90.0.0/24, bevarade källor och TCP 8443 reserverad för denna ingång. Justera värdena, behåll lagren.

Börja med socketen, inte värdnamnet

Bind HTTPS-lyssnaren till tunneladressen och en egen port. En specifik adress är lättare att tänka igenom än en joker-socket plus en namnkontroll, eftersom kärnan inte ger porten till en annan lokal adress.

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 måste ange tjänstens värdnamn som klienterna skriver, och den privata DNS-vyn måste lösa den värden till den bundna adressen. server_name väljer bara en virtuell värd; det autentiserar ingen. En saknad DNS-post ger ett certifikatfel som ser ut som ett TLS-fel. Kontrollera namnet innan certifikatet byts ut.

Läs den effektiva konfigurationen innan filen läggs till. Inkluderingar och joker-lyssnare kan betjäna samma rot någon annanstans, och en standardserver kan svara på förfrågningar som det nya blocket aldrig ser.

Stäng varje annan lyssnare för det innehållet

Lista listen-direktiven och jämför rötterna de betjänar. Ett block som lagts till för ett annat program kan proxa till samma upstream, och en gammal standardserver kan fortsätta svara efter att den nya är på plats. Den utskriften är den egentliga inventeringen, inte filen du just redigerade. Jämför varje rot som betjänar samma innehåll.

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

Kontrollera båda adressfamiljerna. En IPv4-bindning lämnar en IPv6-socket orörd, och en ny A-post drar inte tillbaka ett gammalt AAAA-svar som fortfarande pekar på en offentlig väg.

Avveckla den gamla virtuella värden som en separat ändring. Att ta bort det nya blockets offentliga tvilling är oftast steget som verkligen stänger ingången; den privata lyssnaren lägger bara till den avsedda.

Avgränsa den inkommande vägen på värden

Lyssningsadressen begränsar socketen, inte ingångsgränssnittet. Ett paket som routas till den adressen från annat håll anländer ändå som lokal indata, därför behöver värdens brandvägg sitt eget uttalande om varifrån anslutningen får komma. Därför uppfyller en bindning ensam sällan en revision.

Med en inkommande standardavvisningspolicy och utan ett bredare tillstånd för denna tjänst namnger en avgränsad regel tunneln, källintervallet, destinationen och porten tillsammans:

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

Läs brandväggens effektiva ordning innan den tillämpas. Ett tidigare brett accepterande kan slå ut begränsningen, och en tidigare terminal drop kan hindra att detta tillstånd någonsin nås. Töm inte orelaterade regler och stäng inte av brandväggen för att exemplet ska passa.

Den regeln är värdindata, inte en väg till en annan LAN-maskin, och gatewayens yttre OpenVPN-lyssnare är fortfarande en separat tjänst. Om webbplatsen var offentlig tidigare, planera hur den gamla ingången avvecklas och hur befintliga sessioner hanteras.

Håll HTTP-listan intakt när platser ändras

NGINX utvärderar allow- och deny-poster i ordning, och listan på servernivå ovan släpper in den deklarerade gruppen före den slutliga deny. Åtkomstmodulen registrerar också att en plats som definierar en åtkomstpost använder sin egen lista i stället för föräldralistan. Ordningen är lika viktig som posterna själva.

Den återställningen är den vanliga regressionen. En ny uppladdnings-, API- eller hälsoplats som lägger till en post ersätter tyst begränsningen på servernivå, och webbplatsen blir bredare på den senast tillagda vägen.

Granska varje plats, alias och alternativt block som en del av samma policy. Om IP-kontroller kombineras med NGINX-autentisering, förstå satisfy: en any-inställning kan släppa in en klient via en mekanism medan den andra inte har godkänts. Sätt åtkomstlistan i checklistan för platser.

En HTTP-avvisning sker efter att TCP-anslutningen når NGINX. Den kompletterar nätverksbegränsningen, och programmets egen auktorisering gäller fortfarande för varje användare.

Verifiera den levande vägen och felet

Kör konfigurationsparsern, inspektera de lyssnande socketarna och gör sedan en ny namngiven begäran från en avsedd klient. Bekräfta att certifikatet validerar, att DNS-namnet löses till den bundna adressen och att svaret kommer från den förväntade roten.

Testa sedan en utesluten källa och en alternativ ingång. En fungerande tillåten begäran säger ingenting om vägarna du ville stänga, och det är i det uteslutna testet en kvarvarande lyssnare eller ett brett brandväggsgodkännande dyker upp.

Upprepa start- eller VPN-återställningsfallet. Om NGINX startar innan tunneladressen finns kan bindningen misslyckas även med en perfekt fil. Samordna adressberedskapen och behåll en lokal återställningsväg innan en delad webbserver ändras.

Registrera socketen, porten, källintervallet och HTTP-listan som godkändes. Nästa VPN- eller DNS-ändring kan flytta vilken som helst av dem, och fyra namngivna värden är lättare att jämföra än en fungerande webbläsarflik.

Relaterade artiklar