Qué revela una respuesta STUN cuando la VPN se ejecuta en el router

Cuando el túnel reside en el router, la máquina que ejecuta el navegador no tiene ninguna interfaz de túnel. Pídale a esa máquina sus direcciones locales y obtendrá una dirección privada de LAN y una de bucle, nada que se parezca a una dirección VPN. Aun así, un servidor STUN del otro lado todavía puede informar algo significativo sobre la ruta, y lo que informa depende por completo de cómo se enrutó y se tradujo esa solicitud concreta.

Esa es la parte que merece ir más despacio. «El navegador no posee la dirección VPN» responde a una pregunta sobre interfaces, mientras que una dirección reflejada es una respuesta sobre una ruta a través de la traducción. Confundir ambas produce conclusiones seguras sobre la divulgación que la evidencia no respalda.

Dos dispositivos, dos conjuntos de interfaces

En una configuración basada en router, el túnel termina en el router y el cliente de la LAN envía tráfico ordinario a su puerta de enlace predeterminada. La lista de interfaces del cliente sigue siendo corta: una dirección privada, quizá una segunda para otra red, y la de bucle. El riesgo no es que una de ellas resulte ser la dirección del túnel; es que la solicitud salga por una ruta que usted no eligió.

Pregunte al cliente qué ruta tomaría un destino concreto en lugar de preguntar qué interfaces existen. La respuesta nombra una puerta de enlace y la dirección de origen que usaría el núcleo, lo que ya es más informativo que cualquier inventario de direcciones.

ip route get 198.51.100.20
ip -6 route get 2001:db8::20
wg show wg0 allowed-ips

Los rangos de documentación son buenos destinos de prueba porque nunca se resuelven a un servicio real. Compare lo que dice el cliente con lo que dice el router, y trate cualquier discrepancia como prueba de que el enrutamiento por políticas, una regla de túnel dividido o una segunda ruta predeterminada está haciendo algo que usted no tuvo en cuenta.

Qué puede decir una respuesta Binding

RFC 8489 define la solicitud y la respuesta Binding, en las que el servidor informa de la dirección de transporte de origen que observó para esa solicitud. Es una afirmación sobre una quíntupla en un momento dado, no un censo de las interfaces del cliente. Por eso todo lo interesante ocurre entre el cliente y el punto de observación.

Ese hueco lo llenan el enrutamiento y la traducción. Un router que hace NAT de origen del tráfico saliente sustituye el origen privado del cliente por su propia dirección en la interfaz de salida. Si esa interfaz es el túnel, el reflector ve la dirección del túnel. Si el paquete quedó excluido del túnel, el reflector ve lo que produjo la traducción de la WAN. El mismo cliente, el mismo reflector, una respuesta distinta.

Tres casos que se parecen y no lo son

La distinción útil no es público frente a privado, sino qué punto de control trató el paquete. Trabaje los casos con las tablas del propio router abiertas, porque un solo navegador puede producir los tres según una regla que olvidó que había escrito.

Solo el segundo caso incumple el requisito de que cierto tráfico no salga nunca directamente, y solo el primero y el tercero revelan un identificador del lado del túnel. Ninguna de las tres filas es una afirmación sobre el comportamiento de un proveedor concreto: que se pueda alcanzar un reflector privado depende del enrutamiento, de las direcciones IP permitidas del otro extremo y de la política del cortafuegos en ambos extremos.

Tener una cuenta con el mismo proveedor no establece nada de eso. También conviene recordar que una solicitud enrutada puede conservar el origen de LAN del cliente si nada lo traduce, así que el campo de origen hay que rastrearlo en lugar de suponerlo a partir del diagrama de topología.

Recopilar no es seleccionar

WebRTC recopila direcciones candidatas para probar, y un candidato que aparece en una lista de diagnóstico puede no haber transportado nunca medios. Leer la lista como «esto es lo que aprendió el otro extremo» exagera la evidencia. El par seleccionado es el que transportó realmente la sesión, y vive en otro campo.

Un comprobador de salida HTTPS responde a otra pregunta: la dirección de origen que un servidor web vio para esa solicitud. Es una comprobación cruzada útil precisamente porque usa un protocolo distinto y a menudo un destino distinto que un reflector UDP, y la discrepancia entre ambos suele apuntar a una regla de enrutamiento más que a un fallo.

Decida la política y luego lea la respuesta

Escriba la intención antes de probar: qué tráfico debe usar el túnel, cuál puede salir directamente, qué familias de direcciones entran en el alcance y qué debe ocurrir cuando el túnel está caído. Sin esa línea base, toda observación es ambigua, porque no puede separar una fuga de una ruta que usted permitió deliberadamente.

Después haga una pregunta cada vez. Qué ruta toma este destino. Qué dirección informa este reflector. Qué par candidato seleccionó la sesión. Guarde las respuestas junto a la política y póngales fecha, porque una actualización de firmware puede cambiar el comportamiento predeterminado de formas que invalidan en silencio la conclusión del año pasado.

El router sigue siendo un punto de control sólido, porque ve tráfico que un cliente no puede eludir sin reconfigurarse a sí mismo. No es una promesa de que cada campo de cada protocolo de aplicación no revele nada, ni sustituye a escribir las rutas que decidió permitir.