NGINX-werf net vir VPN: luisteraar, firewall en HTTP-toegangslys

Drie onafhanklike besluite staan tussen 'n private werf en die internet: watter sok die verbinding aanvaar, watter pad dit kan aflewer, en watter HTTP-kliënte die gekose bediener antwoord. 'n Bedienerblok neem net die eerste besluit. Behandel die ander twee as afsonderlike kontroles, anders lyk die werf privaat terwyl 'n ou ingang oop bly. Die meeste NGINX-foute wat net vir VPN bedoel is, kom daarvan dat net die eerste laag getoets word.

Die voorbeeld gebruik 'n Linux-OpenVPN-poort by 10.90.0.1 op tun0, kliënte in 10.90.0.0/24, bewaarde bronne en TCP 8443 wat vir hierdie inskrywing gereserveer is. Pas die waardes aan, hou die lae.

Begin met die sok, nie die gasheernaam nie

Bind die HTTPS-luisteraar aan die tonneladres en 'n toegewyde poort. 'n Spesifieke adres is makliker om oor te redeneer as 'n wildkaart-sok plus 'n naamkontrole, want die kernel sal nie die poort aan 'n ander plaaslike adres gee nie.

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

Die sertifikaat moet die diensgasheernaam noem wat kliënte tik, en die private DNS-aansig moet daardie gasheer na die gebinde adres oplos. 'n server_name kies net 'n virtuele gasheer; dit verifieer niemand nie. 'n Ontbrekende DNS-inskrywing lewer 'n sertifikaatfout wat soos 'n TLS-fout lyk. Kontroleer die naam voordat die sertifikaat vervang word.

Lees die effektiewe konfigurasie voordat die lêer bygevoeg word. Insluitings en wildkaart-luisteraars kan dieselfde wortel elders bedien, en 'n verstekbediener kan versoeke antwoord wat die nuwe blok nooit sien nie.

Sluit elke ander luisteraar vir daardie inhoud

Lys die listen-aanwysings en vergelyk die wortels wat hulle bedien. 'n Blok wat vir 'n ander toepassing bygevoeg is, kan na dieselfde opstroom gevolg gee, en 'n ou verstekbediener kan bly antwoord nadat die nuwe een in plek is. Daardie uitset is die werklike inventaris, nie die lêer wat jy pas verander het nie. Vergelyk elke wortel wat dieselfde inhoud bedien.

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

Kontroleer albei adresfamilies. 'n IPv4-binding laat 'n IPv6-sok onaangeraak, en 'n nuwe A-rekord trek nie 'n ou AAAA-antwoord terug wat steeds na 'n publieke pad wys nie.

Trek die ou virtuele gasheer as 'n afsonderlike verandering terug. Die verwydering van die nuwe blok se publieke tweeling is gewoonlik die stap wat die ingang werklik sluit; die private luisteraar voeg net die bedoelde een by.

Beperk die inkomende pad by die gasheer

Die luisteradres beperk die sok, nie die inkomende koppelvlak nie. 'n Pakket wat van elders na daardie adres gerouteer word, arriveer steeds as plaaslike invoer, so die gasheer se firewall het sy eie verklaring nodig oor waar die verbinding vandaan mag kom. Daarom bevredig 'n binding alleen selde 'n oudit.

Met 'n verstek-weier-inkombeleid en geen breër toelating vir hierdie diens nie, noem 'n beperkte reël die tonnel, die bronreeks, die bestemming en die poort saam:

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

Lees die effektiewe firewall-orde voordat dit toegepas word. 'n Vroeëre breë aanvaarding kan die beperking verydel, en 'n vroeëre terminale verwerping kan keer dat hierdie toelating ooit bereik word. Moenie onverwante reëls spoel of die firewall afskakel om die voorbeeld te laat pas nie.

Daardie reël is gasheer-invoer, nie 'n roete na 'n ander LAN-masjien nie, en die poort se buitenste OpenVPN-luisteraar bly 'n afsonderlike diens. As die werf voorheen publiek was, beplan hoe die ou ingang teruggetrek word en hoe bestaande sessies hanteer word.

Hou die HTTP-lys ongeskonde terwyl liggings verander

NGINX evalueer allow- en deny-inskrywings in volgorde, en die lys op bediener-vlak hierbo laat die verklaarde poel toe voor die finale deny. Die toegangsmodule teken ook aan dat 'n ligging wat enige toegangsinskrywing definieer, sy eie lys gebruik eerder as die ouerlys. Volgorde maak net so saak soos die inskrywings self.

Daardie herstelling is die gewone regressie. 'n Nuwe oplaai-, API- of gesondheidsligging wat een inskrywing byvoeg, vervang die beperking op bediener-vlak stilweg, en die werf word breër by die mees onlangs bygevoegde pad.

Hersien elke ligging, alias en alternatiewe blok as deel van dieselfde beleid. As IP-kontroles met NGINX-verifikasie gekombineer word, verstaan satisfy: 'n any-instelling kan 'n kliënt deur een meganisme toelaat terwyl die ander nog nie geslaag het nie. Sit die toegangslys in die kontrolelys vir liggings.

'n HTTP-weiering gebeur nadat die TCP-verbinding NGINX bereik. Dit vul die netwerkbeperking aan, en die toepassing se eie magtiging geld steeds vir elke gebruiker.

Verifieer die lewende pad en die foutgeval

Voer die konfigurasie-ontleder uit, ondersoek die luisterende soks, en maak dan 'n vars genoemde versoek vanaf 'n bedoelde kliënt. Bevestig die sertifikaat valideer, die DNS-naam los op na die gebinde adres en die antwoord kom van die verwagte wortel.

Toets volgende 'n uitgeslote bron en 'n alternatiewe ingang. 'n Werkende toegelate versoek sê niks oor die paaie wat jy bedoel het om te sluit nie, en die uitgeslote toets is waar 'n oorblywende luisteraar of 'n breë firewall-aanvaarding opduik.

Herhaal die opstart- of VPN-herstelgeval. As NGINX begin voordat die tonneladres bestaan, kan die binding misluk selfs met 'n perfekte lêer. Koördineer adresgereedheid en hou 'n plaaslike herstelpad voordat 'n gedeelde webbediener verander word.

Teken die sok, poort, bronreeks en HTTP-lys aan wat geslaag het. Die volgende VPN- of DNS-verandering kan enigeen daarvan skuif, en vier genoemde waardes is makliker om te vergelyk as 'n werkende blaaier-oortjie.