Que revela unha lista de candidatos WebRTC sobre a túa VPN
Un candidato de host, reflexivo de servidor ou de retransmisión di de onde veu un enderezo. Só o par ICE seleccionado di que ruta usaron realmente os medios.
Cando unha páxina de proba WebRTC imprime 172.20.4.15, aprendeu que existe unha interface local nesa rede. Iso é unha revelación real e non é o mesmo achado que «os medios saíron pola saída da VPN». O descubrimento de candidatos e o encamiñamento de paquetes son mecanismos separados, e a maioría dos informes de fugas fusiónanos nun só veredicto. Cal dos dous estás mirando decide a solución.
A recollida ocorre antes de que se envía nada
O navegador enumera as interfaces locais, envía unha solicitude de vinculación a un servidor STUN e pide unha asignación a un servidor TURN, e despois escribe os resultados na descrición da sesión como liñas de candidatos. Todo iso remata sen chamada, sen medios e sen interlocutor. Unha lista de candidatos é, polo tanto, un rexistro do descubrimento, non do transporte.
Os navegadores modernos poden substituír o enderezo literal dun candidato de host por un nome mDNS .local, de xeito que a páxina non pode ler o IP privado. A rede local segue vendo as consultas de multidifusión que resolven ese nome, así que o enderezo ocúltase á aplicación en lugar de eliminarse do cable.
A orde tamén importa: unha carga nova da páxina recolle un conxunto novo, con outra asignación TURN e posiblemente outro mapado reflexivo. Dúas execucións que non coinciden non son necesariamente dúas configuracións distintas.
Tres tipos de candidatos, tres clases de probas
Cada liña procede dunha observación distinta. Cada tipo responde a unha pregunta distinta, e a táboa sepáraos polo que poden e non poden establecer.
| Candidate | Derived from | What it establishes | What it cannot establish |
|---|---|---|---|
| Host | An interface on the device | A local address exists in that network | That the peer can reach it |
| Server-reflexive | A STUN binding response | How a NAT mapped this source | Which exit the media will use |
| Peer-reflexive | A connectivity check that arrived | An address seen by the far side | That it was ever advertised |
| Relay | A TURN allocation | The relay server accepted the session | That the relay carries the call |
Un candidato de retransmisión confúndese habitualmente co enderezo de internet do usuario. Pertence ao servidor TURN, e a súa presenza mostra que había unha retransmisión dispoñible, non que o navegador a escollese. A mesma confusión vai en sentido contrario cos candidatos de host, onde un nome mDNS agocha o enderezo á páxina mentres a rede segue transportando as consultas. Le o tipo antes de ler o valor.
O par seleccionado responde á pregunta de encamiñamento
ICE emparexa cada candidato local con cada un remoto, executa comprobacións de conectividade sobre cada par e nomea un gañador. Ese par nomeado, visible nos diagnósticos do propio navegador, transporta os medios. Todo o demais da lista é unha posibilidade que perdeu.
O gañador diche a forma da ruta. De retransmisión a retransmisión pasa polo servidor TURN, un par de host queda na rede local e un par reflexivo de servidor vai directo por NAT. Ese é o feito que necesita unha comprobación de VPN, e é un feito distinto do da lista de enderezos. Dúas chamadas con listas de candidatos idénticas poden tomar pares diferentes.
Os candidatos non seleccionados recolléronse igualmente, e a recollida é tráfico de rede que sae da máquina. Unha chamada que ao final usou a retransmisión non significa que non se revelase nada mentres se construía a lista.
Os controis responden a obxectivos, non a unha puntuación de fugas
A especificación de xestión de IP de WebRTC describe varias políticas: usar só a interface que leva a ruta predeterminada, usar todas as interfaces e desactivar o UDP sen proxy para que o tráfico teña que pasar por unha retransmisión ou un proxy. Cada unha cambia conectividade e latencia por un tipo distinto de exposición. Cal implementa un navegador, e con que nome, varía segundo a plataforma e a versión.
Escolle a política segundo o obxectivo. Agochar os enderezos locais a unha páxina é un obxectivo; impedir o tráfico directo entre pares é outro; manter cada paquete dentro do túnel é un terceiro. O primeiro trata sobre todo do que aprende a aplicación, o segundo de que ruta se permite, e o terceiro debe impoñerse tamén no límite da plataforma ou da VPN.
Sexa cal sexa o control que escollas, verifica as dúas metades: executa a proba de recollida e anota os tipos de candidatos, e despois inspecciona o par seleccionado durante unha sesión real. Unha lista de enderezos limpa cunha ruta de medios directa segue sendo unha ruta que non querías.