(Dato che alcune persone me l’hanno chiesto mi sembra utile ripetere qua parte del “trucco” che avevo utilizzato per il bonding.)

Può capitarci spesso questa situazione: abbiamo il nostro sistema Linux collegato ad internet normalmente e con una VPN aperta. La route di default di sistema punta al gateway “normale” verso internet.

Diciamo che abbiamo quindi l’interfaccia TAP verso la nostra vpn ed è tutto configurato sul server della vpn per nattare il traffico in uscita cioè possiamo impostare, se vogliamo, il server della VPN come gateway di default.
Vogliamo però uscire su internet normalmente e utilizzare la vpn solo per alcune applicazioni.

Come fare a far uscire sulla vpn solo il traffico di una specifica applicazione?

Per riconoscere i pacchetti in uscita da un determinato processo ci servirebbe la funzionalità di mark by pid che però, purtroppo, non è più supportata in iptables da diversi anni (io mi sto attualmente occupando di re-implementarla). Fortunatamente possiamo sfruttare un workaround sfruttando i gruppi.

Iniziamo con il creare un gruppo apposito per tutti i programmi che vogliamo far uscire sulla VPN:
addgroup vpn
A questo punto diciamo a iptables di marcare i pacchetti in uscita dal sistema con un “mark” specifico. I mark di iptables potete immaginarli come delle etichette che vengono messe su tutti i pacchetti che soddisfano i nostri target. Useremo queste etichette per riconoscere i pacchetti speciali e utilizzare il routing corretto.
iptables -t mangle -A OUTPUT -m owner --gid-owner vpn -j MARK --set-mark 42
Il marcatore scelto (in questo caso 42) è del tutto arbitrario.
In questo modo abbiamo “etichettato” tutti i pacchetti in uscita da processi con GID (Group ID) pari a quello del gruppo vpn.

Ora possiamo procedere a definire una tabella di routing alternativa a quella di default. Non tutti sanno infatti che su Linux non esiste un’unica tabella di routing, ma ne possono essere definite diverse e poi utilizzarle a seconda del contesto.
ip rule add fwmark 42 table 42
In questo modo abbiamo “creato” la tabella di routing numero 42, che si attiverà per tutti i pacchetti con fwmark (cioè la nostra “etichettta”) pari a 42.

Passiamo quindi a aggiungere in questa tabella l’operazione di routing che dovrà essere svolta alternativa a quella standard:
ip route add default via 10.0.0.1 dev tap0 table 42
Tutto ciò supponendo che il server della nostra vpn sia 10.0.0.1 e l’interfaccia sia tap0.

Ci manca ancora una cosa però. A causa del workaround che abbiamo scelto i pacchetti in uscita avranno ancora come sorgente l’ip dell’interfaccia utilizzata per il routing di default. Per questo motivo dobbiamo sostituirlo con il nostro indirizzo della vpn:
iptables -t nat -A POSTROUTING -m mark --mark 42 -j SNAT --to-source 10.0.0.2
(Supponendo che l’ip del nostro client della vpn sia 10.0.0.2)
In questo modo guardiamo tutti i pacchetti con l’etichetta 42 e mettiamo a posto l’indirizzo sorgente.

Ora abbiamo tutto pronto. Come facciamo però a fare in modo che un processo utilizzi il GID (Group ID) che abbiamo scelto per la regola?
Su Linux è possibile lanciare un programma con un GID specifico utilizzando il comando sg (set group):
sg vpn -c "programma_che_fa_uso_della_rete"
Se l’utente con cui avviate sg non è parte del gruppo vpn, dovrete lanciare il comando da root. Per aggiungere il vostro utente al gruppo vpn:
adduser vostro_utente vpn
Come ultima nota vi ricordo che quando lanciate un programma in questo modo, anche le richieste DNS viaggeranno all’interno della VPN, assicuratevi quindi di utilizzare come server DNS dei server raggiungibili sia dalla vpn che da fuori! In alternativa inserite due server DNS in /etc/resolv.conf per gestire entrambi i casi separatamente.