Cosa cambia il routing per policy sul traffico VPN, e cosa no

Il routing per policy risponde a una domanda diversa da quella che pongono la maggior parte delle note di risoluzione dei problemi. La tabella principale dice dove va una destinazione; le regole di policy dicono quale tabella viene consultata, e possono deciderlo dall'indirizzo di origine, da una marcatura di pacchetto, o dall'interfaccia su cui è arrivato un pacchetto. Quando un tunnel si comporta in modo incoerente, l'insieme di regole è spesso la causa e la tabella di routing spesso non lo è.

Le regole scelgono la tabella, poi la tabella sceglie la rotta

Ogni regola porta una priorità, una condizione di corrispondenza e una tabella di destinazione. Il kernel percorre le regole in ordine di priorità e si ferma alla prima corrispondenza, poi esegue una normale ricerca del prefisso più lungo in quella tabella. Una regola che punta a una tabella vuota ricade su ciò che seleziona la regola successiva, ed è così che una regola scritta con cura può sembrare non fare nulla.

Per questo elencare la tabella principale raramente spiega un client VPN funzionante. I client inseriscono di solito regole con numeri di priorità bassi, molto prima della regola predefinita della tabella principale, così il pacchetto non raggiunge mai la rotta che stavate fissando. Abbassare una metrica nella tabella principale non cambia nulla per il traffico già deviato.

Una regola può anche rendere di proposito un prefisso un buco nero o irraggiungibile. Alcuni client aggiungono una regola del genere come interruttore di sicurezza, e allora la caduta sembra un tunnel rotto invece di uno configurato.

Leggi l'insieme di regole come una sequenza, non come un elenco

Stampa le regole con le loro priorità e le tabelle a cui fanno riferimento, poi stampa ogni tabella che porta una rotta predefinita o una rotta di tunnel. L'ordine è la parte che conta, ed è la parte che uno screenshot di solito omette:

ip rule show
ip route show table all | sed -n '1,60p'
ip route get 198.51.100.20 from 10.8.0.2
ip route get 198.51.100.20 from 10.8.0.2 mark 0x1

Gli ultimi due comandi sono quelli che trasformano una teoria in un'osservazione, perché chiedono cosa farebbe il kernel per quell'origine e quella marcatura. Se la risposta cambia quando cambia la marcatura, è in gioco una regola basata sulla marcatura e qualsiasi test che ometta la marcatura sta testando un pacchetto diverso. La connessione esterna merita una regola propria. Un tunnel che instrada tutto il traffico attraverso se stesso deve escludere l'indirizzo di endpoint a cui si connette, altrimenti i pacchetti cifrati vengono rimandati nel tunnel che hanno appena lasciato. La maggior parte dei client inserisce quell'esclusione automaticamente, e un insieme di regole modificato a mano è il punto in cui manca.

Marcature e socket: due modi in cui i client dividono il traffico

Alcuni client marcano i pacchetti nel firewall e aggiungono una regola che corrisponde alla marcatura. Altri usano il routing a livello di socket, mettendo una rotta sul socket prima che si connetta. Il primo è visibile in ip rule; il secondo no, e non apparirà in una ricerca generica.

Se un programma di test si comporta diversamente dall'applicazione che dovrebbe rappresentare, controlla se l'applicazione mette una marcatura o si lega a un dispositivo. Quella differenza non è un mistero una volta nominato il meccanismo, e spiega perché un curl da una shell e una scheda del browser possono prendere percorsi diversi sulla stessa macchina. Entrambe le tecniche sono routing per policy in senso lato: scelgono un percorso con qualcosa di diverso dalla destinazione. Nessuna delle due autorizza il traffico, e nessuna sostituisce le regole del firewall o le credenziali che il peer si aspetta.

Traccia la proprietà prima di aggiungere un'altra regola

Le regole le installa qualcosa. Un client VPN, un gestore di rete e uno script scritto a mano possono ciascuno aggiungere regole all'avvio, e la logica di riconnessione può lasciare dietro l'insieme precedente. Due regole obsolete di un profilo precedente continueranno a orientare il traffico molto dopo che il profilo è stato eliminato.

Scopri quale processo possiede la regola dalla sua priorità e dalla sua forma, e controlla se quel proprietario riscrive l'insieme a ogni connessione. Se lo fa, una regola manuale aggiunta oggi scompare domani, e la correzione appartiene alla configurazione del client e non a un file di cronologia della shell. Pulire l'intero insieme di regole per provare è una scorciatoia tentante con un costo prevedibile: rimuove anche le regole che il client ha bisogno di tenere per far funzionare il proprio tunnel. Elimina una regola alla volta, o prova su una macchina che puoi riavviare.

Dimostra la portata con due flussi, non con uno

Una correzione si verifica solo con un flusso che dovrebbe essere interessato e un flusso che non dovrebbe. Scegli una destinazione che la policy instrada nel tunnel, e una che deve restare fuori, poi confronta le ricerche e le catture per entrambe:

ip route get 198.51.100.20 from 192.0.2.44
ip route get 198.51.100.21 from 192.0.2.44
tcpdump -ni any host 198.51.100.21 and port 443

Quando le due ricerche restituiscono interfacce diverse, la regola fa qualcosa. Quando restituiscono la stessa interfaccia, la regola corrisponde più ampiamente del previsto, e quella è l'anomalia che invia silenziosamente un'intera sottorete attraverso un tunnel pensato per una sola applicazione.

Annota le priorità delle regole e il servizio proprietario nel ticket, insieme ai due indirizzi di test. La persona successiva ha così una coppia riproducibile invece di una descrizione di un sintomo, e può dire in un minuto se il routing per policy è ancora in gioco.