Tinyproxy Listen, Bind en BindSame: watter adres wen
Listen kies die adres wat kliënte aanvaar, Bind kies die bron vir uitgaande verbindings. Nie een installeer ’n roete nie, so verifieer die pad op sy eie.
Die proxy antwoord, die versoek voltooi, en die bestemming teken steeds die LAN-adres aan. Niks in die proxy-logboek lyk verkeerd nie, en die reël wat jy verander het, is die een wat die dokumentasie gesê het jy moet verander. Op ’n gasheer met beide ’n LAN-adres en ’n tonneladres besluit drie riglyne watter adres waar verskyn, en net een daarvan gaan oor die uitgaande kant. Lees jy hulle in die verkeerde orde, beland jy sonder rede in die roetetabel.
Die simptoom: die bestemming sien die LAN-adres
’n Kliënt verbind met die proxy op die LAN-adres, en die proxy open sy eie verbinding na die bestemming. Daardie tweede verbinding kies ’n bronadres volgens die kernel se reëls, en by verstek is dit wat die roetesoektog kies. Die bestemming teken dus die gasheer se primêre adres aan, selfs al het elke byte deur die proxy gegaan. In die deurstuur-sin is niks fout nie, en daarom het die proxy-logboek niks daaroor te sê nie.
Die spieëlbeeld van daardie fout is makliker raak te sien: pen die uitgaande bron aan die tonneladres vas en LAN-kliënte bereik die luisteraar glad nie meer nie. Daardie weergawe kondig homself aan, terwyl die eerste een agter ’n werkende versoek wegkruip. Albei kom daarvan dat een riglyn behandel word asof dit albei vrae beantwoord.
Drie riglyne, drie verskillende adresse
Listen noem die plaaslike adres wat proxy-kliënte aanvaar. Bind gee ’n bronadres vir die verbindings wat die proxy na buite maak, en BindSame sê vir hom om die plaaslike adres van die verbinding wat hy pas aanvaar het, te hergebruik. Dit is drie aparte vrae, en ’n enkele reël beantwoord net een daarvan. Om hulle te verwar is die gewone rede waarom ’n verandering niks blyk te doen nie.
| 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 |
Lees die geannoteerde konfigurasie wat saam met die geïnstalleerde weergawe gelewer word, want verstekke en aanvaarde sintaks verander tussen weergawes. Die projek se voorbeeldkonfigurasie dokumenteer elke riglyn langs die ander. Vergelyk daardie lêer met die een op skyf, nie met ’n gids wat vir ’n ander verspreiding geskryf is nie.
Stel die luisteraar en die uitgaande bron onafhanklik in
Neem ’n gasheer met LAN-adres 192.168.50.10 en tonneladres 10.90.0.3. As LAN-kliënte die proxy moet bereik terwyl hul versoeke uit die tonnel vertrek, is dit twee onafhanklike besluite en albei moet neergeskryf word. Die fragment hier onder druk presies dit uit en niks anders nie.
Listen 192.168.50.10
Bind 10.90.0.3
BindSame noDit is nie ’n volledige konfigurasie nie, so behou die goedgekeurde poort, die verifikasie, die kliëntetoegangsbeheer en die bestemmingsbeperkings. Albei adresse moet aan hierdie gasheer behoort binne Tinyproxy se netwerknaamruimte, want ’n Bind-waarde wat die proses nie kan besit nie, faal by verbindingstyd eerder as by opstart. BindSame yes beskryf ’n ander beleid, waar die aanvaarde verbinding se plaaslike adres die uitgaande bron word. In huidige weergawes het daardie tak voorrang bo die Bind-lys, en dit is hoe ’n gekonfigureerde bron sonder ’n fout verdwyn.
Kontroleer die roete wat die bron impliseer
Om ’n bronadres te kies skep nie ’n pad nie, so vra die kernel wat hy met daardie bron en daardie bestemming sou doen. ’n Soektog wat die tonnelkoppelvlak noem, is die minimum bewys, en een wat die LAN-koppelvlak noem, beteken die bron kan nie werk soos geskryf nie. Die soektog is kontekstueel: dit evalueer die beleidsreëls en die tabel wat vir daardie naamruimte geld. Dit is nie ’n verbinding nie, en dit sê niks oor wat ’n stroomaf NAT aan die diens sal voorhou nie.
ip -4 route get 203.0.113.25 from 10.90.0.3Gebruik ’n dokumentasie-adres in die voorbeeld en vervang die diens wat jy gemagtig is om te toets. Voer die soektog binne die proxy se naamruimte uit wanneer die proxy in ’n houer loop, want die gasheer se reëls is nie die reëls wat die proses sien nie. Wanneer die beoogde tonnelroete ontbreek, laat die netwerkeienaar dit regmaak eerder as om bestemming-spesifieke reëls by die proxy-gasheer te voeg. Moenie gasheerroetes skoonmaak of bediener-gedrukte roetes deaktiveer om ’n soektog te laat slaag nie, selfs al het ’n ouer gids dit gedoen, want daardie veranderinge verskuif die hele gasheer se goedgekeurde VPN-gedrag om een proxy-pad te herstel.
Bevestig die bron by die bestemming
Lees die bron waar die versoek aankom, nie waar dit vertrek nie. Die bestemming se toepassinglogboek, of die randtoestel voor dit, teken die adres aan wat dit werklik gesien het, terwyl die proxy jou net kan sê wat hy bedoel het. Maak een nuwe versoek deur die beoogde luisteraar ná die verandering, want ’n gekasde verbinding bewys niks oor die nuwe binding nie. Vergelyk dan daardie aangetekende adres met die een wat jy gekonfigureer het.
ss -ltnp | grep tinyproxy
curl -x http://192.168.50.10:8888 https://example.com -o /dev/null -sSDie curl is net die verkeersgenerator; die adres wat werd is om te verifieer, is die een wat die ander kant aangeteken het, nie die eweknie waarmee curl toevallig verbind het nie. As die twee verskil, besluit of die verskil van bronkeuse of van verdere vertaling verderaan kom, want dié word op verskillende plekke reggemaak. Beplan adresveranderings en proxy-hervestartings ook saam, want om ’n adres te bind wat die tonnel nie meer het nie, misluk stil ná ’n herverbinding. Definieer DNS- en IPv6-gedrag ook apart, want die IPv4-fragment hierbo bewys niks oor enige van die twee nie.