Què revela una resposta STUN quan la VPN funciona al router
L’adreça del túnel del router no és l’adreça local del navegador. Seguiu com es dirigeix i es tradueix cada petició abans de llegir què informa un reflector.
Quan el túnel viu al router, la màquina que executa el navegador no té cap interfície de túnel. Demaneu a aquesta màquina les seves adreces locals i obtindreu una adreça privada de LAN i una de bucle, res que s’assembli a una adreça VPN. I tot i així, un servidor STUN a l’altre costat encara pot informar d’alguna cosa significativa sobre el camí, i allò que informa depèn completament de com es va encaminar i traduir aquella petició concreta.
Aquesta és la part que val la pena aturar-se a mirar. «El navegador no posseeix l’adreça VPN» respon una pregunta sobre interfícies, mentre que una adreça reflectida és una resposta sobre un camí a través de la traducció. Confondre les dues coses produeix conclusions segures sobre la revelació que les proves no sostenen.
Dos dispositius, dos conjunts d’interfícies
En una configuració basada en router, el túnel acaba al router i el client de la LAN envia trànsit ordinari a la seva porta d’enllaç predeterminada. La llista d’interfícies del client es manté curta: una adreça privada, potser una segona per a una altra xarxa, i la de bucle. El risc no és que una d’elles sigui casualment l’adreça del túnel; és que la petició surti per un camí que no vau triar.
Pregunteu al client quin camí prendria una destinació concreta en lloc de preguntar quines interfícies existeixen. La resposta anomena una porta d’enllaç i l’adreça d’origen que el nucli faria servir, cosa que ja és més informativa que qualsevol inventari d’adreces.
ip route get 198.51.100.20
ip -6 route get 2001:db8::20
wg show wg0 allowed-ipsEls rangs de documentació són bones destinacions de prova perquè mai no es resolen en un servei real. Compareu què diu el client amb què diu el router, i tracteu qualsevol discrepància com a prova que l’encaminament per política, una regla de túnel dividit o una segona ruta predeterminada fa alguna cosa que no heu tingut en compte.
Què pot dir una resposta Binding
RFC 8489 defineix la petició i la resposta Binding, on el servidor informa de l’adreça de transport d’origen que va observar per a aquella petició. És una afirmació sobre una quíntupla en un moment, no un cens de les interfícies del client. Per tant, tot el que és interessant passa entre el client i el punt d’observació.
Aquest buit l’omplen l’encaminament i la traducció. Un router que fa NAT d’origen al trànsit de sortida substitueix l’origen privat del client per la seva pròpia adreça a la interfície de sortida. Si aquesta interfície és el túnel, el reflector veu l’adreça del túnel. Si el paquet queda exclòs del túnel, el reflector veu allò que ha produït la traducció de la WAN. Mateix client, mateix reflector, resposta diferent.
Tres casos que semblen iguals i no ho són
La distinció útil no és públic enfront de privat, sinó quin punt d’aplicació ha gestionat el paquet. Treballeu els casos amb les taules del router obertes, perquè un sol navegador pot produir els tres segons una regla que heu oblidat que vau escriure.
| 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 |
Només el segon cas incompleix el requisit que cert trànsit no surti mai directament, i només el primer i el tercer revelen un identificador del costat del túnel. Cap de les tres files no és una afirmació sobre el comportament d’un proveïdor concret: si un reflector privat és abastable depèn de l’encaminament, de les adreces IP permeses de l’altre extrem i de la política del tallafoc als dos caps.
Tenir un compte amb el mateix proveïdor no estableix res d’això. També val la pena recordar que una petició encaminada pot conservar l’origen de LAN del client si res no el tradueix, així que el camp d’origen s’ha de traçar en lloc de suposar-lo a partir del diagrama de topologia.
Recollir no és seleccionar
WebRTC recull adreces candidates per provar, i un candidat que apareix en una llista de diagnòstic pot no haver transportat mai mitjans. Llegir la llista com «això és el que ha après l’altre extrem» exagera les proves. La parella seleccionada és la que va transportar realment la sessió, i viu en un altre camp.
Un comprovador de sortida HTTPS respon encara una altra pregunta: l’adreça d’origen que un servidor web va veure per a aquella petició. És una comprovació creuada útil precisament perquè fa servir un protocol diferent i sovint una destinació diferent de la d’un reflector UDP, i la discrepància entre tots dos sol assenyalar una regla d’encaminament més que un error.
Decidiu la política i després llegiu la resposta
Escriviu la intenció abans de provar: quin trànsit ha d’usar el túnel, quin pot sortir directament, quines famílies d’adreces entren en abast i què ha de passar quan el túnel està caigut. Sense aquesta línia base, cada observació és ambigua, perquè no podeu separar una fuita d’un camí que heu permès deliberadament.
Després feu una pregunta alhora. Quin camí pren aquesta destinació. Quina adreça informa aquest reflector. Quina parella candidata ha seleccionat la sessió. Guardeu les respostes al costat de la política i dateu-les, perquè una actualització de firmware pot canviar el comportament predeterminat de maneres que invaliden silenciosament la conclusió de l’any passat.
El router continua sent un punt d’aplicació fort, perquè veu trànsit que un client no pot evitar sense reconfigurar-se a si mateix. No és una promesa que cada camp de cada protocol d’aplicació no reveli res, ni substitueix escriure els camins que heu decidit permetre.