Perché la tua regola di tunnel diviso ha smesso di corrispondere a un servizio

Il tunnel diviso di solito fallisce in uno di due modi. O il traffico che dovrebbe stare dentro il tunnel lo aggira, oppure il traffico che dovrebbe restare fuori viene trascinato dentro. L’errore della regola obsoleta è il primo tipo, ed è quello che confonde di più, perché la regola viene applicata esattamente come è scritta. Ciò che è cambiato è la destinazione: il servizio ora risponde su un indirizzo che la regola non ha mai nominato, e nel tunnel non c’è nulla di sbagliato.

Cosa fissa la regola e cosa restituisce il DNS

Una regola di tunnel diviso è un’affermazione statica sulle destinazioni, di solito espressa come prefisso, rotta o elenco di indirizzi. Viene valutata rispetto alla destinazione del pacchetto al momento dell’invio. Un nome host è una ricerca che restituisce un insieme di indirizzi con una durata e una cache, e la risposta può variare per resolver, per tipo di query e per minuto.

Questi due oggetti non negoziano mai tra loro. La regola continua a corrispondere al prefisso che le è stato dato, il servizio continua a cambiare l’indirizzo che distribuisce, e il divario tra loro si allarga in silenzio. Ecco perché il sintomo compare dopo una migrazione del fornitore o un rinnovo del certificato e non dopo un cambio di configurazione. Nessuno ha modificato il tunnel, quindi nessuno guarda il tunnel, e la diagnosi scivola verso l’applicazione invece che verso la politica.

Tre modi in cui la corrispondenza si rompe

Il caso ovvio è un servizio spostato: l’operatore gli ha dato un nuovo indirizzo, il DNS ha seguito, e l’eccezione no. Il secondo è una famiglia di indirizzi che la regola non ha mai coperto, cosa che accade quando un nome inizia a restituire record AAAA che un’eccezione solo per IPv4 ignora. Il terzo è una differenza di resolver: una vista interna e una pubblica possono restituire indirizzi diversi per lo stesso nome, quindi l’indirizzo che usa la tua app non è quello con cui hai fatto la prova.

Una connessione in cache è una quarta variante ed è facile da trascurare. L’applicazione potrebbe parlare ancora con un indirizzo che ha risolto un’ora fa, il che significa che la tua ricerca recente e il suo socket aperto non concordano su dove viva il servizio.

Leggi la destinazione che l’app usa davvero

Chiedi al sistema operativo e alla tabella dei socket, non a una scheda del browser. La ricerca risponde a cosa si risolve il nome in questo momento, e la tabella dei socket mostra l’indirizzo a cui è connesso il processo, che può essere più vecchio. Esegui entrambi prima di formulare una teoria, perché la differenza tra loro è essa stessa la risposta in circa metà dei casi.

getent ahosts api.example.com
dig +short api.example.com A
dig +short api.example.com AAAA
ss -tnp | grep -F api
ip route get 203.0.113.40

Poi confronta con ciò che la regola copre. Se l’indirizzo attuale cade fuori dall’eccezione e la richiesta continua a fallire, hai trovato la causa senza toccare la configurazione del tunnel. Se l’app è connessa a un indirizzo che corrisponde alla regola e la richiesta continua a fallire, il problema è oltre il tunnel e questa è l’indagine sbagliata.

Ripara il meccanismo, non il sintomo

Se il prodotto supporta un instradamento mantenuto basato sui domini, usalo e segui il suo comportamento documentato di aggiornamento e ambito. Questo sostituisce una supposizione statica con una risposta mantenuta, al costo di dipendere dal fatto che la funzione funzioni come documentato.

Se il progetto si basa su un elenco statico, dagli un proprietario e un piano di aggiornamento. Il piano dovrebbe dire come viene scoperto l’indirizzo, chi approva la modifica e con quale rapidità ci si aspetta che l’elenco segua una migrazione del fornitore. Un elenco senza proprietario è un futuro guasto con una causa nota.

Non allargare l’eccezione a una grande rete vicina solo per catturare ogni indirizzo visto durante un test breve. Non è una correzione; è un cambiamento permanente del confine di sicurezza, e lascerà tranquillamente servizi non correlati aggirare il tunnel finché la regola esiste.

Verifica entrambe le metà dell’intento

Un progetto di tunnel diviso ha due intenti, e una correzione dovrebbe preservarli entrambi. Il servizio protetto deve passare dal tunnel, e le categorie escluse devono continuare ad aggirarlo. Prova una connessione nuova alla destinazione riparata, poi prova qualcosa che dovrebbe restare fuori.

curl -sv --max-time 5 https://api.example.com/ -o /dev/null 2>&1 | grep -E 'Trying|Connected to'
curl -sS --max-time 5 https://public.example/ -o /dev/null -w '%{http_code}\n'

Annota il nuovo indirizzo, il meccanismo scelto e la data. È quella nota che impedisce alla persona successiva di concludere che la VPN abbia ignorato a caso la propria configurazione.