Perché una VPN può sembrare connessa quando non funziona niente

Il tuo client segnala connesso mentre l'interfaccia è attiva e il browser va in timeout, e nessuna di queste tre affermazioni è falsa. Connesso descrive uno strato che non ha nulla a che vedere con la pagina che hai richiesto. Decidere quale strato sta segnalando richiede una nuova richiesta e uno sguardo al contatore che dimostrerebbe che il traffico si è mosso. Un riavvio getta via quella prova e ricostruisce le condizioni che stavi cercando di osservare.

Tre cose diverse chiamate connesso

In fondo, connesso può significare che un processo client è in esecuzione e tiene un socket verso un pari. Più in alto può significare che esiste un'interfaccia con un indirizzo, che un dispositivo persistente o una routine di ripristino possono creare senza alcuna sessione viva dietro. A livello di controllo può significare che è stata negoziata un'associazione, il che non dice nulla sul fatto che un solo pacchetto le sia passato sotto. Ognuna di queste sopravvive a guasti a cui le altre non sopravvivono, e un client di solito mostra la più forte che può rivendicare.

Un'icona verde e un tunnel morto sono quindi compatibili e non contraddittori; riferiscono di oggetti diversi. È tutta la ragione per cui questo guasto continua a essere diagnosticato male come bug del client.

Invia una richiesta innocua verso una destinazione che ti serve davvero prima di toccare il demone, e mantieni il blocco del traffico diretto richiesto al suo posto mentre lavori. Un riavvio cancella l'ordine degli eventi e poi li ricrea abbastanza vicini da nascondere la causa, ed è per questo che lo stesso ticket torna una settimana dopo senza nulla di nuovo. Una richiesta, una lettura del contatore e l'innesco che ha prodotto il guasto sono la prova minima.

Quale contatore dimostra che i pacchetti si sono mossi

In IPsec l'associazione IKE e l'associazione CHILD sono oggetti separati, e solo il child porta i contatori che rispondono a questa domanda. Elenca il child, osserva se i pacchetti aumentano in entrambe le direzioni e confrontalo con ciò che l'applicazione sta cercando di fare. Un'associazione installata a zero è un risultato diverso da una che aumenta mentre l'applicazione continua a fallire; la prima significa che il traffico non viene selezionato, la seconda che si sta muovendo e che il guasto è più avanti. Leggi i contatori due volte, a qualche secondo di distanza, perché un solo campione non può mostrare una tendenza.

swanctl --list-sas
ip xfrm state list
ip -s link show dev tun0

I contatori a zero indicano la selezione: il routing, la politica, uno spazio dei nomi da cui è uscito il pacchetto o un'interfaccia a cui il client non si è mai legato. I contatori crescenti indicano lontano dal tunnel, quindi continua con l'inoltro all'estremità remota, la risoluzione dei nomi, il percorso di ritorno e il servizio di destinazione, in quest'ordine. Un protocollo senza oggetto child separato espone la stessa prova nei propri termini, quindi usa ciò che riporta sullo stato del pari e sul conteggio dei pacchetti invece di prendere in prestito il vocabolario di IPsec. La forma della lettura conta più dello strumento che l'ha prodotta.

Dove si trova il guasto dopo che i contatori si muovono

Un gateway che risponde sul proprio indirizzo di gestione dimostra che il gateway funziona, non che qualcosa dietro di esso serva la tua richiesta, quindi prova il lato remoto e non la scatola in mezzo. La risoluzione dei nomi nasconde meglio i guasti, perché un resolver irraggiungibile attraverso il tunnel va in timeout esattamente come una connessione morta. Due ricerche separano quei casi, ed entrambe costano poco. Chiedi prima al resolver che il tunnel impone, poi chiedi a un resolver pubblico lo stesso nome.

dig +short host.example
dig +short @10.20.0.1 host.example
ping -c 2 10.20.0.25

Un nome che si risolve tramite il resolver pubblico ma non tramite quello del tunnel significa che il percorso DNS è rotto, mentre un nome che si risolve tramite entrambi e va ancora in timeout nel browser indica il percorso di ritorno o il servizio. Se il ping per indirizzo riesce e l'applicazione rifiuta ancora, la rete ha consegnato la richiesta e il servizio l'ha rifiutata, che è una fase molto più tarda.

Registra l'innesco, poi cambia una cosa

Registra cosa ha preceduto il guasto: un periodo di inattività, un cambio di rete, un rinnovo di chiave, un portatile ripreso o un sistema ripristinato. Questi producono meccanismi diversi, e di solito solo il sistema ripristinato si ripara da solo, che è proprio il caso che non ti insegna nulla. Un riavvio rimuove l'ordine degli eventi e poi ricrea condizioni abbastanza vicine da nascondere la causa. Scrivi l'innesco mentre è ancora riproducibile.

Poi fai una correzione supportata e ripeti la richiesta originale insieme all'innesco che ha prodotto il guasto. L'inattività è l'innesco più facile da riprodurre, quindi è la conferma più rapida che la correzione ha affrontato il meccanismo e non il sintomo.

Ciò che vuoi riportare è la prova che il traffico che intendevi inviare ha raggiunto il servizio che intendevi raggiungere. Un'icona che diventa verde, una pagina in cache che si carica e un contatore che si muove dimostrano tutti meno di una richiesta completata verso la destinazione prevista. Tieni insieme la richiesta, la lettura del contatore e l'innesco, così la persona successiva può distinguere una correzione da una coincidenza.