Ainult VPN-ile mõeldud NGINX sait: kuulaja, tulemüür ja HTTP lubade loend

Privaatne NGINX sait vajab seotud VPN-pesa, piiratud hosti sisenemisreeglit ja tervet HTTP juurdepääsuloendit. Testige kõiki kolme, mitte ainult ühte serveriplokki.

Privaatse saidi ja interneti vahel on kolm sõltumatut otsust: milline pesa ühenduse vastu võtab, milline tee selle kohale toimetada võib ja millistele HTTP-klientidele valitud server vastab. Serveriplokk teeb ainult esimese otsuse. Käsitlege kahte ülejäänut eraldi juhtimisvahenditena, muidu näib sait privaatne, samal ajal kui vana sissepääs jääb avatuks. Enamik ainult VPN-ile mõeldud NGINX-i tõrkeid tuleneb ainult esimese kihi testimisest.

Näide kasutab Linuxi OpenVPN lüüsi aadressil 10.90.0.1 liidesel tun0, kliente aadressiruumis 10.90.0.0/24, säilitatud lähteid ja selle sissepääsu jaoks reserveeritud TCP 8443. Kohandage väärtusi, jätke kihid alles.

Alustage pesast, mitte hostinimest

Siduge HTTPS-kuulaja tunneliaadressi ja eraldi pordiga. Konkreetse aadressi üle on lihtsam mõelda kui metamärgiga pesa pluss nimekontroll, sest kernel ei anna porti teisele kohalikule aadressile.

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

Sertifikaat peab nimetama teenuse hostinime, mille kliendid sisestavad, ja privaatne DNS-vaade peab selle hosti seotud aadressile lahendama. server_name valib ainult virtuaalhosti; see ei autenti kedagi. Puuduv DNS-kirje tekitab sertifikaadivea, mis näeb välja nagu TLS-i rike. Kontrollige nime enne sertifikaadi asendamist.

Lugege kehtivat konfiguratsiooni enne faili lisamist. Kaasamised ja metamärgiga kuulajad võivad sama juurt mujal teenindada ning vaikeserver võib vastata päringutele, mida uus plokk kunagi ei näe.

Sulgege kõik teised selle sisu kuulajad

Loetlege listen-direktiivid ja võrrelge juuri, mida need teenindavad. Teise rakenduse jaoks lisatud plokk võib edastada samale upstreamile ja vana vaikeserver võib jätkata vastamist ka pärast uue paigaldamist. See väljund on tegelik inventuur, mitte äsja muudetud fail. Võrrelge iga juurt, mis teenindab sama sisu.

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

Kontrollige mõlemat aadressiperekonda. IPv4 sidumine jätab IPv6 pesa puutumata ja uus A-kirje ei tühista vana AAAA-vastust, mis osutab endiselt avalikule teele.

Võtke vana virtuaalhost eraldi muudatusena kasutusest välja. Uue ploki avaliku kaksiku eemaldamine on tavaliselt samm, mis sissepääsu tegelikult sulgeb; privaatne kuulaja lisab ainult kavandatu.

Piirake sissetulev tee hosti juures

Kuulamisandress piirab pesa, mitte sissetulevat liidest. Mujalt sellele aadressile suunatud pakett saabub ikkagi kohaliku sisendina, seepärast vajab hosti tulemüür oma kinnitust selle kohta, kust ühendus tulla tohib. Seetõttu rahuldab ainult sidumine auditit harva.

Vaikimisi keelava sissetuleva poliitika ja selle teenuse jaoks laiema loata nimetab piiratud reegel tunnelit, lähtevahemikku, sihtkohta ja porti koos:

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

Lugege tulemüüri kehtivat järjekorda enne selle rakendamist. Varasem lai lubamine võib piirangu nurjata ja varasem lõplik kõrvalejätmine võib takistada selle loadeni jõudmist. Ärge tühjendage mitteseotud reegleid ega lülitage tulemüüri välja, et näide sobiks.

See reegel on hosti sisend, mitte marsruut teise LAN-masinani, ja lüüsi välimine OpenVPN-kuulaja jääb eraldi teenuseks. Kui sait oli varem avalik, planeerige, kuidas vana sissepääs kasutusest võetakse ja kuidas olemasolevaid sessioone käsitletakse.

Hoidke HTTP-loend tervena, kui asukohad muutuvad

NGINX hindab allow- ja deny-kirjeid järjekorras ning ülal serveritasandi loend lubab deklareeritud kogumi enne lõplikku deny-kirjet. Juurdepääsumoodul märgib ka, et asukoht, mis määratleb ükskõik millise juurdepääsukirje, kasutab oma loendit, mitte ülemloendit. Järjekord on sama oluline kui kirjed ise.

See lähtestamine on tavaline regressioon. Uus üleslaadimis-, API- või terviseasukoht, mis lisab ühe kirje, asendab vaikselt serveritasandi piirangu ja sait muutub laiemaks kõige hiljem lisatud teel.

Vaadake üle iga asukoht, aliash ja alternatiivne plokk sama poliitika osana. Kui IP-kontrolle kombineeritakse NGINX-i autentimisega, mõistke satisfy-d: any seade võib lasta kliendi ühest mehhanismist läbi, samal ajal kui teine pole läbinud. Pange juurdepääsuloend asukohtade ülevaatuse kontrollnimekirja.

HTTP keeldumine toimub pärast seda, kui TCP-ühendus jõuab NGINX-ini. See täiendab võrgupiirangut ja rakenduse enda autoriseerimine kehtib endiselt iga kasutaja kohta.

Kontrollige töötavat teed ja tõrkejuhtu

Käivitage konfiguratsioonianalüsaator, uurige kuulavaid pesasid ja tehke seejärel kavandatud kliendist värske nimeline päring. Kinnitage, et sertifikaat valideerub, DNS-i nimi lahendub seotud aadressile ja vastus tuleb oodatud juurest.

Järgmisena testige välistatud allikat ja alternatiivset sissepääsu. Töötav lubatud päring ei ütle midagi teede kohta, mille tahtsite sulgeda, ja just välistatud testis ilmub allesjäänud kuulaja või lai tulemüüri lubamine.

Korrake käivitamise või VPN-i taastamise juhtu. Kui NGINX käivitub enne, kui tunneliaadress on olemas, võib sidumine ebaõnnestuda ka täiusliku failiga. Koordineerige aadressi valmisolekut ja hoidke kohalikku taasteteed enne jagatud veebiserveri muutmist.

Registreerige pesa, port, lähtevahemik ja HTTP-loend, mis läbisid. Järgmine VPN-i või DNS-i muudatus võib mõnda neist liigutada ja nelja nimetatud väärtust on lihtsam võrrelda kui töötavat brauserikaarti.

Seotud artiklid