Dante SOCKS su VPN: tunnel completo rispetto al routing per sorgente

Vuoi che il traffico del proxy SOCKS esca dalla VPN mentre il resto dell’host mantiene il suo percorso normale. Due progetti lo fanno, e differiscono in ciò che si rompe quando qualcosa va storto. Uno spinge una rotta predefinita dentro il tunnel e poi la aggira; l’altro lascia in pace la tabella principale e manda un solo indirizzo sorgente a una seconda tabella. Il secondo è più pulito, e ha trappole proprie.

Due progetti, due raggi d’impatto diversi

Il progetto a tunnel completo è ciò che fanno di default quasi tutti i client VPN: sostituire la rotta predefinita così che tutto segua il tunnel, poi escludere ciò che non deve. È facile da ragionare e difficile da mantenere stretto, perché ogni servizio locale che aggiungi eredita il tunnel finché non lo escludi. La modalità di guasto è ampia, dato che una rotta sbagliata si porta dietro la connettività dell’host stesso.

Il progetto a sorgente selezionata va nella direzione opposta. La tabella principale resta com’era, e una regola di policy manda i pacchetti da uno specifico indirizzo locale a una tabella con un default nel tunnel. Nient’altro cambia, il che significa che il raggio d’impatto è un solo indirizzo.

Questa strettezza è anche il vincolo: il progetto funziona solo se i pacchetti in uscita del proxy portano davvero quell’indirizzo.

Che cosa fa l’impostazione external di Dante

L’impostazione external sceglie gli indirizzi che il proxy usa per le connessioni in uscita; non tocca la policy di routing del kernel. È questa separazione a rendere possibile il secondo progetto, ed è anche il punto in cui le persone leggono male la documentazione. Puntare external su un indirizzo del tunnel fa sì che il proxy usi quell’indirizzo come sorgente delle sue connessioni, e poi è la tabella di routing a decidere dove vanno quei pacchetti.

Il listener è una questione separata. Tieni internal limitato ai client che devono usare il proxy, richiedi l’autenticazione e metti un firewall sulla porta, perché un listener aperto non è una funzione dell’uscita VPN.

Verifica che l’indirizzo configurato appartenga davvero al tunnel dentro il network namespace del proxy.

Costruire la tabella a sorgente selezionata

Per un indirizzo TUN 10.90.0.2/24 con un peer raggiungibile su 10.90.0.1, e un numero di tabella che nient’altro usa, la disposizione è questa:

ip -4 route add table 100 10.90.0.0/24 dev tun0 src 10.90.0.2
ip -4 route add table 100 default via 10.90.0.1 dev tun0 metric 10
ip -4 route add table 100 unreachable default metric 32760
ip -4 rule add priority 1000 from 10.90.0.2/32 lookup 100

La rotta unreachable è la parte che la gente salta. Senza di essa, una tabella la cui rotta del tunnel sparisce ricade sul default ordinario e il proxy esce in silenzio dalla WAN. Con essa, la ricerca fallisce, il che è un guasto visibile invece di una fuga silenziosa. Anche la priorità della regola deve stare davanti a qualsiasi altra cosa che corrisponda a quella sorgente.

Questi valori descrivono una topologia. Peer point-to-point, indirizzamento net30 e client che assegnano un prefisso diverso hanno tutti bisogno delle proprie rotte, quindi copia la forma, non gli indirizzi.

Dove la regola sulla sorgente perde

Una regola che corrisponde a un indirizzo sorgente tocca ogni processo che lo usa, non solo il proxy. Se un altro daemon si lega allo stesso indirizzo, anche il suo traffico prende il tunnel, e il guasto sembrerà un problema di un servizio non correlato. Dai al proxy un indirizzo che nient’altro usa, oppure accetta che l’ambito sia l’indirizzo e non il processo.

Il DNS è l’altra fuga. Un socket del resolver non usa necessariamente la sorgente esterna delle connessioni dati del proxy, quindi le risoluzioni dei nomi possono ancora uscire dalla WAN. Prova la risoluzione separatamente dall’instaurazione della connessione, e decidi se quel risultato è accettabile.

IPv6 ha bisogno di regole e rotte proprie, perché un assetto IPv4 non dimostra nulla al riguardo.

Scegli in base al guasto che puoi tollerare

Scegli il tunnel completo quando l’host va protetto nel suo insieme e puoi mantenere l’elenco delle esclusioni. Scegli il routing basato sulla sorgente quando l’host deve conservare il proprio percorso e va reindirizzato un solo servizio. Entrambi sono legittimi; l’errore è scegliere l’uno e poi provarlo come se fosse l’altro.

Qualunque tu scelga, verifica da entrambi i lati: una richiesta attraverso il proxy e una richiesta diretta dall’host, registrando l’indirizzo di uscita osservato per ciascuna.

Se il tunnel cade, decidi in anticipo se il proxy deve fallire o ripiegare, e lascia che sia la tabella di routing a esprimere quella decisione.