Come instradare una sola app tramite VPN senza tutta la macchina

L'icona del client dice connesso, l'interfaccia esiste e l'applicazione continua a non raggiungere nulla. Questa combinazione è comune, perché un'interfaccia virtuale può restare presente mentre il suo peer remoto, i suoi indirizzi o le sue rotte mancano. ip link è il primo strumento giusto, e anche il più facile da sovrainterpretare. Flag e contatori descrivono un livello, e i livelli sopra di essi falliscono in modo indipendente. È anche lo strumento che le persone citano quando vogliono dimostrare che il tunnel è attivo, ed è esattamente l'affermazione che non può sostenere da solo.

Leggi l'interfaccia prima dell'icona

Inizia con ip -details link show dev tun0 come documentato nel manuale di ip-link, sostituendo il nome convenzionale con l'interfaccia che il tuo client possiede davvero. Flag, tipo, MTU e identità dell'interfaccia sono osservazioni utili. La formulazione dello stato di un'interfaccia virtuale non deve comportarsi come l'indicazione di portante di un cavo fisico, quindi tratta UP come un'affermazione sull'interfaccia e non sul tunnel.

Questa distinzione spiega il caso più confuso: un'interfaccia che persiste mentre il lato remoto si riconnette o è irraggiungibile.

Le impostazioni di persistenza possono mantenere il collegamento proprio perché la riconnessione non lo ricostruisca, il che significa che la presenza non è salute.

Aggiungi contatori e una richiesta che dovrebbe usarli

Usa la vista statistiche supportata, ip -s link show dev tun0, e annota i contatori di pacchetti e byte in entrambe le direzioni. Poi genera una richiesta innocua che dovrebbe attraversare l'interfaccia e confronta la direzione pertinente. Una richiesta che ha preso la rotta diretta di un'altra applicazione non muoverà quei contatori, e questo è il senso dell'esercizio.

Se il contatore di trasmissione si muove e quello di ricezione no, il pacchetto è uscito e non è tornato nulla. È un problema diverso da un'interfaccia che non ha mai trasportato nulla. Se entrambi i contatori si muovono e l'applicazione fallisce ancora, il guasto sta sopra l'interfaccia, il che è un progresso e non un vicolo cieco.

Prendi la lettura due volte, una prima e una dopo, invece di fidarti di un'unica istantanea.

Indirizzi e rotte sono passaggi separati

Un collegamento può esistere senza il prefisso, senza la configurazione del resolver o senza la rotta che serve all'applicazione. Controlla l'indirizzo con ip address show dev tun0, poi controlla quale rotta sceglierebbe la destinazione con ip route get per il target reale. Quelle tre osservazioni rispondono a tre domande diverse, e solo l'ultima riguarda l'inoltro.

Con IPsec possono contare anche la politica di sicurezza e lo stato dell'associazione, e non ogni progetto IPsec appare come una semplice interfaccia tun. Cercare un dispositivo tun che non sarebbe mai esistito è un modo rapido per concludere la cosa sbagliata.

Registra il nome esatto, il namespace e l'ora con qualsiasi output che conservi, perché lo stesso nome in un altro container o in una sessione ripristinata rappresenta un contesto del tutto diverso.

Non cancellare ciò che non hai identificato

Un'interfaccia sconosciuta non è automaticamente obsoleta. Identifica il proprietario prima di rimuovere qualcosa, e usa lo smantellamento documentato del client o la configurazione gestita quando la rimozione è davvero voluta. Cancellare un tunnel vivo per vedere cosa succede è un test che risponde a una domanda che nessuno ha posto.

Se l'interfaccia appartiene a un runtime di container o a un namespace di rete che non hai creato, il proprietario è a un comando di distanza e vale la pena trovarlo prima.

Quella cautela vale anche per ip link set down, che sembra reversibile e spesso non lo è.

Cosa dovrebbe lasciarti l'ispezione

Una buona ispezione finisce con quattro fatti: il nome e il namespace dell'interfaccia, i suoi flag e l'MTU, il delta dei contatori da una richiesta reale, e la rotta e l'indirizzo che l'applicazione ha davvero bisogno. Con questi scritti, il passo successivo è ovvio e appartiene a un livello preciso. Senza, ogni modifica successiva è un'ipotesi con un piano di rollback.

Confronta quei quattro fatti con gli stessi quattro di una sessione funzionante. Se il nome e il namespace dell'interfaccia coincidono ma il delta dei contatori è zero, la richiesta non ha mai raggiunto il tunnel. Se il delta dei contatori è sano e la rotta punta altrove, il tunnel va bene e l'instradamento no. È quel confronto che trasforma un mucchio di output in una decisione.

Conserva l'output con il ticket, perché un confronto successivo è utile solo se puoi vedere cosa è cambiato.

Poi chiudi il cerchio provando di nuovo l'applicazione, perché l'interfaccia non è mai stata ciò che interessava all'utente.