Quina adreça d'origen veu STUN amb una VPN al router?
La ruta, la selecció d'origen i la traducció decideixen l'adreça que informa un reflector. Tres fets per anotar i després una consulta per confirmar quin camí guanya.
La pregunta sembla una sola consulta i en realitat són tres decisions. Quina ruta pren la binding request, quin origen tria el nucli per a aquesta ruta i si alguna cosa pel camí reescriu aquest origen. Canvia'n una de les tres i l'adreça que informa un servidor STUN canvia amb ella. Per això dir que la VPN és al router no et diu gairebé res per si sol.
La decisió es recolza en tres fets
Primer la ruta: les regles de política i la taula d'encaminament decideixen si la petició surt pel túnel o per la WAN normal, i una destinació exclosa pren el segon camí fins i tot amb un túnel actiu. Segon l'origen: el nucli tria un origen per a la ruta escollida, i aquesta tria depèn de l'origen preferit de la ruta i de qualsevol regla que hi hagi coincidit. Tercer la traducció: NAT pel camí substitueix l'origen que s'hagi triat. L'adreça reflectida és el producte de les tres, no una propietat del túnel.
Canvia'n un dels tres i la resposta canvia mentre cada component continua semblant sa en el seu propi registre. És la raó habitual per la qual aquest diagnòstic s'encalla.
Anota els tres fets per al flux que estàs provant abans de començar. Interfície, ruta i regla de traducció són prou per predir el resultat, i és precisament la predicció que fa informativa una sorpresa. Si no pots omplir un dels tres, aquest buit és la troballa real.
Seguir una binding request al llarg del camí
Una binding request de STUN demana a un servidor que informi l'adreça de transport d'origen que ha observat. La resposta descriu el camí que ha pres la petició, no un inventari d'interfícies a la màquina client. Dues peticions per dos camins informaran honestament dues adreces diferents.
| 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 |
Llegeix aquesta taula com un conjunt de condicions, no com un menú de proveïdors. La fila del mig exigeix que el reflector privat sigui abastable sota l'encaminament i la política de parells propis del túnel; és un fet de configuració que pots verificar, no una cosa que impliqui un nivell de compte. La fila de baix sol ser la que importa per a la política, perquè aquell trànsit s'havia de quedar dins del túnel. Entre les dues hi ha el cas ordinari, en què la sortida tradueix i el reflector només veu la sortida.
Els candidats host i els candidats reflexius de servidor vénen de mecanismes diferents, així que una llista de candidats no diu quin camí van usar realment els mitjans. Llegeix la parella seleccionada, no el registre de recollida, quan vulguis saber on va anar la sessió.
Què no és l'adreça de túnel del router
Una adreça de túnel assignada al router pertany a una interfície del router. Un navegador en un host de la LAN té les seves pròpies adreces d'interfície i cap vista directa de la interfície de túnel del router. Tractar les dues com intercanviables produeix respostes errònies i segures sobre què pot aprendre una pàgina web.
El reenviament és el que les connecta. La petició travessa el router com a trànsit encaminat, i el seu origen és el que van produir l'encaminament i la traducció.
Si el camí del túnel conserva l'origen de la LAN, un reflector privat pot aprendre aquesta adreça de LAN, cosa que és una divulgació real i diferent de l'adreça de túnel. Si el camí tradueix cap a l'adreça de túnel, el reflector aprèn l'adreça de túnel en lloc seu. Tots dos resultats són compatibles amb el mateix navegador al mateix host, i per això una observació s'ha de lligar a un flux concret. Pregunta al nucli quin origen faria servir abans de culpar l'aplicació.
Divulgació contra elusió: dues troballes, dues reparacions
Una adreça de túnel reflectida divulga un identificador intern per un camí que has permès. Una petició directa per la WAN eludeix un camí que volies exigir. La primera és una qüestió d'informació, la segona d'aplicació de normes, i es corregeixen en llocs diferents. Fondre-les en una sola paraula produeix una reparació que no atén cap de les dues.
WebRTC fa això més visible sense fer-ho incorrecte, ja que recollir un candidat no és el mateix que seleccionar-lo.
ip route get 203.0.113.7 from 192.0.2.25
ip rule showExecuta la consulta de ruta per a cada adreça de reflector que permetis, amb l'origen que esperes que porti aquest flux, i torna-la a executar per als rangs exclosos per veure què selecciona el respatller. Compara les dues respostes amb la política que has anotat. Quan difereixin d'una manera que no volies, hauràs trobat el punt de reparació sense necessitat d'interpretar ni tan sols la llista de candidats d'un navegador.