VPN soilik NGINX gunea: entzulea, suebakia eta HTTP baimen zerrenda
NGINX gune pribatu batek VPN socket lotua, ostalari sarrerako arau mugatua eta HTTP sarbide zerrenda osoa behar ditu. Probatu hirurak, ez zerbitzari bloke bat soilik.
Hiru erabaki independente daude gune pribatu baten eta interneten artean: zein socketek onartzen duen konexioa, zein bidek eman dezakeen eta hautatutako zerbitzariak zein HTTP bezerori erantzuten dien. Zerbitzari bloke batek lehen erabakia baino ez du hartzen. Tratatu beste biak kontrol bereizi gisa, bestela gunea pribatua emango du eta sarrera zaharra irekita geratuko da. VPN soilik NGINX hutsegite gehienak lehen geruza soilik probatetik datoz.
Adibideak Linux OpenVPN ate bat erabiltzen du 10.90.0.1 helbidean tun0-n, bezeroak 10.90.0.0/24-n, iturri gordetakoak eta sarrera honetarako gordetako TCP 8443. Egokitu balioak, mantendu geruzak.
Hasi socketarekin, ez ostalari izenarekin
Lotu HTTPS entzulea tunel helbidera eta portu dedikatu batera. Helbide zehatz bat errazagoa da pentsatzeko komodin socket bat gehi izen egiaztapena baino, kernelak ez baitio portua beste helbide lokal bati emango.
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;
}
}
Ziurtagiriak bezeroek idazten duten zerbitzu ostalariaren izena izan behar du, eta DNS ikuspegi pribatuak ostalari hori lotutako helbidera ebatzi behar du. server_name-ek ostalari birtual bat baino ez du hautatzen; ez du inor autentifikatzen. DNS erregistro bat falta bada TLS hutsegite baten antza duen ziurtagiri errorea sortzen da. Egiaztatu izena ziurtagiria ordezkatu aurretik.
Irakurri konfigurazio eraginkorra fitxategia gehitu aurretik. Inklusioek eta komodin entzuleek erro bera beste leku batean zerbitza dezakete, eta lehenetsitako zerbitzari batek bloke berriak inoiz ikusten ez dituen eskaerei erantzun diezaieke.
Itxi eduki horretarako beste entzule guztiak
Zerrendatu listen direktibak eta alderatu zerbitzatzen dituzten erroak. Beste aplikazio batentzat gehitutako bloke batek upstream berera proxya dezake, eta lehenetsitako zerbitzari zahar batek erantzuten jarrai dezake berria jarrita egon ondoren. Irteera hori da benetako inbentarioa, ez orain editatu duzun fitxategia. Alderatu eduki bera zerbitzatzen duen erro bakoitza.
sudo nginx -T | grep -n "listen\|server_name\|root\|proxy_pass"
Egiaztatu bi helbide familiak. IPv4 lotura batek IPv6 socket bat ukitu gabe uzten du, eta A erregistro berri batek ez du bide publiko batera oraindik seinalatzen duen AAAA erantzun zaharra erretiratzen.
Erretiratu ostalari birtual zaharra aldaketa bereizi gisa. Bloke berriaren biki publikoa kentzea da, normalean, sarrera benetan ixten duen urratsa; entzule pribatuak aurreikusitakoa baino ez du gehitzen.
Mugatu sarrerako bidea ostalarian
Entzuteko helbideak socketa mugatzen du, ez sarrera interfazea. Beste nonbaitetik helbide horretara bideratutako paketea tokiko sarrera gisa iristen da oraindik, beraz ostalariaren suebakiak bere adierazpena behar du konexioa nondik etor daitekeen. Horregatik lotura soil batek gutxitan betetzen du auditoria bat.
Sarrerako ukapen lehenetsitako politika batekin eta zerbitzu honetarako baimen zabalagorik gabe, arau mugatu batek tunela, iturri tartea, helburua eta portua batera izendatzen ditu:
sudo ufw allow in on tun0 proto tcp from 10.90.0.0/24 to 10.90.0.1 port 8443
Irakurri suebakiaren ordena eraginkorra aplikatu aurretik. Lehenagoko onarpen zabal batek murrizketa gaindi dezake, eta lehenagoko baztertze terminal batek baimen hau inoiz iristea eragotz dezake. Ez hustu erlaziorik gabeko arauak eta ez itzali suebakia adibidea egokitu dadin.
Arau hori ostalari sarrera da, ez beste LAN makina baterako bidea, eta atearen kanpoko OpenVPN entzulea zerbitzu bereizia izaten jarraitzen du. Gunea lehen publiko bazen, planifikatu sarrera zaharra nola erretiratzen den eta lehendik dauden saioak nola kudeatzen diren.
Mantendu HTTP zerrenda osoa kokalekuak aldatzen diren bitartean
NGINX-ek allow eta deny sarrerak ordenan ebaluatzen ditu, eta goiko zerbitzari mailako zerrendak deklaratutako multzoa onartzen du azken deny aurretik. Sarbide moduloak ere erregistratzen du edozein sarbide sarrera definitzen duen kokaleku batek bere zerrenda erabiltzen duela guraso zerrendaren ordez. Ordena sarrerek bezain garrantzitsua da.
Berrarazketa hori da ohiko erregresioa. Sarrera bat gehitzen duen karga, API edo osasun kokaleku berri batek isilka ordezkatzen du zerbitzari mailako murrizketa, eta gunea zabalagoa bihurtzen da azkenik gehitu den bidean.
Berrikusi kokaleku, alias eta bloke alternatibo bakoitza politika beraren parte gisa. IP egiaztapenak NGINX autentifikazioarekin konbinatzen badira, ulertu satisfy: any ezarpen batek bezero bat mekanismo batetik pasa dezake, bestea pasa gabe dagoen bitartean. Jarri sarbide zerrenda kokalekuen berrikuspen zerrendan.
HTTP ukapena TCP konexioa NGINX-era iritsi ondoren gertatzen da. Sare murrizketa osatzen du, eta aplikazioaren beraren baimenak erabiltzaile bakoitzari aplikatzen zaizkio oraindik.
Egiaztatu bide bizia eta hutsegite kasua
Exekutatu konfigurazio analizatzailea, ikuskatu entzuten ari diren socketak, eta egin gero izeneko eskaera berri bat aurreikusitako bezero batetik. Berretsi ziurtagiriak balio duela, DNS izenak lotutako helbidera ebazten duela eta erantzuna espero den errotik datorrela.
Probatu ondoren kanpo utzitako iturri bat eta sarrera alternatibo bat. Lanean ari den baimendutako eskaera batek ez du ezer esaten itxi nahi zenituen bideei buruz, eta kanpo utzitako proban agertzen da geratzen den entzule bat edo suebakiko onarpen zabal bat.
Errepikatu abiarazte edo VPN berreskuratze kasua. NGINX tunel helbidea existitu aurretik abiarazten bada, loturak huts egin dezake fitxategi perfektuarekin ere. Koordinatu helbidearen prestutasuna eta mantendu tokiko berreskuratze bide bat web zerbitzari partekatu bat aldatu aurretik.
Erregistratu pasa ziren socketa, portua, iturri tartea eta HTTP zerrenda. Hurrengo VPN edo DNS aldaketak edozein alda dezake, eta izendatutako lau balio errazago alderatzen dira funtzionatzen duen nabigatzaile fitxa bat baino.