Listen, Bind i BindSame a Tinyproxy: quina adreça guanya
Listen tria l’adreça que accepta clients, Bind tria la font de les connexions sortints. Cap de les dues instal·la una ruta, així que verifiqueu el camí pel seu compte.
El proxy respon, la petició es completa i, tot i això, la destinació continua registrant l’adreça de la LAN. Res del registre del proxy no sembla erroni, i la línia que heu canviat és la que la documentació us va dir de canviar. En un host amb adreça de LAN i adreça de túnel, tres directives decideixen quina adreça apareix on, i només una tracta el costat sortint. Llegir-les en l’ordre equivocat us porta a la taula d’encaminament sense cap motiu.
El símptoma: la destinació veu l’adreça de la LAN
Un client es connecta al proxy per l’adreça de la LAN, i el proxy obre la seva pròpia connexió cap a la destinació. Aquesta segona connexió tria una adreça d’origen segons les regles del nucli, i per defecte és la que selecciona la consulta de ruta. Per tant, la destinació registra l’adreça primària de l’host encara que cada byte hagi passat pel proxy. En termes de reenviament no hi ha res trencat, i per això el registre del proxy no té res a dir-ne.
La imatge inversa d’aquesta fallada és més fàcil de veure: fixeu l’origen sortint a l’adreça del túnel i els clients de la LAN deixen d’arribar al receptor del tot. Aquella versió s’anuncia sola, mentre que la primera s’amaga darrere d’una petició que funciona. Totes dues vénen de tractar una directiva com si respongués a les dues preguntes.
Tres directives, tres adreces diferents
Listen anomena l’adreça local que accepta els clients del proxy. Bind proporciona una adreça d’origen per a les connexions que el proxy fa cap enfora, i BindSame li diu que reutilitzi l’adreça local de la connexió que acaba d’acceptar. Són tres preguntes separades, i una sola línia només respon una. Barrejar-les és la raó habitual que un canvi sembli no fer res.
| 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 |
Llegiu la configuració anotada que s’inclou amb la versió instal·lada, perquè els valors per defecte i la sintaxi acceptada canvien entre versions. La configuració d’exemple del projecte documenta cada directiva al costat de les altres. Compareu aquell fitxer amb el del disc, no amb una guia escrita per a una altra distribució.
Definiu el receptor i l’origen sortint de manera independent
Agafeu un host amb adreça de LAN 192.168.50.10 i adreça de túnel 10.90.0.3. Si els clients de la LAN han d’arribar al proxy mentre les seves peticions surten pel túnel, són dues decisions independents i cal escriure-les totes dues. El fragment següent expressa exactament això i res més.
Listen 192.168.50.10
Bind 10.90.0.3
BindSame noNo és una configuració completa, així que conserveu el port aprovat, l’autenticació, els controls d’accés de clients i les restriccions de destinació. Les dues adreces han de pertànyer a aquest host dins de l’espai de noms de xarxa del Tinyproxy, perquè un valor de Bind que el procés no pot posseir falla en connectar, no en arrencar. BindSame yes descriu una política diferent, on l’adreça local de la connexió acceptada esdevé l’origen sortint. En les versions actuals aquesta branca té prioritat sobre la llista Bind, i així és com una font configurada desapareix sense cap error.
Comproveu la ruta que implica l’origen
Triar una adreça d’origen no crea cap camí, així que pregunteu al nucli què faria amb aquesta font i aquesta destinació. Una consulta que anomena la interfície del túnel és l’evidència mínima, i una que anomena la interfície de la LAN vol dir que la font no pot funcionar tal com està escrita. La consulta és contextual: avalua les regles de política i la taula vigents per a aquest espai de noms. No és una connexió, i no diu res sobre què presentarà un NAT posterior al servei.
ip -4 route get 203.0.113.25 from 10.90.0.3Feu servir una adreça de documentació a l’exemple i substituïu el servei que teniu autorització per provar. Executeu la consulta dins de l’espai de noms del proxy quan el proxy va en un contenidor, perquè les regles de l’host no són les que veu el procés. Quan falta la ruta de túnel prevista, feu que l’amo de la xarxa la corregeixi en lloc d’afegir regles específiques de destinació a l’host del proxy. No esborreu rutes de l’host ni desactiveu les rutes que empeny el servidor per fer que una consulta surti bé, encara que una guia antiga ho fes, perquè aquests canvis mouen tot el comportament de VPN aprovat de l’host per reparar un sol camí del proxy.
Confirmeu l’origen a la destinació
Llegiu l’origen on arriba la petició, no on marxa. El registre de l’aplicació de la destinació, o el dispositiu de vora que té davant, anota l’adreça que realment va veure, mentre que el proxy només us pot dir què pretenia. Feu una petició nova a través del receptor previst després del canvi, perquè una connexió en memòria cau no demostra res sobre la nova vinculació. Després compareu aquella adreça registrada amb la que heu configurat.
ss -ltnp | grep tinyproxy
curl -x http://192.168.50.10:8888 https://example.com -o /dev/null -sSEl curl només és el generador de trànsit; l’adreça que val la pena verificar és la que va registrar la banda remota, no el parell amb què curl va connectar per casualitat. Si les dues no coincideixen, decidiu si la diferència ve de la selecció d’origen o d’una traducció més endavant, perquè això es corregeix en llocs diferents. Planifiqueu els canvis d’adreça i els reinicis del proxy junts, perquè enllaçar una adreça que el túnel ja no té falla en silenci després d’una reconnexió. Definiu també el comportament de DNS i IPv6 per separat, perquè el fragment IPv4 anterior no demostra res de cap dels dos.