Listen, Bind eta BindSame Tinyproxyn: zein helbidek irabazten du
Listenek bezeroak onartzen dituen helbidea aukeratzen du, Bindek irteerako konexioen iturria aukeratzen du. Biak ez dute ibilbiderik instalatzen, beraz egiaztatu bidea bere aldetik.
Proxyak erantzuten du, eskaera osatzen da, eta hala ere helmugak LAN helbidea erregistratzen du oraindik. Proxyaren erregistroan ezer ez dirudi oker, eta aldatu duzun lerroa dokumentazioak aldatzeko esan zizun berbera da. LAN helbidea eta tunel helbidea dituen ostalari batean, hiru direktibak erabakitzen dute zein helbide non agertzen den, eta horietako bat bakarrik da irteera aldeaz. Okerreko ordenan irakurtzen badituzu, arrazoirik gabe amaitzen duzu bideratze-taulan.
Sintoma: helmugak LAN helbidea ikusten du
Bezero bat LAN helbidean konektatzen da proxyarekin, eta proxyak bere konexioa irekitzen du helmugara. Bigarren konexio horrek iturburu helbidea nukleoaren arauen arabera aukeratzen du, eta lehenespenez bide-kontsultak hautatzen duena da. Beraz, helmugak ostalariaren helbide nagusia erregistratzen du, byte bakoitza proxytik igaro bazen ere. Birbidaltzearen aldetik ezer ez dago hautsita, eta horregatik proxyaren erregistroak ez du horri buruz esatekorik.
Akats horren ispilu-irudia errazago ikusten da: ainguratu irteerako iturburua tunel helbidera eta LAN bezeroek ez dute entzulea batere ukitzen. Bertsio hark bere burua iragartzen du, eta lehenengoak, berriz, funtzionatzen duen eskaera baten atzean ezkutatzen da. Biak datoz direktiba bat bi galderak erantzuten dituela balitz bezala tratatzetik.
Hiru direktiba, hiru helbide desberdin
Listenek proxy bezeroak onartzen dituen helbide lokala izendatzen du. Bindek kanporako proxyak egiten dituen konexioetarako iturburu helbidea ematen du, eta BindSamek orain dela gutxi onartutako konexioaren helbide lokala berrerabiltzeko agintzen dio. Hiru galdera bereizi dira, eta lerro bakar batek bat baino ez du erantzuten. Hauek nahastea da aldaketa ezer egiten ez duela emateko ohiko arrazoia.
| What you observe | Check first |
|---|---|
| A client cannot connect at all | Listen: the local address the listener binds |
| The request works but the far side logs the LAN address | Bind: the outgoing source is not being applied |
| A configured Bind appears to have no effect | BindSame yes: the accepted local address overrides the Bind list |
| The lookup names the LAN interface | The route, not the proxy: the source cannot reach that destination |
Irakurri instalatutako bertsioarekin datorren konfigurazio iruzkindua, lehenespenak eta onartutako sintaxia argitalpenen artean aldatzen direlako. Proiektuaren konfigurazio adibidea direktiba bakoitza besteekin batera dokumentatzen du. Alderatu fitxategi hori diskoan dagoenarekin, beste banaketa baterako idatzitako gida batekin ez.
Ezarri entzulea eta irteerako iturburua modu independentean
Hartu ostalari bat, LAN helbidea 192.168.50.10 eta tunel helbidea 10.90.0.3 dituena. LAN bezeroek proxyra iritsi behar badute eta haien eskaerek tuneletik irten, bi erabaki independente dira eta biak idatzi behar dira. Beheko zatiak zehazki hori adierazten du, ez besterik.
Listen 192.168.50.10
Bind 10.90.0.3
BindSame noHau ez da konfigurazio oso bat, beraz mantendu onartutako ataka, autentifikazioa, bezeroen sarbide-kontrolak eta helmuga-murrizketak. Bi helbideek ostalari honi pertenezu behar diote Tinyproxyren sare-izen-espazioaren barruan, prozesuak eduki ezin duen Bind balio batek konektatzean huts egiten duelako, ez abiaraztean. BindSame yes beste politika bat deskribatzen du: onartutako konexioaren helbide lokala irteerako iturburu bihurtzen da. Egungo argitalpenetan adar horrek Bind zerrendaren gaineko lehentasuna du, eta horrela desagertzen da konfiguratutako iturburua errorerik gabe.
Egiaztatu iturburuak inplikatzen duen ibilbidea
Iturburu helbidea aukeratzeak ez du biderik sortzen, beraz galdetu nukleoari zer egingo lukeen iturburu eta helmuga horiekin. Tunel interfazea aipatzen duen kontsulta da gutxieneko froga, eta LAN interfazea aipatzen duenak esan nahi du iturburua ezin dela idatzita dagoen bezala funtzionatu. Kontsulta testuingurukoa da: izen-espazio horretarako indarrean dauden politika-arauak eta taula ebaluatzen ditu. Ez da konexio bat, eta ez du ezer esaten beheragoko NAT batek zerbitzuari zer aurkeztuko dion.
ip -4 route get 203.0.113.25 from 10.90.0.3Erabili dokumentazio helbide bat adibidean eta ordeztu probatzeko baimena duzun zerbitzua. Exekutatu kontsulta proxyaren izen-espazioaren barruan proxyak edukiontzian funtzionatzen duenean, ostalariaren arauak ez direlako prozesuak ikusten dituen arauak. Aurreikusitako tunel ibilbidea falta denean, utzi sarearen jabea hura konpontzen, proxy ostalarian helmuga zehatzeko arauak gehitu beharrean. Ez garbitu ostalariaren ibilbideak eta ez desgaitu zerbitzariak bultzatutako ibilbideak kontsulta bat lortzeko, gida zaharrago batek hala egin bazuen ere, aldaketa horiek ostalariaren VPN portaera onartu osoa lekuz aldatzen dutelako proxy bide bat konpontzeko.
Egiaztatu iturburua helmugan
Irakurri iturburua eskaera iristen den tokian, ez nondik irteten den. Helmugaren aplikazioaren erregistroak edo haren aurreko ertz-gailuak benetan ikusi zuen helbidea idazten du, proxyak bere asmoa baino ezin dizu esan bitartean. Egin eskaera berri bat aurreikusitako entzulearen bidez aldaketaren ondoren, cachean dagoen konexioak ez baitu ezer frogatzen lotura berriari buruz. Gero alderatu erregistratutako helbidea konfiguratu duzunarekin.
ss -ltnp | grep tinyproxy
curl -x http://192.168.50.10:8888 https://example.com -o /dev/null -sScurl trafiko-sorgailua baino ez da; egiaztatzea merezi duen helbidea urruneko aldeak erregistratu zuena da, ez curl-ek ustekabean konektatu zuen bikotea. Biak bat ez badatoz, erabaki aldea iturburu-hautaketatik edo aurrerago egindako itzulketatik datorren, horiek toki desberdinetan konpontzen baitira. Planifikatu helbide-aldaketak eta proxyaren berrabiarazteak batera, tunelak jada ez duen helbide bat lotzeak isilik huts egiten baitu berrikonektatu ondoren. Definitu DNS eta IPv6 portaera bereiz ere, goiko IPv4 zatia ez baita bien artean ezer frogatzen.