Redsocks loopbackean entzuten du, baina VPN trafikoa ez da inoiz iristen
Loopbackera soilik lotutako entzuleak ez du inoiz tun0-tik birbideratutako trafikoa ikusten. Irakurri birbideratzearen helburua eta socketaren lotura, konpondu lotura, eta gero probatu benetako bezero batetik.
Tunel bat altxatzen da, bezeroak gatewaya pinga dezake, eta proxy bideko web eskaera guztiak hiltzen dira. redsocks prozesua martxan dago eta bere portua entzuten ari da, beraz zerbitzua osasuntsu dirudi gatewaytik bertatik. Huts egiten duena entrega urratsa da: tunelatik birbideratutako pakete bat ez da zuk abiatutako socketean lurreratzen. Lotura helbideak eta birbideratzearen helburuak bat etorri behar dute, eta normalean haietako bat bakarrik egiaztatzen da.
Nora lurreratzen da birbideratutako pakete bat benetan
Gateway batean proxy gardenak PREROUTING-en nat taulako REDIRECT erabiltzen du sarrerako konexio baten helmuga portu lokal batera berridazteko. Berridatzitako helmuga paketea iritsi zen interfazeak ikusten duen helbide lokala da, ez beste nonbait abiatutako prozesu baten loopback helbidea. 127.0.0.1-era soilik lotutako entzuleak hostean jada lokalak ziren konexioak onartzen ditu, eta hori da tunel trafikoak huts egiten duenean lanean jarraitzen duen kasua. Bezeroaren loopback propioa hirugarren helbidea da eta ez da inoiz gatewayaren arauaren helburua.
Beraz, goiko mailako kredentzialak ukitu aurretik, ezarri bi gertaera: arauak zein helbide lokaletara berridazten duen eta proxy socketaren zein helbideri lotuta dagoen.
Irakurri entzulea eta birbideratze araua elkarrekin
Inprimatu socket taula eta nat arauak pase berean, zeren inork ez duen portu batera seinalatzen duen arau bat helbide okerrekoa seinalatzen duen arauaren berdin-berdina dirudi. sudo ss -ltnp | grep redsocks lotura helbidea eta jabe den prozesua erakusten ditu. sudo iptables -t nat -S PREROUTING REDIRECT helburua erakusten du, eta sudo iptables -t nat -L PREROUTING -v -n harekin zerbait bat etorri den erakusten du.
REDSOCKS izeneko erabiltzaile kate batera jauzi egiteak ez du ezer lortzen katea existitzen ez bada eta aurreikusitako bazterketak eta REDIRECT ekintza ez badaramatza. Irakurri jauzi egiten duen katea sudo iptables -t nat -S REDSOCKS erabiliz, izenak lana egiten duela suposatu beharrean.
Gero konparatu bi balioak. Arauak 12345 portuko gateway helbide batera birbideratzen badu eta entzuleak 127.0.0.1:12345 jakinarazten badu, desadostasunak hutsaren azalpena ematen du diagnostiko gehigarririk gabe.
Lotu estu, eta gero mugatu zer irits daitekeen
Goiko mailako konfigurazio ereduak entzulea loopbackean jartzen du arrazoi onez: proxy gardenak hara irits daitekeen edonoren izenean onartzen ditu konexioak. Lotura 0.0.0.0-ra aldatzeak entrega konpontzen du eta aldi berean portua interfaze guztietan irekitzen du, eta hori segurtasun aldaketa da, ez konponketa neutroa. Nahiago lotu birbideratzeak helburu duen helbide lokal zehatzera, eta eduki portua itxita konfiantzazkoak ez diren interfazeetan. Lotura zabalagoa saihestezina bada, gehitu ostalariaren suebaki arau bat tunelaren iturburu barrutia eta gatewayaren bertako trafiko lokala soilik onartzen dituena.
Portua interfaze publikoan irekitzea ez da inoiz beharrezkoa birbideratutako VPN trafikoarentzat, konexioa berridazketaren ondoren tokian bertan amaitzen delako. Ez jarri proxya interneten erakusgai tokiko birbideratze bat funtziona dezan.
Froga ezazu bezero batetik datorren konexio berri batekin
Probatu benetako VPN bezero batetik TCP konexio berri batekin, ez gatewayko shell batetik. Bezeroan curl -sS -o /dev/null -w '%{http_code}\n' http://example.com birbideratutako bideak hasieratik amaierara arte probatzen du.
Gero baieztatu konfiantzazkoak ez den sare batetik entzulera zuzeneko konexioa oraindik ukatzen dela, eta proxyaren beraren goiko konexioa ez dela berriro arau berak harrapatzen. Harrapaketa errekurtsiboak bere buruarekin konektatzen den eta inoiz eskaera bat osatzen ez duen proxy gisa agertzen da. Gehitu proxyaren helmuga bazterketa multzora, edo markatu haren irteerako paketeak kateak saltatu ditzan.
Azkenik, gogoratu bide honek zer ez duen estaltzen. redsocksen ohiko TCP birbideratzeak ez ditu UDP, QUIC edo DNS SOCKS trafiko bihurtzen, eta helmuga pribatuek normalean bazterketa esplizituak behar dituzte. Tokiko proba arrakastatsu batek arazo izan ez zen loopback bidea bakarrik frogatzen du.