Il tunnel completo è più semplice di una lunga lista di tunnel diviso?

Un elenco di tunnel diviso inizia con tre applicazioni e finisce per coprire la maggior parte della macchina, e ogni nuova riga è l’eccezione di qualcuno. A quel punto l’elenco è diventato silenziosamente un valore predefinito con passaggi in più. Il tunnel completo inverte la disposizione: tutto entra nel tunnel tranne se un’esclusione documentata dice il contrario. Se questo sia più semplice dipende dal gateway e dai servizi locali che rompereste.

Iniziate contando le regole che mantenete

Contate le voci, poi contate quante hanno un proprietario nominato e una data di ultima verifica. È il secondo numero che conta, perché un’eccezione che nessuno possiede non può essere valutata quando il software a cui fa riferimento viene rinominato o sostituito. Le regole legate a un percorso eseguibile falliscono in silenzio dopo un aggiornamento, e il guasto sembra una VPN instabile invece di una regola obsoleta. Scrivete l’elenco prima di averne un’opinione.

Ogni voce dovrebbe rispondere a tre domande: cosa si rompe senza di essa, chi l’ha deciso e come notereste che il motivo è scaduto. Le voci che non possono rispondere a tutte e tre sono candidate alla cancellazione più che alla migrazione, e cancellarle prima rende onesto il confronto successivo.

Se la maggior parte delle voci instrada una quota ampia del traffico, state già gestendo un tunnel completo con un carico di manutenzione allegato. La decisione riguarda allora dove vive il valore predefinito, non se debba esserci.

Verificate se il gateway può portare il valore predefinito

Il tunnel completo sposta ogni pacchetto verso un solo dispositivo, il che cambia insieme il carico della CPU di quel dispositivo, la tabella conntrack, la traduzione degli indirizzi e il fabbisogno di banda in uscita. Un gateway che serviva comodamente alcune sottoreti interne potrebbe non essere stato dimensionato per tutta la navigazione di un utente. Guardate il maggior numero di sessioni simultanee che vi aspettate, non la media, perché è il picco a rompersi per primo.

ip -s link show dev tun0
conntrack -C
ss -s

Misurate lo stesso carico prima e dopo la modifica invece di ragionare dalle specifiche. Un solo pomeriggio di uso ordinario su una macchina mostrerà se il gateway è vicino a un limite, e non costa nulla rispetto a scoprirlo un lunedì mattina.

Controllate anche l’MTU del percorso da un capo all’altro, perché un valore predefinito completo espone ogni applicazione alla dimensione massima del pacchetto del tunnel. Applicazioni che funzionavano fuori dal tunnel ora possono dipendere da un comportamento di frammentazione che non avete mai dovuto considerare.

Confermate che i servizi locali e il DNS privato funzionino ancora

Elencate ciò che deve restare locale per protocollo e non per nome di applicazione: protocolli di scoperta per stampanti e display, un bridge per la casa intelligente, la pagina di amministrazione di un router, un server di sviluppo locale raggiunto con un nome che si risolve solo sulla LAN. Questi elementi si rompono quando la rotta predefinita inizia a puntare in un tunnel, e si rompono in silenzio perché nulla registra un errore sul client.

Il DNS privato è l’altra dipendenza. Se i nomi interni venivano risolti dal resolver del tunnel, nulla cambia; se venivano risolti localmente, un valore predefinito completo deve portarli a un resolver che conosce le zone. Provate un nome interno e uno pubblico dopo la modifica invece di supporre che l’elenco dei resolver sia sopravvissuto.

Scrivete le eccezioni locali nel profilo che le possiede. Un’eccezione tenuta solo nella memoria di qualcuno è la prima cosa che la migrazione successiva perde.

Migrate un profilo e verificate i confini

Modificate il profilo tramite la sua configurazione invece di sovrapporre un nuovo valore predefinito a rotte manuali lasciate da esperimenti precedenti. Quelle rotte residue sono la causa abituale di una migrazione che sembra funzionare e si comporta in modo incoerente un giorno dopo. Tenete disponibile il vecchio profilo così che un ritorno sia una selezione e non una ricostruzione.

Poi verificate due confini separatamente: che le destinazioni pubbliche e private funzionino entrambe, e che il traffico indesiderato non esca fuori dal tunnel. Un caricamento di pagina riuscito dimostra il primo e non dice nulla del secondo.

ip route get 203.0.113.10
ip route get 10.40.8.15
resolvectl query intranet.example
curl -sS -o /dev/null -w "%{remote_ip}\n" https://example.com

Ripetete il controllo dopo una riconnessione e dopo un’interruzione, perché un interruttore che blocca il traffico durante un’interruzione è una proprietà diversa da una rotta che poi si ripristina correttamente. Il progetto più semplice è quello di cui potete ancora spiegare la copertura reale dopo che un’applicazione o una rete è cambiata.