Stesso IP del server, due percorsi: marcare il flusso esterno di OpenVPN

La consueta protezione contro i loop è una rotta host: invia il traffico verso l'indirizzo pubblico del server VPN sull'uplink, così la sessione cifrata non entra mai nel proprio tunnel. Funziona fino al momento in cui vuoi raggiungere anche un servizio web su quello stesso server attraverso il tunnel, perché l'esenzione è legata alla destinazione e la destinazione è identica. La via d'uscita è smettere di classificare per destinazione e iniziare a classificare in base a quale socket ha inviato il pacchetto.

Parti dai due flussi che vuoi separare

Un flusso è il trasporto OpenVPN cifrato stesso, che deve uscire dall'uplink, altrimenti il tunnel porterebbe la propria connessione esterna. L'altro è una normale richiesta HTTPS allo stesso indirizzo pubblico, che vuoi dentro il tunnel perché arrivi al servizio da un'origine tunnel. Stessa destinazione, in molti casi stesso numero di porta, percorso richiesto diverso.

Per questa trattazione, supponi un client su 10.90.0.10 tramite tun1, un indirizzo pubblico del server di 198.51.100.25 e una tabella principale intatta la cui rotta predefinita punta all'uplink ordinario. Il lato server deve anche accettare il servizio web sul percorso interno e restituire il traffico all'origine del tunnel; inviare un pacchetto a un indirizzo pubblico non annulla il listener né la politica del firewall del server.

Prima di cambiare qualcosa, registra le regole attuali dell'host e scegli valori che nessun altro usa: un mark, un numero di tabella e tre priorità di regola. Mantieni una via di ritorno alla macchina che non passi per questa connessione, perché un errore qui ti toglie il tuo accesso remoto invece di rompere solo una scheda del browser.

Marca il socket che porta la busta

La configurazione del client guadagna un mark per i suoi pacchetti cifrati in uscita e smette di installare rotte da sola, così la politica di sostituzione è l'unica cosa che decide i percorsi:

mark 42
route-noexec
disable-dco

Il decimale 42 è esadecimale 0x2a, e la forma esadecimale è quella su cui corrisponderanno le regole di instradamento. Il riferimento di link-options descrive mark come qualcosa che si applica ai pacchetti cifrati in uscita su Linux, cioè esattamente il socket di cui devi controllare il percorso. Disattivare l'offload del canale dati mantiene questo esempio sul percorso dello spazio utente, dove il comportamento del mark è quello descritto.

route-noexec sopprime le aggiunte e rimozioni automatiche di rotte di OpenVPN. Non installa nulla al loro posto, quindi da questo momento il proprietario delle rotte deve mantenere ogni rotta che il tunnel richiede. Se una destinazione privata scompare dopo la modifica, è la politica di sostituzione mancante, non un difetto del mark.

Non tenere una rotta host nella tabella principale per 198.51.100.25 mentre fai questo. Una rotta del genere reintroduce esattamente l'esenzione che il progetto cerca di restringere, e vincerà per il flusso HTTPS prima che venga consultata qualsiasi politica qui sotto.

Manda tutto il resto alla tabella del tunnel

Una volta che l'interfaccia del tunnel esiste e ha il suo indirizzo, la politica appare così:

ip -4 route add default dev tun1 src 10.90.0.10 table 47100
ip -4 rule add priority 20000 lookup main suppress_prefixlength 0
ip -4 rule add priority 20001 not fwmark 0x2a lookup 47100
ip -4 rule add priority 20002 not fwmark 0x2a unreachable

La prima regola tiene visibili le rotte specifiche dell'host, compresa qualsiasi rete locale approvata, mentre rende invisibile la rotta predefinita della tabella principale per questa ricerca. Questa distinzione conta: sopprimere la predefinita non è lo stesso che ignorare la tabella, e le eccezioni locali che ti servono ancora sopravvivono proprio per questo. Leggi quelle eccezioni una per una invece di dare per scontato che il risultato sia un interruttore di arresto universale.

Il traffico non marcato ricade quindi nella tabella del tunnel, prende l'origine del tunnel ed esce dalla VPN. Il traffico marcato fallisce il test fwmark sulle due regole successive e prosegue verso la ricerca principale ordinaria più in basso nell'elenco, dove la predefinita dell'uplink è ancora presente. La regola unreachable finale è quella che impedisce a un flusso non marcato di ricadere silenziosamente sull'uplink quando manca la rotta del tunnel. Il selettore è il mark dall'inizio alla fine, e l'indirizzo di destinazione non entra mai nella decisione.

Mantieni quella guardia in posizione tra le disconnessioni, e installala con il resto della politica invece che a mano. Una regola che svanisce con l'interfaccia non è una politica, è una coincidenza. Cancellare la politica quando il tunnel cade cambia la modalità di guasto da “bloccato” a “filtrato”, e una rotta del tunnel obsoleta che scade più tardi è un problema molto più facile da spiegare del traffico uscito dall'interfaccia sbagliata.

Fai vedere lo stesso mark al percorso di ritorno

I mark in uscita sono solo metà del meccanismo, e questa è la parte che la maggior parte delle riproduzioni omette. Le risposte alla sessione cifrata arrivano sull'uplink e sono soggette alla validazione del percorso di ritorno, che chiede se l'origine instraderebbe indietro per la stessa strada da cui è arrivata. Senza aiuto, quella ricerca applica la tua politica del tunnel non marcata e conclude che il pacchetto è sull'interfaccia sbagliata.

La correzione spetta al proprietario del firewall: salva il mark sulla connessione in uscita, ripristinalo sui pacchetti in ingresso corrispondenti e abilita la gestione dei mark convalidata dall'origine per il percorso interessato. Che OpenVPN imposti un mark sul socket non fa nessuna di queste tre cose, e una ricetta che elenca solo le opzioni del client è incompleta. Chiedi quell'integrazione per iscritto, perché è la parte meno visibile del progetto e la più facile da perdere in una ricostruzione.

Nemmeno il controllo permissivo del percorso di ritorno è un sostituto. La modalità permissiva richiede comunque che esista una rotta per l'origine, e la guardia unreachable che hai aggiunto ne rimuove deliberatamente una per le ricerche non marcate. Fai completare e rivedere l'integrazione del mark di connessione prima di affidarti a questo progetto, e tratta i filtri dell'host come una questione separata: un mark è un segnale di instradamento, non un permesso. Se l'integrazione manca, il sintomo è una sessione che si stabilisce e poi tace non appena le risposte iniziano ad arrivare.

Provalo con due ricerche di rotta

Confronta ciò che il kernel decide per i due contesti, e leggi i campi dev e src invece dello stato di uscita:

ip -4 route get 198.51.100.25
ip -4 route get 198.51.100.25 mark 0x2a

La prima ricerca dovrebbe risolvere su tun1 con l'origine del tunnel, e la seconda sull'uplink. Sono ricerche sintetiche, quindi provano la politica e non il processo vivo: conferma separatamente il percorso di trasporto reale del client in esecuzione, poi fai una vera richiesta HTTPS con la verifica dei certificati attiva.

Annota ciò che il progetto non copre prima di dichiararlo finito. DNS, IPv6 e il ciclo di vita delle regole richiedono ciascuno una propria decisione, e questo è un esempio di instradamento IPv4 più che una configurazione completa della privacy. Il suo valore è il selettore: la busta ottiene l'esenzione dell'uplink, e un servizio ordinario allo stesso indirizzo non deve ereditarne l'esenzione.