Il proxy è ancora sul vecchio indirizzo del tunnel dopo una riconnessione VPN?

Riavviare il client VPN dimostra solo che il tunnel è tornato. Non dice nulla del proxy a cui era stato detto di uscire attraverso di esso. Squid, tinyproxy e la maggior parte degli altri forwarder mantengono l’indirizzo sorgente locale risolto all’avvio finché qualcosa non li costringe a ricaricare. Quando una riconnessione assegna un nuovo indirizzo del tunnel, il forwarder fallisce a ogni connessione in uscita oppure comincia a uscire dalla tua rotta ordinaria.

Il secondo guasto è quello pericoloso: il tunnel è attivo, le pagine si caricano e solo l’indirizzo di uscita è sbagliato.

Parti dal listener, non dal tunnel

Ci sono tre indirizzi in gioco, e una riconnessione ne sposta solo alcuni. Il listener è dove punta il tuo browser, di solito 127.0.0.1 o un indirizzo LAN, e non gli importa che il tunnel sia cambiato. La sorgente locale in uscita è ciò che il forwarder chiede al kernel di usare quando compone il salto successivo, ed è legata al dispositivo del tunnel. L’uscita pubblica è ciò che registra un server web, e può essere un indirizzo tradotto a diversi salti di distanza.

Una ricerca dell’IP pubblico risponde solo all’ultima domanda. Non può dirti a quale indirizzo locale un forwarder debba legarsi, perché una sola uscita pubblica può nascondere diverse sorgenti interne. Leggi l’indirizzo da chi possiede la connessione: l’output di stato del client, l’interfaccia stessa o lo spazio dei nomi in cui vive il tunnel. Prendere la prima interfaccia il cui nome somiglia a un tunnel dà la risposta sbagliata appena esiste un secondo profilo.

Le disposizioni con container e spazi dei nomi spezzano silenziosamente questo presupposto. Un forwarder in uno spazio dei nomi di rete non può legarsi a un tunnel che esiste in un altro, e nessuna modifica alla configurazione lo ripara.

Quattro controlli prima di modificare qualcosa

Affrontali in ordine. Il primo controllo che fallisce è il punto in cui ti fermi, perché i successivi presuppongono che i precedenti valgano.

1. Conferma che il tunnel in uso sia il profilo attorno a cui è stato costruito il proxy, non un secondo profilo che si è connesso da solo.
2. Stampa l’indirizzo attualmente presente su quel dispositivo e confrontalo con l’indirizzo nella configurazione in esecuzione.
3. Chiedi al forwarder quale sorgente ha risolto, invece di ciò che dichiara il file su disco.
4. Conferma che il traffico del forwarder sia realmente soggetto alla politica di routing e firewall che ti aspetti.

L’indirizzo del dispositivo è facile: ip -4 addr show dev tun0 stampa quello attuale, e ip -4 route get 1.1.1.1 mostra quale interfaccia sceglierebbe il kernel per quella destinazione. Un forwarder che lega un indirizzo esatto fallisce rumorosamente quando l’indirizzo sparisce. Un forwarder che lega un dispositivo, o ricade sulla sorgente predefinita, continua a funzionare e a perdere traffico, e questo è il risultato silenzioso.

Allinea la documentazione alla versione che esegui, non al primo risultato di ricerca. La direttiva dell’indirizzo in uscita di Squid è documentata per v7 e precedenti, e la documentazione di v8 dice chiaramente che la direttiva non è disponibile lì, quindi uno script costruito su di essa non sopravvive a quel confine (vedi il riferimento Squid tcp_outgoing_address). Verifica con il parser del prodotto stesso prima che qualcosa venga ricaricato: squid -k parse segnala errori ed esce senza toccare il processo in esecuzione.

Numera ogni tunnel e scarta gli scambi obsoleti

Una riconnessione è una consegna, e le consegne hanno bisogno di un ordine. Etichetta ogni connessione osservata con un contatore o una marca temporale che aumenta a ogni stabilimento riuscito, poi porta quell’etichetta nella configurazione candidata. Quando l’etichetta di un candidato è più vecchia di quella attuale, scarta il candidato invece di applicarlo, perché un aggiornamento lento scritto per il tunnel precedente sovrascriverebbe altrimenti le impostazioni di quello attuale. Unisci le raffiche di eventi così che un collegamento che oscilla produca una transizione invece di quindici.

Ordina il lavoro in quattro mosse: invalida il vecchio stato di uscita, attendi che il proprietario della connessione segnali il completamento, costruisci solo il frammento gestito, poi verifica e attiva tramite il gestore dei servizi. Rigenerare l’intero file da due valori di indirizzo è il modo in cui le restrizioni del listener, l’autenticazione e la politica di destinazione spariscono in silenzio. Rispetta anche un arresto deliberato. Un aiutante che continua a comporre un tunnel che l’utente ha spento è un difetto, non una resilienza.

I socket aperti non seguiranno il nuovo indirizzo

Riconfigurare il forwarder non dice nulla delle connessioni già stabilite. Se si svuotano o muoiono dipende dal prodotto, quindi osserva il comportamento invece di darlo per scontato.

Una richiesta servita su un socket aperto prima dello scambio esce ancora dal vecchio percorso, anche quando la nuova configurazione è corretta. Se questo conta, decidi esplicitamente: concedi una breve finestra di svuotamento e smetti di accettare nuovo lavoro, oppure chiudi i vecchi socket e accetta gli errori. Poi prova con una connessione nuova e tieni quel risultato separato dal controllo di svuotamento. Anche il binding della sorgente non è un confine di sicurezza. Quando il traffico non deve mai toccare la rotta ordinaria, imponilo con marcature e regole del firewall, DNS e IPv6 inclusi, così che una ricarica fallita lasci il proxy esplicitamente spento invece che aperto.

Dimostra la nuova uscita con una richiesta nuova

Ciò che conta è una richiesta aperta dopo l’attivazione, non un ping e non una pagina già in cache. Chiedi al proxy un URL reale e leggi l’indirizzo di uscita che l’estremità remota riporta, poi confrontalo con la visione che il client ha del tunnel quando il fornitore ne espone una.

Tieni l’analisi, la ricarica e la richiesta come comandi separati così che un guasto indichi un solo passo. I primi due non cambiano nulla quando falliscono, ed è proprio per questo che girano prima del riavvio.

squid -k parse
sudo squid -k reconfigure
curl -x http://127.0.0.1:3128 -sS -o /dev/null -w '%{http_code} %{remote_ip}\n' https://example.com

Se la ricarica fallisce, ferma il servizio e ripara il frammento; un proxy che serve con un’uscita obsoleta è peggio di una breve interruzione. Se la ricarica riesce ma la richiesta nuova esce ancora in un punto inatteso, torna al controllo di routing invece di modificare di nuovo gli indirizzi. Annota la generazione del tunnel rispetto alla quale hai verificato, così la prossima riconnessione ha qualcosa di concreto da confrontare.