Cosa vi dice una tabella di routing VPN e cosa non può dirvi

Vi collegate, eseguite un elenco delle route e vedete una sottorete di cui non avete mai sentito parlare che punta al tunnel. Quella riga afferma una cosa con precisione e diverse cose per niente. Registra come questa macchina inoltrerà i pacchetti a quel prefisso, nulla su quali host esistono lì e nulla su ciò che il vostro account può raggiungere. Leggerla correttamente richiede un minuto; leggerla come un inventario richiede molto più tempo per disimpararlo.

Leggete la tabella come istruzioni locali

Una route è un’istruzione di inoltro tenuta dal kernel locale: per questo prefisso, usate questa interfaccia e questo prossimo salto. La lunghezza del prefisso decide quanto è specifica l’istruzione, e vince la corrispondenza più lunga. Nulla in quella regola menziona autorizzazioni, salute del servizio o topologia remota.

Le regole di policy possono intervenire prima che la tabella venga consultata, ed è per questo che una route può esistere e non essere comunque quella usata da un dato pacchetto. Leggete le regole accanto alla tabella, poi chiedete al kernel quale percorso sceglierebbe per una destinazione specifica. La risposta per un indirizzo vale più di una pagina di prefissi, ed è l’unica risposta che riflette i marcatori, gli spazi dei nomi e i binding di interfaccia applicati dal client.

Un prefisso ampio non è un catalogo

Un /16 instradato attraverso il tunnel non significa sedicimila host raggiungibili, e una route predefinita significa ancora meno. Il server decide chi risponde, il firewall decide cosa è permesso e l’account decide cosa è autorizzato.

Una tabella stretta ha la trappola opposta: un prefisso assente può significare che la destinazione è raggiungibile per un’altra via, o semplicemente che non è instradata affatto. Quei due casi sembrano identici finché non li provate. Confrontate la tabella con la risorsa che vi è stato detto di usare, non con le vostre aspettative su cosa dovrebbe contenere una VPN.

Da dove vengono le voci

Le route arrivano da almeno quattro posti: il file di configurazione, il server che spinge una route durante l’instaurazione della connessione, un gestore di rete che possiede l’interfaccia e una persona che digita un comando durante un incidente. Ognuno ha una durata diversa e un proprietario diverso.

Quella digitata durante un’interruzione è quella che sparisce al riavvio e non compare nella documentazione di nessuno. Una route spinta dal server cambia quando cambia il server, ed è per questo che un nuovo prefisso inspiegato spesso compare dopo un aggiornamento del gateway e non dopo un cambiamento del client. Il manuale di ip-route documenta la sintassi della tabella e dei campi se dovete leggere i flag.

Verificate la route rispetto al contratto di servizio

Il confronto utile è tra la tabella e il servizio che vi è stato promesso: nome, ambito degli indirizzi, porta e proprietario. Scrivete quei quattro accanto al prefisso e le lacune diventano visibili.

ip route show table all dev tun0
ip route get 10.20.5.9
ip rule show

Se il prefisso è presente e il servizio fallisce ancora, la tabella ha fatto il suo lavoro e il problema è altrove: risoluzione dei nomi, un firewall dall’altra parte o un account senza il gruppo giusto. Se il prefisso manca, la domanda è chi avrebbe dovuto fornirlo, non cosa digitare. Entrambe le risposte nominano un team da chiedere in seguito, e questo è l’unico output utile della lettura di una tabella di routing. Scrivete quel nome prima di chiudere il terminale.

Registrate il prima e il dopo di ogni modifica, con la data e l’interfaccia. Una tabella di routing è un’istantanea di un momento su una macchina, e diventa una prova solo quando qualcuno ha annotato quando è stata scattata.