¿Qué dirección de origen ve STUN con una VPN en el router?
La ruta, la selección de origen y la traducción deciden la dirección que informa un reflector. Tres hechos que anotar y luego una consulta para confirmar qué camino gana.
La pregunta parece una sola consulta y en realidad son tres decisiones. Qué ruta toma la binding request, qué origen elige el kernel para esa ruta y si algo en el camino reescribe ese origen. Cambia una de las tres y la dirección que informa un servidor STUN cambia con ella. Por eso decir que la VPN está en el router no te dice casi nada por sí solo.
La decisión se apoya en tres hechos
Primero la ruta: las reglas de política y la tabla de rutas deciden si la petición sale por el túnel o por la WAN normal, y un destino excluido toma el segundo camino incluso con un túnel activo. Segundo el origen: el kernel elige un origen para la ruta escogida, y esa elección depende del origen preferido de la ruta y de cualquier regla que haya coincidido. Tercero la traducción: NAT en el camino sustituye el origen que se haya elegido. La dirección reflejada es el producto de las tres, no una propiedad del túnel.
Cambia uno de los tres y la respuesta cambia mientras cada componente sigue pareciendo sano en su propio registro. Es la razón habitual por la que este diagnóstico se atasca.
Anota los tres hechos para el flujo que estás probando antes de empezar. Interfaz, ruta y regla de traducción bastan para predecir el resultado, y precisamente la predicción es lo que hace informativa una sorpresa. Si no puedes rellenar uno de los tres, ese hueco es el hallazgo real.
Seguir una binding request a lo largo del camino
Una binding request de STUN pide a un servidor que informe la dirección de transporte de origen que observó. La respuesta describe el camino que tomó la petición, no un inventario de interfaces en la máquina cliente. Dos peticiones por dos caminos informarán honestamente dos direcciones distintas.
| Path taken | Source the reflector sees | What it means |
|---|---|---|
| Tunnel to a public exit that translates | The exit's public address | The reflector learns nothing about the LAN |
| Tunnel to a private reflector, translated to the tunnel address, no later translation | That tunnel address | An internal identifier is disclosed to that reflector |
| Excluded flow over the ordinary WAN | The WAN address | The tunnel was not used at all |
Lee esa tabla como un conjunto de condiciones, no como un menú de proveedores. La fila central exige que el reflector privado sea alcanzable bajo el enrutamiento y la política de pares propios del túnel; es un hecho de configuración que puedes verificar, no algo que implique un nivel de cuenta. La fila inferior suele ser la que importa para la política, porque ese tráfico debía quedarse dentro del túnel. Entre ambas está el caso ordinario, en el que la salida traduce y el reflector solo ve la salida.
Los candidatos host y los candidatos reflexivos de servidor vienen de mecanismos distintos, así que una lista de candidatos no dice qué camino usaron realmente los medios. Lee el par seleccionado, no el registro de recopilación, cuando quieras saber adónde fue la sesión.
Lo que no es la dirección de túnel del router
Una dirección de túnel asignada al router pertenece a una interfaz del router. Un navegador en un host de la LAN tiene sus propias direcciones de interfaz y ninguna vista directa de la interfaz de túnel del router. Tratar ambas como intercambiables produce respuestas erróneas y seguras sobre lo que una página web puede aprender.
El reenvío es lo que los conecta. La petición cruza el router como tráfico enrutado, y su origen es lo que produjeron el enrutamiento y la traducción.
Si el camino del túnel conserva el origen de la LAN, un reflector privado puede aprender esa dirección de LAN, lo cual es una divulgación real y distinta de la dirección de túnel. Si el camino traduce hacia la dirección de túnel, el reflector aprende la dirección de túnel en su lugar. Ambos resultados son compatibles con el mismo navegador en el mismo host, y por eso una observación debe ligarse a un flujo concreto. Pregunta al kernel qué origen usaría antes de culpar a la aplicación.
Divulgación frente a elusión: dos hallazgos, dos arreglos
Una dirección de túnel reflejada divulga un identificador interno por un camino que permitiste. Una petición directa por la WAN elude un camino que querías exigir. La primera es una cuestión de información, la segunda de aplicación de normas, y se corrigen en lugares distintos. Fundirlas en una sola palabra produce un arreglo que no atiende ninguna de las dos.
WebRTC hace esto más visible sin volverlo incorrecto, ya que recopilar un candidato no es lo mismo que seleccionarlo.
ip route get 203.0.113.7 from 192.0.2.25
ip rule showEjecuta la consulta de ruta para cada dirección de reflector que permitas, con el origen que esperas que lleve ese flujo, y vuelve a ejecutarla para los rangos excluidos para ver qué selecciona el respaldo. Compara las dos respuestas con la política que anotaste. Cuando difieran de una manera que no pretendías, habrás encontrado el punto de arreglo sin necesidad de interpretar siquiera la lista de candidatos de un navegador.