Listen, Bind y BindSame en Tinyproxy: qué dirección gana

El proxy responde, la petición se completa y, aun así, el destino sigue registrando la dirección de la LAN. Nada en el registro del proxy parece erróneo, y la línea que cambió es la que la documentación le dijo que cambiara. En un host con dirección de LAN y dirección de túnel, tres directivas deciden qué dirección aparece dónde, y solo una trata el lado saliente. Si las lee en el orden equivocado, acabará en la tabla de rutas sin motivo.

El síntoma: el destino ve la dirección de la LAN

Un cliente se conecta al proxy en la dirección de la LAN y el proxy abre su propia conexión hacia el destino. Esa segunda conexión elige una dirección de origen según las reglas del núcleo y, por defecto, es la que selecciona la consulta de ruta. Por eso el destino registra la dirección primaria del host aunque cada byte pasó por el proxy. En cuanto a reenvío no hay nada roto, y por eso el registro del proxy no tiene nada que decir.

La imagen inversa de ese fallo es más fácil de ver: fije el origen saliente en la dirección del túnel y los clientes de la LAN dejan de llegar al receptor por completo. Esa versión se anuncia sola, mientras que la primera se esconde tras una petición que funciona. Ambas nacen de tratar una directiva como si respondiera a las dos preguntas.

Tres directivas, tres direcciones distintas

Listen nombra la dirección local que acepta clientes del proxy. Bind aporta una dirección de origen para las conexiones que el proxy hace hacia fuera, y BindSame le dice que reutilice la dirección local de la conexión que acaba de aceptar. Son tres preguntas separadas y una sola línea responde solo a una. Confundirlas es la razón habitual de que un cambio parezca no hacer nada.

Lea la configuración comentada que se entrega con la versión instalada, porque los valores predeterminados y la sintaxis aceptada cambian entre versiones. La configuración de ejemplo del proyecto documenta cada directiva junto a las demás. Compare ese archivo con el del disco, no con una guía escrita para otra distribución.

Configure el receptor y el origen saliente de forma independiente

Tome un host cuya dirección de LAN sea 192.168.50.10 y cuya dirección de túnel sea 10.90.0.3. Si los clientes de la LAN deben llegar al proxy mientras sus peticiones salen por el túnel, son dos decisiones independientes y ambas deben quedar escritas. El fragmento siguiente expresa exactamente eso y nada más.

Listen 192.168.50.10
Bind 10.90.0.3
BindSame no

No es una configuración completa, así que conserve el puerto aprobado, la autenticación, los controles de acceso de clientes y las restricciones de destino. Ambas direcciones deben pertenecer a este host dentro del espacio de nombres de red de Tinyproxy, porque un valor de Bind que el proceso no puede poseer falla al conectar, no al arrancar. BindSame yes describe otra política, en la que la dirección local de la conexión aceptada se convierte en el origen saliente. En las versiones actuales esa rama tiene prioridad sobre la lista Bind, y así es como un origen configurado desaparece sin error.

Compruebe la ruta que implica el origen

Elegir una dirección de origen no crea un camino, así que pregunte al núcleo qué haría con ese origen y ese destino. Una consulta que nombre la interfaz del túnel es la evidencia mínima, y una que nombre la interfaz de la LAN significa que el origen no puede funcionar tal como está escrito. La consulta es contextual: evalúa las reglas de política y la tabla vigentes para ese espacio de nombres. No es una conexión y no dice nada sobre lo que un NAT posterior presentará al servicio.

ip -4 route get 203.0.113.25 from 10.90.0.3

Use una dirección de documentación en el ejemplo y sustituya el servicio que tiene autorización para probar. Ejecute la consulta dentro del espacio de nombres del proxy cuando el proxy va en un contenedor, porque las reglas del host no son las que ve el proceso. Cuando falte la ruta de túnel prevista, haga que el dueño de la red la corrija en lugar de añadir reglas específicas de destino al host del proxy. No borre rutas del host ni desactive las rutas que empuja el servidor para que una consulta salga bien, aunque una guía antigua lo hiciera, porque esos cambios mueven todo el comportamiento de VPN aprobado del host para reparar un solo camino del proxy.

Confirme el origen en el destino

Lea el origen donde llega la petición, no donde sale. El registro de la aplicación del destino, o el dispositivo de borde que tiene delante, anota la dirección que realmente vio, mientras que el proxy solo puede decirle qué pretendía. Haga una petición nueva a través del receptor previsto después del cambio, porque una conexión en caché no demuestra nada sobre la nueva vinculación. Luego compare esa dirección registrada con la que configuró.

ss -ltnp | grep tinyproxy
curl -x http://192.168.50.10:8888 https://example.com -o /dev/null -sS

curl solo es el generador de tráfico; la dirección que merece verificación es la que registró el lado remoto, no el par al que curl se conectó por casualidad. Si ambas no coinciden, determine si la diferencia viene de la selección de origen o de una traducción más adelante, porque eso se corrige en lugares distintos. Planifique los cambios de dirección y los reinicios del proxy juntos, porque vincular una dirección que el túnel ya no tiene falla en silencio tras una reconexión. Defina también el comportamiento de DNS e IPv6 por separado, porque el fragmento IPv4 anterior no demuestra nada de ninguno de los dos.