NGINX vietne tikai VPN vajadzībām: klausītājs, ugunsmūris un HTTP atļauju saraksts

Trīs neatkarīgi lēmumi šķir privātu vietni no interneta: kura ligzda pieņem savienojumu, kurš ceļš to var piegādāt un kuriem HTTP klientiem atbild izvēlētais serveris. Servera bloks pieņem tikai pirmo lēmumu. Uzskatiet pārējos divus par atsevišķām kontroles ierīcēm, citādi vietne izskatīsies privāta, kamēr veca ieeja paliks atvērta. Lielākā daļa tikai VPN paredzēto NGINX kļūmju rodas, pārbaudot tikai pirmo slāni.

Piemērā izmantota Linux OpenVPN vārteja adresē 10.90.0.1 saskarnē tun0, klienti 10.90.0.0/24, saglabātie avoti un šai ieejai rezervētais TCP 8443. Pielāgojiet vērtības, saglabājiet slāņus.

Sāciet ar ligzdu, nevis resursdatora nosaukumu

Piesaistiet HTTPS klausītāju tuneļa adresei un atsevišķam portam. Konkrēta adrese ir vieglāk pārdomājama nekā aizstājējligzda ar nosaukuma pārbaudi, jo kodols portu nenodos citai vietējai adresei.

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

Sertifikātā jābūt pakalpojuma resursdatora nosaukumam, ko ievada klienti, un privātajam DNS skatam šis resursdators jāatrisina uz piesaistīto adresi. server_name tikai izvēlas virtuālu resursdatoru; tas nevienu neautentificē. Trūkstošs DNS ieraksts rada sertifikāta kļūdu, kas izskatās kā TLS bojājums. Pārbaudiet nosaukumu pirms sertifikāta nomaiņas.

Izlasiet faktisko konfigurāciju pirms faila pievienošanas. Iekļāvumi un aizstājējklausītāji var apkalpot to pašu sakni citur, un noklusējuma serveris var atbildēt uz pieprasījumiem, kurus jaunais bloks nekad neredz.

Aizveriet visus citus šī satura klausītājus

Uzskaitiet listen direktīvas un salīdziniet to apkalpotās saknes. Citai lietojumprogrammai pievienots bloks var pārsūtīt uz to pašu upstream, un vecs noklusējuma serveris var turpināt atbildēt pēc jaunā uzstādīšanas. Šī izvade ir īstais inventārs, nevis tikko rediģētais fails. Salīdziniet katru sakni, kas apkalpo to pašu saturu.

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

Pārbaudiet abas adrešu saimes. IPv4 piesaiste atstāj IPv6 ligzdu neskartu, un jauns A ieraksts neatsauc vecu AAAA atbildi, kas joprojām norāda uz publisku ceļu.

Izņemiet veco virtuālo resursdatoru kā atsevišķu izmaiņu. Jaunā bloka publiskā dvīņa noņemšana parasti ir solis, kas patiešām aizver ieeju; privātais klausītājs tikai pievieno paredzēto.

Ierobežojiet ienākošo ceļu resursdatorā

Klausīšanās adrese ierobežo ligzdu, nevis ieejas saskarni. No citurienes uz šo adresi maršrutēts pakets joprojām ierodas kā vietēja ievade, tāpēc resursdatora ugunsmūrim vajadzīgs savs paziņojums par to, no kurienes savienojums drīkst nākt. Tāpēc vien piesaiste reti apmierina auditu.

Ar noklusējuma noraidīšanas ienākošo politiku un bez plašākas atļaujas šim pakalpojumam ierobežots noteikums kopā nosauc tuneli, avota diapazonu, galamērķi un portu:

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

Izlasiet faktisko ugunsmūra secību pirms tās piemērošanas. Agrāka plaša atļaušana var izjaukt ierobežojumu, un agrāka galīga nomešana var neļaut šai atļaujai vispār tikt sasniegtai. Neiztīriet nesaistītus noteikumus un neizslēdziet ugunsmūri, lai piemērs atbilstu.

Šis noteikums ir resursdatora ievade, nevis maršruts uz citu LAN mašīnu, un vārtejas ārējais OpenVPN klausītājs paliek atsevišķs pakalpojums. Ja vietne iepriekš bija publiska, plānojiet, kā vecā ieeja tiek izņemta un kā tiek apstrādātas esošās sesijas.

Saglabājiet HTTP sarakstu neskartu, mainoties atrašanās vietām

NGINX novērtē allow un deny ierakstus secībā, un iepriekš minētais servera līmeņa saraksts pielaiž deklarēto kopu pirms galīgā deny. Piekļuves modulis arī reģistrē, ka atrašanās vieta, kas definē jebkuru piekļuves ierakstu, izmanto savu sarakstu, nevis vecāksarakstu. Secība ir tikpat svarīga kā paši ieraksti.

Šī atiestatīšana ir ierastā regresija. Jauna augšupielādes, API vai veselības atrašanās vieta, kas pievieno vienu ierakstu, klusi aizstāj servera līmeņa ierobežojumu, un vietne kļūst plašāka visnesenāk pievienotajā ceļā.

Pārskatiet katru atrašanās vietu, aizstājvārdu un alternatīvo bloku kā vienas politikas daļu. Ja IP pārbaudes tiek apvienotas ar NGINX autentifikāciju, izprotiet satisfy: iestatījums any var ielaist klientu pa vienu mehānismu, kamēr otrs vēl nav izturēts. Iekļaujiet piekļuves sarakstu atrašanās vietu pārskata kontrolsarakstā.

HTTP atteikums notiek pēc tam, kad TCP savienojums sasniedz NGINX. Tas papildina tīkla ierobežojumu, un pašas lietojumprogrammas autorizācija joprojām attiecas uz katru lietotāju.

Pārbaudiet dzīvo ceļu un kļūmes gadījumu

Palaidiet konfigurācijas analizatoru, pārbaudiet klausošās ligzdas, pēc tam veiciet jaunu nosauktu pieprasījumu no paredzēta klienta. Apstipriniet, ka sertifikāts validējas, DNS nosaukums atrisinās uz piesaistīto adresi un atbilde nāk no gaidītās saknes.

Pēc tam pārbaudiet izslēgtu avotu un alternatīvu ieeju. Strādājošs atļauts pieprasījums neko nepasaka par ceļiem, kurus gribējāt aizvērt, un tieši izslēgtajā pārbaudē parādās palicis klausītājs vai plaša ugunsmūra atļaušana.

Atkārtojiet startēšanas vai VPN atjaunošanas gadījumu. Ja NGINX startē pirms tuneļa adreses eksistences, piesaiste var neizdoties pat ar perfektu failu. Saskaņojiet adreses gatavību un pirms koplietota tīmekļa servera maiņas saglabājiet vietēju atjaunošanas ceļu.

Pierakstiet ligzdu, portu, avota diapazonu un HTTP sarakstu, kas izturēja. Nākamā VPN vai DNS izmaiņa var pārvietot jebkuru no tiem, un četras nosauktas vērtības ir vieglāk salīdzināt nekā strādājošu pārlūka cilni.