Que enderezo de orixe ve STUN cunha VPN no router?
A ruta, a selección de orixe e a tradución deciden o enderezo que informa un reflector. Tres feitos para anotar e despois unha consulta para confirmar que camiño gaña.
A pregunta parece unha única consulta e en realidade son tres decisións. Que ruta toma a binding request, que orixe escolle o kernel para esa ruta e se algo polo camiño reescribe esa orixe. Cambia unha das tres e o enderezo que informa un servidor STUN cambia con ela. Por iso dicir que a VPN está no router non che di case nada por si só.
A decisión apóiase en tres feitos
Primeiro a ruta: as regras de política e a táboa de rutas deciden se a petición sae polo túnel ou pola WAN normal, e un destino excluído toma o segundo camiño mesmo cun túnel activo. Segundo a orixe: o kernel escolle unha orixe para a ruta escollida, e esa escolla depende da orixe preferida da ruta e de calquera regra que coincidise. Terceiro a tradución: NAT polo camiño substitúe a orixe escollida. O enderezo reflectido é o produto das tres, non unha propiedade do túnel.
Cambia un dos tres e a resposta cambia mentres cada compoñente segue parecendo san no seu propio rexistro. É a razón habitual pola que este diagnóstico se atasca.
Anota os tres feitos para o fluxo que estás probando antes de comezar. Interface, ruta e regra de tradución abondan para prever o resultado, e é precisamente a predición o que fai informativa unha sorpresa. Se non podes encher un dos tres, ese oco é o achado real.
Seguir unha binding request ao longo do camiño
Unha binding request de STUN pide a un servidor que informe o enderezo de transporte de orixe que observou. A resposta describe o camiño que tomou a petición, non un inventario de interfaces na máquina cliente. Dúas peticións por dous camiños informarán honestamente dous enderezos distintos.
| 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 |
Le esa táboa como un conxunto de condicións, non como un menú de provedores. A fila do medio esixe que o reflector privado sexa alcanzable baixo o encamiñamento e a política de pares propios do túnel; é un feito de configuración que podes verificar, non algo que implique un nivel de conta. A fila de abaixo adoita ser a que importa para a política, porque ese tráfico debía quedar dentro do túnel. Entre ambas está o caso común, no que a saída traduce e o reflector só ve a saída.
Os candidatos host e os candidatos reflexivos de servidor veñen de mecanismos distintos, así que unha lista de candidatos non di que camiño usaron realmente os medios. Le a parella seleccionada, non o rexistro de recollida, cando queiras saber onde foi a sesión.
O que non é o enderezo de túnel do router
Un enderezo de túnel asignado ao router pertence a unha interface do router. Un navegador nun host da LAN ten os seus propios enderezos de interface e ningunha vista directa da interface de túnel do router. Tratar os dous como intercambiables produce respostas erróneas e seguras sobre o que pode aprender unha páxina web.
O reenvío é o que os conecta. A petición atravesa o router como tráfico encamiñado, e a súa orixe é o que produciron o encamiñamento e a tradución.
Se o camiño do túnel conserva a orixe da LAN, un reflector privado pode aprender ese enderezo de LAN, o que é unha divulgación real e distinta do enderezo de túnel. Se o camiño traduce cara ao enderezo de túnel, o reflector aprende o enderezo de túnel no seu lugar. Ambos os resultados son compatibles co mesmo navegador no mesmo host, e por iso unha observación ten que ligarse a un fluxo concreto. Pregunta ao kernel que orixe usaría antes de culpar a aplicación.
Divulgación fronte a evasión: dous achados, dúas reparacións
Un enderezo de túnel reflectido divulga un identificador interno por un camiño que permitiches. Unha petición directa pola WAN evade un camiño que querías esixir. A primeira é unha cuestión de información, a segunda de aplicación de normas, e corrixen en lugares distintos. Fundilas nunha soa palabra produce unha reparación que non atende ningunha das dúas.
WebRTC fai isto máis visible sen facelo incorrecto, xa que recoller un candidato non é o mesmo que seleccionalo.
ip route get 203.0.113.7 from 192.0.2.25
ip rule showExecuta a consulta de ruta para cada enderezo de reflector que permitas, coa orixe que esperas que leve ese fluxo, e volve executala para os rangos excluídos para ver que selecciona o respaldo. Compara as dúas respostas coa política que anotaches. Cando difiran dunha maneira que non pretendías, terás atopado o punto de reparación sen necesidade de interpretar sequera a lista de candidatos dun navegador.