Quale indirizzo sorgente vede STUN con un VPN sul router?
Route, scelta della sorgente e traduzione determinano l’indirizzo che un riflettore segnala. Tre fatti da annotare, poi una query per confermare quale percorso vince.
La domanda sembra un’unica consultazione ed è in realtà tre decisioni. Quale percorso prende la binding request, quale sorgente il kernel sceglie per quel percorso e se qualcosa lungo la strada riscrive quella sorgente. Cambia una delle tre e l’indirizzo che un server STUN segnala cambia con essa. Per questo dire che il VPN sta sul router non dice quasi nulla da solo.
La decisione si basa su tre fatti
Primo il percorso: regole di policy e tabella di routing decidono se la richiesta esce dal tunnel o dal WAN ordinario, e una destinazione esclusa prende il secondo percorso anche con un tunnel attivo. Secondo la sorgente: il kernel sceglie una sorgente per il percorso scelto, e quella scelta dipende dalla sorgente preferita del percorso e da ogni regola che ha corrisposto. Terzo la traduzione: NAT lungo la strada sostituisce la sorgente scelta. L’indirizzo riflesso è il prodotto di tutti e tre, non una proprietà del tunnel.
Cambia uno dei tre e la risposta cambia mentre ogni componente continua a sembrare sano nel proprio log. È il motivo abituale per cui questa diagnosi si blocca.
Annota i tre fatti per il flusso che stai testando prima di iniziare. Interfaccia, percorso e regola di traduzione bastano a prevedere il risultato, ed è proprio la previsione a rendere istruttiva una sorpresa. Se non riesci a compilare uno dei tre, quella lacuna è il vero risultato.
Seguire una binding request lungo il percorso
Una binding request STUN chiede a un server di segnalare l’indirizzo di trasporto sorgente che ha osservato. La risposta descrive il percorso seguito dalla richiesta, non un inventario delle interfacce sulla macchina client. Due richieste su due percorsi segnaleranno onestamente due indirizzi diversi.
| 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 |
Leggi quella tabella come un insieme di condizioni, non come un menu di fornitori. La riga centrale richiede che il riflettore privato sia raggiungibile sotto il routing e la policy dei peer del tunnel; è un fatto di configurazione che puoi verificare, non qualcosa che un livello di account implica. La riga in basso è di solito quella che conta per la policy, perché quel traffico doveva restare dentro il tunnel. Tra le due sta il caso ordinario, in cui l’uscita traduce e il riflettore vede solo l’uscita.
I candidati host e i candidati riflessivi lato server nascono da meccanismi diversi, quindi un elenco di candidati non dice quale percorso abbiano davvero usato i media. Leggi la coppia selezionata, non il log di raccolta, quando vuoi sapere dove è andata la sessione.
Che cosa non è l’indirizzo del tunnel del router
Un indirizzo di tunnel assegnato al router appartiene a un’interfaccia del router. Un browser su un host della LAN ha i propri indirizzi di interfaccia e nessuna vista diretta dell’interfaccia tunnel del router. Trattare i due come intercambiabili produce risposte sbagliate e sicure su ciò che una pagina web può apprendere.
L’inoltro è ciò che li collega. La richiesta attraversa il router come traffico instradato, e la sua sorgente è ciò che routing e traduzione hanno prodotto.
Se il percorso del tunnel conserva la sorgente LAN, un riflettore privato può apprendere quell’indirizzo LAN, il che è una divulgazione reale e diversa dall’indirizzo del tunnel. Se il percorso traduce verso l’indirizzo del tunnel, il riflettore apprende invece l’indirizzo del tunnel. Entrambi gli esiti sono compatibili con lo stesso browser sullo stesso host, ed è per questo che un’osservazione va legata a un flusso specifico. Chiedi al kernel quale sorgente userebbe prima di dare la colpa all’applicazione.
Divulgazione contro aggiramento: due risultati, due riparazioni
Un indirizzo di tunnel riflesso divulga un identificatore interno su un percorso che hai permesso. Una richiesta diretta sul WAN aggira un percorso che volevi imporre. Il primo è un problema di informazione, il secondo di applicazione delle regole, e si correggono in luoghi diversi. Fonderli in una sola parola produce una riparazione che non affronta né l’uno né l’altro.
WebRTC rende tutto questo più visibile senza renderlo sbagliato, dato che raccogliere un candidato non è la stessa cosa che selezionarlo.
ip route get 203.0.113.7 from 192.0.2.25
ip rule showEsegui la query di route per ogni indirizzo di riflettore che consenti, con la sorgente che quel flusso dovrebbe portare, poi eseguila di nuovo per gli intervalli esclusi per vedere che cosa seleziona il ripiego. Confronta le due risposte con la policy che hai annotato. Quando differiscono in un modo che non avevi previsto, hai trovato il punto di riparazione senza dover nemmeno interpretare l’elenco dei candidati di un browser.