Listen, Bind e BindSame en Tinyproxy: que enderezo gaña
Listen escolle o enderezo que acepta clientes, Bind escolle a orixe das conexións saíntes. Ningunha instala unha ruta, así que verifique o camiño pola súa conta.
O proxy responde, a petición complétase e, aínda así, o destino segue rexistrando o enderezo da LAN. Nada no rexistro do proxy parece erróneo, e a liña que cambiou é a que a documentación lle dixo que cambiase. Nun host con enderezo de LAN e enderezo de túnel, tres directivas deciden que enderezo aparece onde, e só unha trata o lado saínte. Se as le en orde incorrecta, acaba na táboa de rutas sen motivo.
O síntoma: o destino ve o enderezo da LAN
Un cliente conéctase ao proxy no enderezo da LAN, e o proxy abre a súa propia conexión cara ao destino. Esa segunda conexión escolle un enderezo de orixe segundo as regras do núcleo e, por defecto, é a que selecciona a consulta de ruta. Por iso o destino rexistra o enderezo primario do host aínda que cada byte pasou polo proxy. En canto a reenvío non hai nada roto, e por iso o rexistro do proxy non ten nada que dicir.
A imaxe inversa dese fallo é máis doada de ver: fixe a orixe saínte no enderezo do túnel e os clientes da LAN deixan de chegar ao receptor por completo. Esa versión anúnciase soa, mentres que a primeira se agocha tras unha petición que funciona. Ambas nacen de tratar unha directiva coma se respondese ás dúas preguntas.
Tres directivas, tres enderezos distintos
Listen nomea o enderezo local que acepta clientes do proxy. Bind fornece un enderezo de orixe para as conexións que o proxy fai cara a fóra, e BindSame dille que reutilice o enderezo local da conexión que acaba de aceptar. Son tres preguntas separadas e unha soa liña responde só a unha. Confundilas é a razón habitual de que un cambio pareza non facer nada.
| 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 |
Lea a configuración comentada que se entrega coa versión instalada, porque os valores por defecto e a sintaxe aceptada cambian entre versións. A configuración de exemplo do proxecto documenta cada directiva xunto ás demais. Compare ese ficheiro co do disco, non cunha guía escrita para outra distribución.
Configure o receptor e a orixe saínte de forma independente
Tome un host cuxo enderezo de LAN sexa 192.168.50.10 e cuxo enderezo de túnel sexa 10.90.0.3. Se os clientes da LAN deben chegar ao proxy mentres as súas peticións saen polo túnel, son dúas decisións independentes e ambas deben quedar escritas. O fragmento seguinte expresa exactamente iso e nada máis.
Listen 192.168.50.10
Bind 10.90.0.3
BindSame noNon é unha configuración completa, así que conserve o porto aprobado, a autenticación, os controis de acceso de clientes e as restricións de destino. Ambos os enderezos deben pertencer a este host dentro do espazo de nomes de rede de Tinyproxy, porque un valor de Bind que o proceso non pode posuír falla ao conectar, non ao arrincar. BindSame yes describe outra política, na que o enderezo local da conexión aceptada se converte na orixe saínte. Nas versións actuais esa rama ten prioridade sobre a lista Bind, e así é como unha orixe configurada desaparece sen erro.
Comprobe a ruta que implica a orixe
Escoller un enderezo de orixe non crea un camiño, así que pregunte ao núcleo que faría con esa orixe e ese destino. Unha consulta que nomea a interface do túnel é a evidencia mínima, e unha que nomea a interface da LAN significa que a orixe non pode funcionar tal como está escrita. A consulta é contextual: avalía as regras de política e a táboa vixentes para ese espazo de nomes. Non é unha conexión e non di nada sobre o que un NAT posterior presentará ao servizo.
ip -4 route get 203.0.113.25 from 10.90.0.3Use un enderezo de documentación no exemplo e substitúa o servizo que ten autorización para probar. Execute a consulta dentro do espazo de nomes do proxy cando o proxy vai nun contedor, porque as regras do host non son as que ve o proceso. Cando falte a ruta de túnel prevista, faga que o dono da rede a corrixa en lugar de engadir regras específicas de destino no host do proxy. Non borre rutas do host nin desactive as rutas que empuxa o servidor para que unha consulta saia ben, aínda que unha guía antiga o fixese, porque eses cambios moven todo o comportamento de VPN aprobado do host para reparar un só camiño do proxy.
Confirme a orixe no destino
Lea a orixe onde chega a petición, non onde sae. O rexistro da aplicación do destino, ou o dispositivo de borde que ten diante, anota o enderezo que realmente viu, mentres que o proxy só pode dicirlle que pretendía. Faga unha petición nova a través do receptor previsto despois do cambio, porque unha conexión en caché non demostra nada sobre a nova vinculación. Despois compare ese enderezo rexistrado co que configurou.
ss -ltnp | grep tinyproxy
curl -x http://192.168.50.10:8888 https://example.com -o /dev/null -sScurl só é o xerador de tráfico; o enderezo que merece verificación é o que rexistrou o lado remoto, non o par ao que curl se conectou por casualidade. Se ambos non coinciden, determine se a diferenza vén da selección de orixe ou dunha tradución máis adiante, porque iso corríxese en lugares distintos. Planifique os cambios de enderezo e os reinicios do proxy xuntos, porque vincular un enderezo que o túnel xa non ten falla en silencio tras unha reconexión. Defina tamén o comportamento de DNS e IPv6 por separado, porque o fragmento IPv4 anterior non demostra nada de ningún dos dous.