Un’applicazione legata a un’interfaccia? Il suo percorso VPN non è quello predefinito

Un’applicazione sulla macchina esce dalla VPN e un’altra no, ed entrambi gli utenti giurano di non aver cambiato nulla. La differenza è spesso una decisione di binding presa dall’applicazione stessa: un socket legato a un dispositivo, un indirizzo sorgente scelto prima della connessione o uno spazio dei nomi con la propria tabella di routing. Ognuna cambia quale percorso si applica, e nessuna compare in un controllo IP generico nel browser.

Tre binding diversi, tre effetti diversi

Legarsi a un dispositivo e legarsi a un indirizzo sorgente sono operazioni correlate con conseguenze diverse. Un binding al dispositivo può forzare il traffico a uscire da un’interfaccia e aggirare la normale ricerca della rotta per quel socket. Il binding a un indirizzo sorgente passa comunque dalla selezione della rotta, ma l’origine scelta può corrispondere a una regola di policy e inviare il pacchetto altrove. La distinzione sembra accademica finché una regola non instrada per origine. Allora decide tutto.

Lo spazio dei nomi di rete è il terzo caso. Ha le proprie interfacce e la propria tabella di routing, quindi un’applicazione al suo interno non subisce affatto il valore predefinito dell’host. Trattare tutti e tre come la stessa cosa produce spiegazioni sicure che non superano la prima prova.

Determina che cosa imposta davvero l’applicazione

Leggi la configurazione di rete dell’applicazione o il suo comportamento documentato prima di toccare le rotte. Se espone una scelta di interfaccia, un campo per l’indirizzo sorgente o un’opzione di spazio dei nomi, quella impostazione è la prima cosa da ispezionare. Altrimenti il binding può essere interno e visibile solo tramite tracciamento o le sue stesse diagnostiche.

Su Linux, opzioni di socket come SO_BINDTODEVICE hanno ambito e requisiti di permessi documentati, e un processo senza privilegi potrebbe non riuscire affatto a impostarle. Questo vincolo è un indizio utile: se l’opzione non può essere applicata, probabilmente l’applicazione non è l’origine della differenza.

Il routing per policy legge l’origine

Quando è configurato il routing per policy, una regola può scegliere una tabella in base all’origine del pacchetto. Un socket che lega un indirizzo sorgente può quindi seguire una regola che il percorso predefinito non tocca mai, anche se nessuna interfaccia è nominata esplicitamente.

Riproduci la ricerca con la stessa famiglia di indirizzi, origine e spazio dei nomi usati dall’applicazione. Una ricerca generica di rotta da una shell nello spazio dei nomi dell’host risponde a un’altra domanda, e questa discrepanza è il motivo più comune per cui una rotta funzionante sembra rotta.

Tunnel diviso e processi ausiliari

Il tunnel diviso per applicazione aggiunge un altro livello. Il client può far corrispondere il pacchetto o il processo dell’applicazione, e un assistente che apre il proprio socket è un soggetto separato. Un launcher e il suo servizio in background possono produrre connessioni diverse sotto lo stesso nome visibile.

Controlla se la regola del tunnel diviso copre il processo che si connette davvero. Se l’applicazione si lega a un’interfaccia specifica e il client VPN fa corrispondere per pacchetto, le due decisioni possono divergere senza che nessuna sia sbagliata.

Prova il percorso proprio dell’applicazione

Esegui una nuova richiesta dall’applicazione dopo ogni modifica. Un browser che mostra l’uscita desiderata non è una prova equivalente per un altro programma legato a un’altra interfaccia, e le connessioni in cache possono continuare a usare il vecchio percorso molto dopo il cambio di un’impostazione. Chiudi la vecchia sessione prima di giudicare la nuova regola. Altrimenti il test misura il passato.

Il riferimento socket di Linux documenta SO_BINDTODEVICE e i suoi requisiti. Leggi prima la configurazione dell’applicazione stessa, riproduci la ricerca nello stesso contesto e solo dopo decidi se cambiare la rotta o il binding.