Que revela unha resposta STUN cando a VPN se executa no router
O enderezo do túnel do router non é o enderezo local do navegador. Seguide como se encamiña e se traduce cada solicitude antes de ler o que informa un reflector.
Cando o túnel reside no router, a máquina que executa o navegador non ten ningunha interface de túnel. Pedídelle a esa máquina os seus enderezos locais e obteredes un enderezo privado de LAN e un de bucle, nada que se pareza a un enderezo VPN. Aínda así, un servidor STUN do outro lado pode informar algo significativo sobre a ruta, e o que informa depende por completo de como se encamiñou e traduciu esa solicitude concreta.
Esa é a parte que merece ir máis devagar. «O navegador non posúe o enderezo VPN» responde a unha pregunta sobre interfaces, mentres que un enderezo reflectido é unha resposta sobre unha ruta a través da tradución. Confundir ambas as dúas produce conclusións seguras sobre a divulgación que as probas non sosteñen.
Dous dispositivos, dous conxuntos de interfaces
Nunha configuración baseada en router, o túnel remata no router e o cliente da LAN envía tráfico ordinario á súa porta de enlace predeterminada. A lista de interfaces do cliente segue a ser curta: un enderezo privado, quizais un segundo para outra rede, e o de bucle. O risco non é que un deles resulte ser o enderezo do túnel; é que a solicitude saia por unha ruta que vostede non escolleu.
Preguntádelle ao cliente que ruta tomaría un destino concreto en lugar de preguntar que interfaces existen. A resposta nomea unha porta de enlace e o enderezo de orixe que usaría o núcleo, o que xa é máis informativo que calquera inventario de enderezos.
ip route get 198.51.100.20
ip -6 route get 2001:db8::20
wg show wg0 allowed-ipsOs rangos de documentación son boas destinacións de proba porque nunca se resolven nun servizo real. Comparade o que di o cliente co que di o router, e tratade calquera discrepancia como proba de que o encamiñamento por políticas, unha regra de túnel dividido ou unha segunda ruta predeterminada está a facer algo que non tivestes en conta.
Que pode dicir unha resposta Binding
RFC 8489 define a solicitude e a resposta Binding, nas que o servidor informa do enderezo de transporte de orixe que observou para esa solicitude. É unha afirmación sobre unha quíntupla nun momento dado, non un censo das interfaces do cliente. Por iso todo o interesante ocorre entre o cliente e o punto de observación.
Ese oco éncheno o encamiñamento e a tradución. Un router que fai NAT de orixe no tráfico saínte substitúe a orixe privada do cliente polo seu propio enderezo na interface de saída. Se esa interface é o túnel, o reflector ve o enderezo do túnel. Se o paquete quedou excluído do túnel, o reflector ve o que produciu a tradución da WAN. O mesmo cliente, o mesmo reflector, unha resposta distinta.
Tres casos que se parecen e non o son
A distinción útil non é público fronte a privado, senón que punto de control tratou o paquete. Traballade os casos coas táboas do propio router abertas, porque un só navegador pode producir os tres segundo unha regra que esquecestes que escribirades.
| Where the request leaves | What rewrites the source | What the reflector reports |
|---|---|---|
| Tunnel interface on the router | Router NAT towards the tunnel address | The tunnel address as seen on that path |
| WAN interface, excluded by policy | Ordinary WAN translation | The public WAN address |
| Private reflector reached through the tunnel route | Router NAT towards the tunnel address | An internal identifier valid only inside that path |
Só o segundo caso incumpre o requisito de que certo tráfico non saia nunca directamente, e só o primeiro e o terceiro revelan un identificador do lado do túnel. Ningunha das tres filas é unha afirmación sobre o comportamento dun provedor concreto: que se poida alcanzar un reflector privado depende do encamiñamento, dos enderezos IP permitidos do outro extremo e da política da devasa nos dous extremos.
Ter unha conta co mesmo provedor non estabelece nada diso. Tamén convén lembrar que unha solicitude encamiñada pode conservar a orixe de LAN do cliente se nada a traduce, así que o campo de orixe hai que rastrexalo en lugar de supoñelo a partir do diagrama de topoloxía.
Recompilar non é seleccionar
WebRTC recompila enderezos candidatos para probar, e un candidato que aparece nunha lista de diagnóstico pode non ter transportado nunca medios. Ler a lista como «isto é o que aprendeu o outro extremo» esaxera a proba. O par seleccionado é o que transportou realmente a sesión, e vive noutro campo.
Un comprobador de saída HTTPS responde a outra pregunta: o enderezo de orixe que viu un servidor web para esa solicitude. É unha comprobación cruzada útil precisamente porque usa un protocolo distinto e a miúdo un destino distinto que un reflector UDP, e a discrepancia entre ambos adoita apuntar a unha regra de encamiñamento máis que a un fallo.
Decidide a política e despois lede a resposta
Escribide a intención antes de probar: que tráfico debe usar o túnel, cal pode saír directamente, que familias de enderezos entran no alcance e que debe ocorrer cando o túnel está caído. Sen esa liña base, toda observación é ambigua, porque non podedes separar unha fuga dunha ruta que permitistes deliberadamente.
Despois facede unha pregunta cada vez. Que ruta toma este destino. Que enderezo informa este reflector. Que par candidato seleccionou a sesión. Gardade as respostas xunto á política e poñédelles data, porque unha actualización de firmware pode cambiar o comportamento predeterminado de xeitos que invalidan en silencio a conclusión do ano pasado.
O router segue a ser un punto de control sólido, porque ve tráfico que un cliente non pode evitar sen reconfigurarse a si mesmo. Non é unha promesa de que cada campo de cada protocolo de aplicación non revele nada, nin substitúe escribir as rutas que decidistes permitir.