Que endereço de origem o STUN vê com uma VPN no router?
A rota, a seleção de origem e a tradução decidem o endereço que um refletor comunica. Três factos a anotar e depois uma consulta para confirmar que caminho vence.
A pergunta parece uma única consulta e na realidade são três decisões. Que rota toma a binding request, que origem o kernel escolhe para essa rota e se algo pelo caminho reescreve essa origem. Muda uma das três e o endereço que um servidor STUN comunica muda com ela. Por isso dizer que a VPN está no router não te diz quase nada por si só.
A decisão assenta em três factos
Primeiro a rota: regras de política e a tabela de rotas decidem se o pedido sai pelo túnel ou pela WAN normal, e um destino excluído toma o segundo caminho mesmo com um túnel ativo. Depois a origem: o kernel escolhe uma origem para a rota escolhida, e essa escolha depende da origem preferida da rota e de qualquer regra que tenha correspondido. Por fim a tradução: NAT pelo caminho substitui a origem escolhida. O endereço refletido é o produto das três, não uma propriedade do túnel.
Muda uma das três e a resposta muda enquanto cada componente continua a parecer saudável no seu próprio registo. É a razão habitual pela qual este diagnóstico encrava.
Anota os três factos para o fluxo que estás a testar antes de começar. Interface, rota e regra de tradução chegam para prever o resultado, e é precisamente a previsão que torna uma surpresa informativa. Se não conseguires preencher um dos três, essa lacuna é o achado real.
Seguir uma binding request ao longo do caminho
Uma binding request STUN pede a um servidor que comunique o endereço de transporte de origem que observou. A resposta descreve o caminho que o pedido tomou, não um inventário de interfaces na máquina cliente. Dois pedidos por dois caminhos comunicam honestamente dois endereços diferentes.
| 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 |
Lê essa tabela como um conjunto de condições, não como um menu de fornecedores. A linha do meio exige que o refletor privado esteja acessível sob o encaminhamento e a política de pares próprios do túnel; é um facto de configuração que podes verificar, não algo que um nível de conta implique. A linha de baixo é normalmente a que importa para a política, porque esse tráfego devia ter ficado dentro do túnel. Entre as duas está o caso comum, em que a saída traduz e o refletor só vê a saída.
Os candidatos host e os candidatos reflexivos do servidor vêm de mecanismos diferentes, por isso uma lista de candidatos não diz que caminho os media usaram de facto. Lê o par selecionado, não o registo de recolha, quando quiseres saber para onde foi a sessão.
O que o endereço de túnel do router não é
Um endereço de túnel atribuído ao router pertence a uma interface do router. Um navegador num host da LAN tem os seus próprios endereços de interface e nenhuma vista direta da interface de túnel do router. Tratar os dois como permutáveis produz respostas erradas e seguras sobre o que uma página web pode aprender.
O encaminhamento é o que os liga. O pedido atravessa o router como tráfego encaminhado, e a sua origem é o que o encaminhamento e a tradução produziram.
Se o caminho do túnel preservar a origem da LAN, um refletor privado pode aprender esse endereço de LAN, o que é uma divulgação real e diferente do endereço de túnel. Se o caminho traduzir para o endereço de túnel, o refletor aprende antes o endereço de túnel. Ambos os desfechos são compatíveis com o mesmo navegador no mesmo host, e é por isso que uma observação tem de estar ligada a um fluxo específico. Pergunta ao kernel que origem usaria antes de culpar a aplicação.
Divulgação versus contorno: dois achados, duas correções
Um endereço de túnel refletido divulga um identificador interno por um caminho que permitiste. Um pedido direto pela WAN contorna um caminho que querias exigir. O primeiro é uma questão de informação, o segundo de aplicação de regras, e corrigem-se em locais diferentes. Juntá-los numa só palavra produz uma correção que não resolve nenhum dos dois.
O WebRTC torna isto mais visível sem o tornar errado, pois recolher um candidato não é o mesmo que selecioná-lo.
ip route get 203.0.113.7 from 192.0.2.25
ip rule showExecuta a consulta de rota para cada endereço de refletor que permites, com a origem que esperas que esse fluxo transporte, e executa-a de novo para os intervalos excluídos para ver o que a alternativa seleciona. Compara as duas respostas com a política que anotaste. Quando diferirem de uma forma que não pretendias, encontraste o ponto de correção sem sequer precisares de interpretar a lista de candidatos de um navegador.