Zein iturburu-helbide erregistratuko du NGINXek VPN bezeroarentzat?

Erabaki zer ikusten duen NGINXek OpenVPNren ondoan host berean: tunelaren barne-helbidea, irteera publikoaren helbidea edo birbidalitako pare bat, hartutako bidearen arabera.

Hiru bezero-helbide agertzen dira host bereko NGINX eta OpenVPN instalazio batean, eskaerak har dezakeen bide bakoitzeko bat. Tunelaren helbidera iristen den nabigatzaile bat, helbide publikora iristen den nabigatzaile bat eta atebidearen internet-bidetik irteten den programa bat desberdinak dira entzuten ari den socketan. Interpretatu aurretik erabaki zein bide ari zaren ikusten. Erabakia bezeroak erabili zuen helmugaren, kanpoko VPN muturrerako duen salbuespenaren eta bidean paketea itzultzen duen ezeren araberakoa da.

Erabaki helmugaren arabera, ez erabiltzailea nor den

Hasi eskaera bidali zen helbidearekin, helbide horrek hautatzen baitu bidea. Hosten tunel-helbiderako eskaera tunel-interfazean iristen da bezeroaren barne-helbidea iturri duela. Hosten helbide publikorako eskaera normalean internet aldera dagoen interfazean iristen da bezeroaren helbide publikoarekin, nahiz eta ordenagailu berak une horretan tunela ezarrita izan. Beraz, VPN igerilekukoa izatea paketearen bidearen ezaugarria da, ez erabiltzaileari jarraitzen dion ezaugarria.

Path the request tookSource the site normally records
Client reaches the site at its tunnel address, 10.24.0.1Client inner address, 10.24.0.20
Client reaches another internet site through the gatewayGateway public egress address, 192.0.2.44
Client reaches the gateway's public address through the endpoint exceptionClient's own public access address

Hirugarren errenkada hori da lehenengo egiaztatzeko merezi duena VPN erabiltzaile bat erregistroan agertzen denean tunelarekin zerikusirik ez duen helbide batekin. Honek ere azaltzen du zergatik sortu ditzaketen profil bereko bi erabiltzailek sarrera desberdinak: haien sarbide-sareak desberdinak dira eta tunelak ez du hori gainidazten.

Zergatik sortzen duen kanpoko muturrak bigarren bide publiko bat

Bezeroak atebidearen helbide publikora iritsi behar du tunela ezartzeko, beraz helbide horretarako ibilbide bat tunelatik kanpo egon behar da. Bezeroak trafiko guztia barrurantz birbideratzen duenean, inplementazio zentzuzko batek host-ibilbide esplizitua gordetzen du zerbitzariaren helbide publikorako, bere buruaren menpe dagoen tunel bat saihesteko. Salbuespen hori ez da zerbitzuen araberakoa, beraz helbide berberarako edozein eskaerak jarraitzen du, atebidean ostatatutako gune baterako nabigatzaile-eskaera barne.

Hau da arlo honetako txosten nahasgarrienen atzean dagoen mekanismoa, eta bezeroaren inplementazioaren araberakoa da, ez zerbitzariaren araberakoa. Beraz, profil berberak dituzten bi bezerok modu desberdinean joka dezakete. Erregistroa »konpontzeko« salbuespena kentzeak tunela ere botatzen du, beraz mantendu eta horren inguruan diseinatu.

Irakurri socket-a, taula eta erregistro-formatuak batera

Hiru behaketak argitzen dute zein bide ari zaren ikusten: non entzuten duen socket-ak, zein interfazek erantzuten dion helmugari eta zer erregistratzen duen erregistro-formatuak benetan. Entzulea tunel-helbidera soilik lotuta badago, eskaera publiko batek ezin du hara iritsi, eta horrek bi errenkada baztertzen ditu berehala. Bezeroaren bilaketak tunel-gailua itzultzen badu, eskaera barne-iturri batekin iritsi da eta erregistroak hori erakutsi behar luke.

ss -lntp 'sport = :443'
ip route get 10.24.0.20
ip route get 192.0.2.44

Ondoren irakurri formatua, ez lerroa. Birbidalitako goiburu batek elikatzen duen eremuak baieztapen bat erregistratzen du, ez socket-aren pare bat, eta baieztapenak bakarrik du garrantzia berehalako parea proxy fidagarria denean. Bi balioak erregistroan idazteak geroko eztabaidak konpontzen ditu, berehalako parea eta ordezkatutako helbidea gertaera desberdinak baitira eta horietako bat bakarrik etorri baitzen saretik.

log_format tunneled '$remote_addr $realip_remote_addr $request $status';
grep -n 'log_format' /etc/nginx/nginx.conf

Aukeratu nahi duzun sarrera-puntua eta jarri DNS ados

Gunea tunelaren bidezkoa bakarrik izan behar bada, eman iezaiozu VPN bezeroentzat tunel-helbidera ebazten duen izen bat eta aplikatu politika entzuten ari den socket-ean. Barne-izenarentzat 10.24.0.1 itzultzen duen split-DNS erantzun bat ibilbide-erabaki bat da, izen-ebazpenaren xehetasun baten mozorroan. Gunea publikoa ere izan behar bada, mantendu bi izen edo bi portu eta utzi erregistroari esaten zeinek zerbitzatu zuen eskaera.

Baimen-arauak logika berari jarraitzen diote. Tunel-igerilekua baimentzeak ez du eskaera publiko bat baimenduko eta ez du barne-helbiderik beteko internetetik iritsitako konexio batean. Bi sarrera-puntu izen bakar baten pean nahasteak erregistratutako iturria bezeroaren ibilbidearen albo-ondorio bihurtzen du, diseinu-erabaki izan beharrean.

Egiaztatu bidea, gero politika

Berretsi bidea atebidean egindako harrapaketa batekin eta zuk kontrolatzen duzun eskaera batekin. Tunel-gailuan eta interfaze publikoan egindako harrapaketek erakusten dute zeinek eraman zituen byteak, eta paketeen ordenak esaten du haien artean itzulpenik gertatu zen.

tcpdump -ni tun0 port 443 -c 5
tcpdump -ni eth0 port 443 -c 5

Ondoren egiaztatu sarbidea bi norabideetan: aurreikusitako izendun sarrera aurreikusitako bezeroarentzat funtzionatzen du eta onartu gabeko bide publiko bat ukatzen da, ez da soilik motela izaten. IP-echo webgune orokor batek zerbait frogatzen du atebidearen internet-irteeraz eta ezer ez host bereko gune honetaz. Orri bat eta WebSocket bat bat ez datozenean, alderatu haien URLak, helbide-familiak eta DNS erantzunak zerbitzariaren konfigurazioa ukitu aurretik.

Erlazionatutako artikuluak