Cosa rivela un elenco di candidati WebRTC sul tuo VPN
Un candidato host, riflessivo lato server o relay dice da dove proviene un indirizzo. Solo la coppia ICE selezionata dice quale percorso hanno usato davvero i media.
Quando una pagina di test WebRTC stampa 172.20.4.15, ha appreso che su quella rete esiste un’interfaccia locale. È una divulgazione reale, e non è la stessa conclusione di «i media sono usciti dall’uscita VPN». La scoperta dei candidati e l’instradamento dei pacchetti sono meccanismi distinti, e la maggior parte dei rapporti sulle fughe li fonde in un unico verdetto. Quale dei due stai guardando decide la correzione.
La raccolta avviene prima che qualcosa venga inviato
Il browser enumera le interfacce locali, invia una richiesta di binding a un server STUN e chiede un’allocazione a un server TURN, poi scrive i risultati nella descrizione della sessione come righe di candidati. Tutto ciò si completa senza chiamata, senza media e senza interlocutore. Un elenco di candidati è quindi un verbale di scoperta, non di trasporto.
I browser moderni possono sostituire l’indirizzo letterale di un candidato host con un nome mDNS .local, così la pagina non può leggere l’IP privato. La rete locale vede ancora le query multicast che risolvono quel nome, quindi l’indirizzo è nascosto all’applicazione anziché rimosso dal cavo.
Anche l’ordine conta: un nuovo caricamento della pagina raccoglie un nuovo insieme, con un’altra allocazione TURN e forse un’altra mappatura riflessiva. Due esecuzioni che divergono non sono necessariamente due configurazioni diverse.
Tre tipi di candidati, tre tipi di prova
Ogni riga deriva da un’osservazione diversa. Ogni tipo risponde a una domanda diversa, e la tabella li separa in base a ciò che possono e non possono stabilire.
| 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 relay viene regolarmente confuso con l’indirizzo internet dell’utente. Appartiene al server TURN, e la sua presenza mostra che un relay era disponibile, non che il browser lo abbia scelto. La stessa confusione va in senso opposto con i candidati host, dove un nome mDNS nasconde l’indirizzo alla pagina mentre la rete trasporta ancora le query. Leggi il tipo prima di leggere il valore.
La coppia selezionata risponde alla domanda di instradamento
ICE accoppia ogni candidato locale con ogni candidato remoto, esegue controlli di connettività su ogni coppia e nomina un vincitore. Quella coppia nominata, visibile nella diagnostica del browser stesso, trasporta i media. Tutto il resto dell’elenco è una possibilità che ha perso.
Il vincitore ti dice la forma del percorso. Relay verso relay passa dal server TURN, una coppia host resta sulla rete locale e una coppia riflessiva lato server va diretta attraverso NAT. È il fatto che serve a un controllo VPN, ed è un fatto diverso dall’elenco degli indirizzi. Due chiamate con elenchi di candidati identici possono prendere coppie diverse.
I candidati non selezionati sono stati comunque raccolti, e la raccolta è traffico di rete che lascia la macchina. Una chiamata che alla fine ha usato il relay non significa che nulla sia stato divulgato mentre l’elenco veniva costruito.
I controlli corrispondono a obiettivi, non a un punteggio di fuga
La specifica WebRTC sulla gestione degli IP descrive diverse politiche: usare solo l’interfaccia che porta la rotta predefinita, usare tutte le interfacce e disattivare l’UDP non proxato in modo che il traffico debba passare per un relay o un proxy. Ognuna scambia connettività e latenza con un tipo diverso di esposizione. Quale un browser implementi, e con quale nome, varia per piattaforma e versione.
Scegli la politica in base all’obiettivo. Nascondere gli indirizzi locali a una pagina è un obiettivo; impedire il traffico diretto tra pari è un altro; tenere ogni pacchetto dentro il tunnel è un terzo. Il primo riguarda soprattutto ciò che l’applicazione apprende, il secondo quale percorso è consentito, e il terzo va imposto anche al confine della piattaforma o del VPN.
Qualunque controllo scegli, verifica entrambe le metà: esegui il test di raccolta e annota i tipi di candidati, poi ispeziona la coppia selezionata durante una sessione reale. Un elenco di indirizzi pulito con un percorso media diretto resta un percorso che non volevi.