Faqe NGINX vetëm për VPN: dëgjuesi, muri i zjarrit dhe lista e lejeve HTTP

Tre vendime të pavarura qëndrojnë midis një faqeje private dhe internetit: cili socket pranon lidhjen, cila rrugë mund ta dorëzojë dhe cilëve klientë HTTP u përgjigjet serveri i zgjedhur. Një bllok serveri merr vetëm vendimin e parë. Trajtoni dy të tjerët si kontrolle të veçanta, përndryshe faqja do të duket private ndërsa një hyrje e vjetër mbetet e hapur. Shumica e dështimeve të NGINX vetëm për VPN vijnë nga testimi i vetëm shtresës së parë.

Shembulli përdor një portal Linux OpenVPN në 10.90.0.1 në tun0, klientë në 10.90.0.0/24, burime të ruajtura dhe TCP 8443 të rezervuar për këtë hyrje. Përshtatni vlerat, mbani shtresat.

Filloni me socketin, jo me emrin e hostit

Lidhni dëgjuesin HTTPS me adresën e tunelit dhe një port të dedikuar. Një adresë e caktuar është më e lehtë për t'u menduar se një socket i përgjithshëm plus një kontroll emri, sepse kerneli nuk do ta japë portin te një adresë tjetër lokale.

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

Certifikata duhet të përmbajë emrin e hostit të shërbimit që shkruajnë klientët, dhe pamja private DNS duhet ta zgjidhë atë host në adresën e lidhur. server_name vetëm zgjedh një host virtual; nuk vërteton askënd. Një hyrje DNS që mungon prodhon një gabim certifikate që duket si defekt TLS. Kontrolloni emrin përpara se të zëvendësoni certifikatën.

Lexoni konfigurimin efektiv përpara se të shtoni skedarin. Përfshirjet dhe dëgjuesit e përgjithshëm mund të shërbejnë të njëjtën rrënjë diku tjetër, dhe një server i parazgjedhur mund t'u përgjigjet kërkesave që blloku i ri nuk i sheh kurrë.

Mbyllni çdo dëgjues tjetër për atë përmbajtje

Listoni direktivat listen dhe krahasoni rrënjët që shërbejnë. Një bllok i shtuar për një aplikacion tjetër mund të përfaqësojë te i njëjti upstream, dhe një server i vjetër i parazgjedhur mund të vazhdojë të përgjigjet pasi i riu është vendosur. Ai dalje është inventari i vërtetë, jo skedari që sapo redaktuat. Krahasoni çdo rrënjë që shërben të njëjtën përmbajtje.

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

Kontrolloni të dyja familjet e adresave. Një lidhje IPv4 e lë një socket IPv6 të paprekur, dhe një regjistrim i ri A nuk e tërheq një përgjigje të vjetër AAAA që ende tregon një rrugë publike.

Tërhiqni hostin e vjetër virtual si një ndryshim të veçantë. Heqja e binjakut publik të bllokut të ri është zakonisht hapi që vërtet mbyll hyrjen; dëgjuesi privat shton vetëm atë të synuar.

Kufizoni rrugën hyrëse në host

Adresa e dëgjimit kufizon socketin, jo ndërfaqen hyrëse. Një paketë e drejtuar në atë adresë nga diku tjetër arrin gjithsesi si hyrje lokale, prandaj muri i zjarrit i hostit ka nevojë për deklaratën e vet se nga mund të vijë lidhja. Prandaj një lidhje e vetme rrallë plotëson një auditim.

Me një politikë hyrëse refuzimi si parazgjedhje dhe pa një leje më të gjerë për këtë shërbim, një rregull i kufizuar emërton bashkë tunelin, intervalin e burimit, destinacionin dhe portin:

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

Lexoni rendin efektiv të murit të zjarrit përpara se ta zbatoni. Një pranim i gjerë i mëparshëm mund ta mundë kufizimin, dhe një hedhje përfundimtare e mëparshme mund të pengojë arritjen e kësaj lejeje. Mos i pastroni rregullat e palidhura dhe mos e fikni murin e zjarrit që shembulli të përshtatet.

Ai rregull është hyrje në host, jo një rrugë drejt një makine tjetër LAN, dhe dëgjuesi i jashtëm OpenVPN i portës mbetet një shërbim i veçantë. Nëse faqja ishte publike më parë, planifikoni si tërhiqet hyrja e vjetër dhe si trajtohen sesionet ekzistuese.

Mbani listën HTTP të paprekur ndërsa ndryshojnë vendndodhjet

NGINX vlerëson hyrjet allow dhe deny sipas radhës, dhe lista në nivel serveri më sipër lejon grupin e deklaruar përpara deny përfundimtar. Moduli i aksesit regjistron gjithashtu se një vendndodhje që përcakton çdo hyrje aksesi përdor listën e vet në vend të listës prindërore. Rendi ka po aq rëndësi sa vetë hyrjet.

Ai rivendosje është regresioni i zakonshëm. Një vendndodhje e re ngarkimi, API ose shëndeti që shton një hyrje zëvendëson në heshtje kufizimin në nivel serveri, dhe faqja bëhet më e gjerë në rrugën e shtuar më së fundmi.

Rishikoni çdo vendndodhje, alias dhe bllok alternativ si pjesë e të njëjtës politikë. Nëse kontrollet IP kombinohen me vërtetimin NGINX, kuptoni satisfy: një cilësim any mund të pranojë një klient përmes një mekanizmi ndërsa tjetri nuk ka kaluar. Vendosni listën e aksesit në listën e kontrollit të vendndodhjeve.

Një refuzim HTTP ndodh pasi lidhja TCP arrin NGINX. Ai plotëson kufizimin e rrjetit, dhe autorizimi i vetë aplikacionit vazhdon të zbatohet për çdo përdorues.

Verifikoni rrugën e gjallë dhe rastin e dështimit

Ekzekutoni analizuesin e konfigurimit, inspektoni socketet që dëgjojnë, më pas bëni një kërkesë të re të emërtuar nga një klient i synuar. Konfirmoni që certifikata vërtetohet, emri DNS zgjidhet në adresën e lidhur dhe përgjigja vjen nga rrënja e pritur.

Më pas provoni një burim të përjashtuar dhe një hyrje alternative. Një kërkesë e lejuar që funksionon nuk thotë asgjë për rrugët që donit të mbyllnit, dhe është në testin e përjashtuar që shfaqet një dëgjues i mbetur ose një pranim i gjerë i murit të zjarrit.

Përsëritni rastin e nisjes ose të rikuperimit VPN. Nëse NGINX niset përpara se të ekzistojë adresa e tunelit, lidhja mund të dështojë edhe me një skedar të përsosur. Koordinoni gatishmërinë e adresës dhe mbani një rrugë rikuperimi lokale përpara se të ndryshoni një server web të përbashkët.

Regjistroni socketin, portin, intervalin e burimit dhe listën HTTP që kaluan. Ndryshimi i ardhshëm VPN ose DNS mund të lëvizë cilindo prej tyre, dhe katër vlera të emërtuara janë më të lehta për t'u krahasuar sesa një skedë shfletuesi që funksionon.