Instradare un account Linux attraverso OpenVPN con una regola UID

L’instradamento per account è adatto quando ogni socket IPv4 di un utente Linux deve uscire da un tunnel esistente, e non è adatto quando serve isolamento a livello di programma. Seleziona per UID, quindi tutto ciò che gira con quell’account rientra nell’ambito, compreso il processo batch che avete dimenticato. Risolvete questa questione prima di toccare una sola ip rule.

L’esempio seguente presuppone un account browser dedicato con UID 1500, un dispositivo di tunnel tun-office con indirizzo locale 10.80.0.11 e una VPN che consente le destinazioni in questione. Il demone stesso gira fuori da quell’UID.

Tre condizioni che scelgono il meccanismo

Scegliete una regola UID quando l’identità che svolge il lavoro è l’account, quando spostare tutto il suo traffico è accettabile e quando un namespace sarebbe più pesante di quanto il compito meriti. Scegliete un namespace di rete quando il carico di lavoro richiede interfacce, resolver e tabella di routing proprie. Scegliete un proxy o un binding per processo quando esattamente un’applicazione deve spostarsi mentre il resto della sessione resta sul percorso locale. Scrivere questi tre punti evita una regola che copre silenziosamente più del previsto.

L’errore da evitare è presumere che un lanciatore definisca il proprietario. Un browser a cui la sessione di un altro utente passa un URL non ha creato socket sotto l’UID 1500, e nessuna regola sposterà il traffico che genera.

La tabella, la regola e la guardia

Dopo aver controllato le regole esistenti e scelto numeri di tabella e priorità non usati, la disposizione è breve: una rotta predefinita in una tabella dedicata che porta l’indirizzo sorgente del tunnel, una regola che manda le ricerche dell’account a quella tabella e una regola terminale che blocca il ripiego. Scritto, è una sostituzione di rotta idempotente, ip -4 route replace default dev tun-office src 10.80.0.11 table 51820, seguita da ip -4 rule add priority 12100 uidrange 1500-1500 lookup 51820.

La guardia è ip -4 rule add priority 12101 uidrange 1500-1500 unreachable, e conta più di quanto suggerisca la sua lunghezza. Senza di essa, una rotta mancante nella tabella 51820 ricade sul collegamento ascendente ordinario e l’account perde silenziosamente il traffico che la politica doveva catturare. Con essa, lo stesso guasto diventa un timeout, cioè un blocco invece di un ripiego.

Tenete la regola normale dell’indirizzo locale davanti a queste, e decidete consapevolmente se le eccezioni LAN o di gestione vanno prima della tabella scelta. Una rotta predefinita trovata lì non consulta in seguito main per una rotta LAN più specifica, il che sorprende chi si aspetta che la corrispondenza del prefisso più lungo valga tra tabelle. Scrivete l’elenco delle eccezioni previste nella nota di modifica finché il ragionamento è ancora fresco.

Ciò che l’instradamento per UID lascia fuori: il DNS

Il demone resolver apre i suoi socket a monte sotto il proprio UID, quindi selezionare 1500 non sposta quelle query nella tabella 51820. L’integrazione DNS è una decisione separata: indicate all’account un resolver raggiungibile dal tunnel, oppure accettate che la risoluzione dei nomi segua il percorso dell’host mentre il traffico no.

Una query in loopback verso uno stub locale non prova che la query a monte abbia usato la rotta del browser, e nemmeno un caricamento di pagina riuscito dalla cache.

IPv6 merita una frase propria nel progetto

Le regole sopra coprono solo IPv4. Se il requisito è un tunnel IPv4 senza IPv6 diretto da questo account, aggiungete una regola terminale rivista come ip -6 rule add priority 12101 uidrange 1500-1500 unreachable, poi controllate le regole IPv6 precedenti e le eccezioni loopback che volete mantenere.

Bloccare IPv6 diretto non è tunnelling a doppio stack; è un confine. Chiamarlo tunnelling confonderà la persona successiva che leggerà la politica, e la confusione emergerà come ticket di assistenza su un sito IPv6 rotto.

Verificate con l’account reale, poi assumetevi il ciclo di vita

Confrontate le ricerche: ip -4 route get 198.51.100.25 uid 1500 rispetto alla stessa destinazione con un UID ordinario. Poi fate una richiesta consentita sotto l’account dedicato e controllate l’indirizzo sorgente che vede l’estremità remota. Un indirizzo sorgente preferito non è source NAT, e non avrà la meglio su un’applicazione che lega qualcos’altro. Se entrambe le ricerche restituiscono lo stesso percorso, la regola non fa ciò che pensate.

Tenete la tabella, le regole e la durata della rotta del tunnel sotto un solo proprietario, provate una riconnessione e una perdita di tunnel, e al ritiro della politica rimuovete solo le sue voci esatte. Un namespace è ancora disponibile se interfacce separate e stato separato sono ciò di cui avete davvero bisogno.