Che cosa rivela una risposta STUN quando la VPN gira sul router

Quando il tunnel vive sul router, la macchina che esegue il browser non ha alcuna interfaccia di tunnel. Chiedete a quella macchina i suoi indirizzi locali e otterrete un indirizzo LAN privato e uno di loopback, nulla che assomigli a un indirizzo VPN. Eppure un server STUN dall’altra parte può ancora riportare qualcosa di significativo sul percorso, e ciò che riporta dipende interamente da come quella specifica richiesta è stata instradata e tradotta.

È questa la parte su cui vale la pena rallentare. «Il browser non possiede l’indirizzo VPN» risponde a una domanda sulle interfacce, mentre un indirizzo riflesso è una risposta su un percorso attraverso la traduzione. Confondere le due cose produce conclusioni sicure sulla divulgazione che le prove non sostengono.

Due dispositivi, due insiemi di interfacce

In una configurazione basata su router il tunnel termina sul router e il client della LAN invia il traffico ordinario al proprio gateway predefinito. L’elenco delle interfacce del client resta corto: un indirizzo privato, forse un secondo per un’altra rete, e il loopback. Il rischio non è che uno di questi sia per caso l’indirizzo del tunnel; è che la richiesta esca per un percorso che non avete scelto.

Chiedete al client quale percorso prenderebbe una destinazione precisa invece di chiedere quali interfacce esistano. La risposta nomina un gateway e l’indirizzo di origine che il kernel userebbe, il che è già più informativo di qualunque inventario di indirizzi.

ip route get 198.51.100.20
ip -6 route get 2001:db8::20
wg show wg0 allowed-ips

Gli intervalli di documentazione sono buone destinazioni di prova perché non si risolvono mai in un servizio reale. Confrontate ciò che dice il client con ciò che dice il router, e trattate qualsiasi disaccordo come prova che l’instradamento per criteri, una regola di tunnel diviso o una seconda rotta predefinita stia facendo qualcosa che non avete considerato.

Che cosa può dire una risposta Binding

RFC 8489 definisce la richiesta e la risposta Binding, in cui il server riporta l’indirizzo di trasporto di origine che ha osservato per quella richiesta. È un’affermazione su una quintupla in un dato momento, non un censimento delle interfacce del client. Tutto ciò che è interessante accade quindi tra il client e il punto di osservazione.

Quel vuoto è colmato da instradamento e traduzione. Un router che fa NAT di origine sul traffico in uscita sostituisce l’origine privata del client con il proprio indirizzo sull’interfaccia in uscita. Se quell’interfaccia è il tunnel, il riflettore vede l’indirizzo del tunnel. Se il pacchetto è stato escluso dal tunnel, il riflettore vede ciò che ha prodotto la traduzione WAN. Stesso client, stesso riflettore, risposta diversa.

Tre casi che sembrano uguali e non lo sono

La distinzione utile non è pubblico contro privato, ma quale punto di applicazione ha trattato il pacchetto. Lavorate i casi con le tabelle del router aperte, perché un solo browser può produrre tutti e tre a seconda di una regola che avete dimenticato di aver scritto.

Solo il secondo caso infrange il requisito che certo traffico non esca mai direttamente, e solo il primo e il terzo rivelano un identificatore dal lato del tunnel. Nessuna delle tre righe è un’affermazione sul comportamento di un fornitore preciso: se un riflettore privato sia raggiungibile dipende dall’instradamento, dagli indirizzi IP consentiti dell’altro estremo e dalla politica del firewall ai due capi.

Avere un account presso lo stesso fornitore non stabilisce nulla di tutto ciò. Vale anche la pena ricordare che una richiesta instradata può conservare l’origine LAN del client se nulla la traduce, quindi il campo di origine va tracciato anziché presunto dal diagramma della topologia.

Raccogliere non è selezionare

WebRTC raccoglie indirizzi candidati da provare, e un candidato che compare in un elenco diagnostico può non aver mai trasportato media. Leggere l’elenco come «questo è ciò che l’altro estremo ha appreso» sopravvaluta la prova. La coppia selezionata è quella che ha realmente trasportato la sessione, e vive in un altro campo.

Un verificatore di uscita HTTPS risponde a un’altra domanda: l’indirizzo di origine che un server web ha visto per quella richiesta. È un controllo incrociato utile proprio perché usa un protocollo diverso e spesso una destinazione diversa da un riflettore UDP, e il disaccordo tra i due indica di solito una regola di instradamento più che un difetto.

Decidete la politica, poi leggete la risposta

Scrivete l’intenzione prima di testare: quale traffico deve usare il tunnel, quale può uscire direttamente, quali famiglie di indirizzi rientrano nell’ambito e che cosa deve accadere quando il tunnel è inattivo. Senza quella linea di base ogni osservazione è ambigua, perché non potete separare una fuga da un percorso che avete deliberatamente consentito.

Poi ponete una domanda alla volta. Quale percorso prende questa destinazione. Quale indirizzo riporta questo riflettore. Quale coppia candidata ha selezionato la sessione. Tenete le risposte accanto alla politica e datatele, perché un aggiornamento del firmware può cambiare il comportamento predefinito in modi che invalidano silenziosamente la conclusione dell’anno scorso.

Il router resta un punto di applicazione solido, perché vede traffico che un client non può aggirare senza riconfigurare se stesso. Non è la promessa che ogni campo di ogni protocollo applicativo non riveli nulla, e non sostituisce lo scrivere i percorsi che avete scelto di consentire.