Site ng NGINX para sa VPN lamang: listener, firewall at listahan ng pahintulot sa HTTP

Tatlong malayang desisyon ang nasa pagitan ng pribadong site at ng internet: aling socket ang tumatanggap ng koneksyon, aling landas ang makapaghahatid nito, at aling mga kliyente ng HTTP ang sinasagot ng napiling server. Isang desisyon lamang ang ginagawa ng bloke ng server. Ituring ang dalawa pa bilang hiwalay na kontrol, kung hindi ay magmumukhang pribado ang site habang nakabukas pa ang lumang pasukan. Karamihan sa mga pagkabigo ng NGINX para sa VPN lamang ay nagmumula sa pagsubok lamang sa unang antas.

Ginagamit ng halimbawa ang gateway na Linux OpenVPN sa 10.90.0.1 sa tun0, mga kliyente sa 10.90.0.0/24, mga pinanatiling pinagmulan at TCP 8443 na nakalaan para sa pasukang ito. Ayusin ang mga halaga, panatilihin ang mga antas.

Magsimula sa socket, hindi sa pangalan ng host

Itali ang listener ng HTTPS sa address ng tunnel at sa nakalaang port. Mas madaling isipin ang partikular na address kaysa wildcard socket at pagsusuri ng pangalan, dahil hindi ibibigay ng kernel ang port sa ibang lokal na address.

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

Dapat ilagay ng sertipiko ang pangalan ng host ng serbisyo na tinatype ng mga kliyente, at dapat i-resolve ng pribadong view ng DNS ang host na iyon sa nakataling address. Pumipili lamang ang server_name ng virtual host; hindi nito pinapatunayan ang sinuman. Ang kulang na entry sa DNS ay gumagawa ng error sa sertipiko na mukhang sira ng TLS. Suriin ang pangalan bago palitan ang sertipiko.

Basahin ang epektibong configuration bago idagdag ang file. Maaaring maghatid ang mga include at wildcard listener ng parehong root sa ibang lugar, at maaaring sagutin ng default na server ang mga kahilingang hindi kailanman nakikita ng bagong bloke.

Isara ang bawat iba pang listener para sa nilalamang iyon

Ilista ang mga direktiba ng listen at ihambing ang mga root na hinahatiran nila. Ang blokeng idinagdag para sa ibang aplikasyon ay maaaring mag-proxy sa parehong upstream, at ang lumang default na server ay maaaring patuloy na sumagot pagkatapos mailagay ang bago. Ang output na iyon ang tunay na imbentaryo, hindi ang file na kaaayos mo lang. Ihambing ang bawat root na naghahatid ng parehong nilalaman.

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

Suriin ang dalawang pamilya ng address. Ang IPv4 binding ay nag-iiwan ng IPv6 socket na hindi ginalaw, at ang bagong A record ay hindi nag-aalis ng lumang AAAA na sagot na tumuturo pa rin sa pampublikong landas.

Alisin sa serbisyo ang lumang virtual host bilang hiwalay na pagbabago. Ang pagtanggal sa pampublikong kambal ng bagong bloke ang karaniwang hakbang na talagang nagsasara ng pasukan; ang pribadong listener ay nagdaragdag lamang ng nilalayon.

Limitahan ang saklaw ng papasok na landas sa host

Nililimitahan ng address ng pakikinig ang socket, hindi ang ingress interface. Ang packet na iruruta sa address na iyon mula sa ibang lugar ay dumarating pa rin bilang lokal na input, kaya kailangan ng firewall ng host ang sarili nitong pahayag tungkol sa pinanggalingan ng koneksyon. Kaya bihirang masapatan ng binding lamang ang isang audit.

Sa patakarang papasok na tanggihan bilang default at walang mas malawak na pahintulot para sa serbisyong ito, pinangalanan ng limitadong panuntunan ang tunnel, saklaw ng pinagmulan, destinasyon at port nang sama-sama:

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

Basahin ang epektibong pagkakasunod-sunod ng firewall bago ito ilapat. Maaaring talunin ng naunang malawak na pagtanggap ang paghihigpit, at maaaring hadlangan ng naunang terminal na pagtanggi ang pag-abot sa pahintulot na ito. Huwag linisin ang walang kaugnayang panuntunan at huwag patayin ang firewall para lamang umakma ang halimbawa.

Ang panuntunang iyon ay input ng host, hindi ruta patungo sa ibang makina sa LAN, at ang panlabas na listener ng OpenVPN ng gateway ay nananatiling hiwalay na serbisyo. Kung dating pampubliko ang site, planuhin kung paano aalisin sa serbisyo ang lumang pasukan at kung paano haharapin ang mga umiiral na sesyon.

Panatilihing buo ang listahan ng HTTP habang nagbabago ang mga lokasyon

Sinusuri ng NGINX ang mga entry ng allow at deny sa pagkakasunod-sunod, at ang listahan sa antas ng server sa itaas ay tumatanggap sa ipinahayag na pangkat bago ang huling deny. Itinatala rin ng access module na ang lokasyong naglilinaw ng anumang entry ng access ay gumagamit ng sarili nitong listahan kaysa sa magulang na listahan. Kasinghalaga ng mga entry mismo ang pagkakasunod-sunod.

Ang reset na iyon ang karaniwang regression. Ang bagong lokasyon ng upload, API o kalusugan na nagdaragdag ng isang entry ay tahimik na pumapalit sa paghihigpit sa antas ng server, at lumalawak ang site sa pinakahuling idinagdag na landas.

Suriin ang bawat lokasyon, alias at alternatibong bloke bilang bahagi ng parehong patakaran. Kung pinagsama ang mga pagsusuri ng IP sa pagpapatunay ng NGINX, unawain ang satisfy: ang setting na any ay maaaring magpapasok ng kliyente sa isang mekanismo habang ang isa ay hindi pa pumasa. Ilagay ang listahan ng access sa checklist ng pagsusuri ng lokasyon.

Ang pagtanggi sa HTTP ay nangyayari pagkatapos maabot ng koneksyon ng TCP ang NGINX. Dinadagdagan nito ang paghihigpit sa network, at ang sariling awtorisasyon ng aplikasyon ay nalalapat pa rin sa bawat gumagamit.

I-verify ang aktibong landas at ang kaso ng pagkabigo

Patakbuhin ang parser ng configuration, siyasatin ang mga socket na nakikinig, pagkatapos ay gumawa ng bagong pinangalanang kahilingan mula sa nilalayong kliyente. Kumpirmahin na nagva-validate ang sertipiko, nire-resolve ang pangalan ng DNS sa nakataling address at nagmumula ang sagot sa inaasahang root.

Pagkatapos ay subukan ang ibinukod na pinagmulan at alternatibong pasukan. Ang gumaganang pinahintulutang kahilingan ay walang sinasabi tungkol sa mga landas na gusto mong isara, at sa ibinukod na pagsubok lumilitaw ang natirang listener o malawak na pagtanggap ng firewall.

Ulitin ang kaso ng boot o pagbawi ng VPN. Kung magsisimula ang NGINX bago umiral ang address ng tunnel, maaaring mabigo ang binding kahit may perpektong file. I-coordinate ang kahandaan ng address at panatilihin ang lokal na landas ng pagbawi bago baguhin ang pinagsasaluhang web server.

Itala ang socket, port, saklaw ng pinagmulan at listahan ng HTTP na pumasa. Maaaring ilipat ng susunod na pagbabago sa VPN o DNS ang alinman sa mga ito, at ang apat na pinangalanang halaga ay mas madaling ihambing kaysa gumaganang tab ng browser.