La VM Vagrant sparisce quando si connette la VPN: di chi è la rotta rotta

La macchina rispondeva un minuto fa, la VPN si è connessa e ora lo stesso indirizzo va in timeout. Tre guasti producono quel sintomo e vivono su macchine diverse. L'host può perdere la rotta verso la rete privata, l'intervallo NAT dell'ospite può entrare in collisione con un intervallo che il tunnel ora annuncia, oppure un tunnel completo può impossessarsi di tutte le rotte dell'host. Scoprite quale è successo prima di cambiare qualsiasi configurazione, perché ogni correzione vive altrove.

Osservate la rotta, non la macchina

Guardate la decisione di routing dell'host per l'indirizzo dell'ospite mentre il tunnel è attivo. Una rotta che punta ancora all'adattatore solo host non è il problema. Una rotta che ora punta all'adattatore VPN è il problema, e l'ha cambiata il client, non voi. Il fatto che l'adattatore conservi il suo indirizzo dice che l'interfaccia è sopravvissuta, cosa diversa dalla sopravvivenza del percorso.

Una sessione SSH che cade esattamente al momento della connessione è un comportamento atteso. Il client ricicla gli adattatori e installa rotte, quindi la connessione muore per qualche secondo. Il guasto è la connessione che non torna mai, non quella che ha lampeggiato.

Catturate la tabella prima del tunnel e di nuovo dopo, poi confrontate queste due uscite. La differenza è la diagnosi, ed è anche la prova che un responsabile di rete chiederà.

ip -4 route get 192.168.56.10
ip -brief addr show
ip route show table main | head -20

Leggete la tabella dell'host prima e dopo

Su Linux la preferenza tra rotte sovrapposte deriva dalla lunghezza del prefisso e dalla metrica, quindi una rotta VPN più specifica vince anche quando è sbagliata. Su Windows la metrica dell'interfaccia decide la parità, e l'adattatore del tunnel di solito arriva con una metrica più bassa del virtuale. In entrambi i casi il sintomo visibile è identico: i pacchetti escono dall'adattatore del tunnel e svaniscono.

Stampate gli adattatori e le loro metriche accanto alla rotta del prefisso dell'ospite. Quella coppia di uscite risponde alla domanda della proprietà con un colpo d'occhio.

Get-NetAdapter | Select-Object Name, InterfaceIndex, InterfaceMetric
Get-NetRoute -DestinationPrefix 192.168.56.0/24
route print -4 | Select-String '192.168.56'

Se la rotta è cambiata ma la metrica dell'adattatore no, il client ha installato una rotta concorrente. Se è cambiata la metrica, il client ha riordinato gli adattatori. Entrambe sono riparabili, e si riparano in punti diversi.

Quando l'intervallo NAT dell'ospite è la collisione

VirtualBox NAT usa 10.0.2.0/24 per impostazione predefinita, e un tunnel che spinge lo stesso intervallo fa sì che l'ospite invii quel traffico al proprio gateway NAT invece che alla destinazione reale. Il pacchetto non lascia mai l'host, quindi nessun registro del firewall dall'altra parte lo mostrerà. Docker Machine ha la stessa classe di conflitto nel suo piano solo host, e cambiare quel piano può richiedere di ricreare la macchina insieme ai suoi certificati.

Scegliete il sostituto elencando ciò che il tunnel annuncia già, poi ciò che usa la rete dell'ufficio e poi ciò che ha rivendicato ogni adattatore virtuale di questo host. È la sovrapposizione che rompe il routing, e la somiglianza è irrilevante. Un intervallo può stare interamente dentro un altro pur non somigliandogli affatto a prima vista.

Impostate il nuovo intervallo alla creazione della macchina, oppure cambiatelo e ricaricate, poi testate di nuovo la connessione che fallisce dall'ospite. La tabella dell'ospite stesso è la vista che conta.

VBoxManage modifyvm devbox --natnet1 10.77.0.0/24
vagrant reload devbox --provision
vagrant ssh devbox -c 'ip route get 10.20.0.15'

Ripristinate il percorso senza combattere il client

Ogni piattaforma offre un modo per riportare avanti il prefisso solo host. Su macOS una rotta statica verso l'interfaccia solo host funziona fino alla connessione successiva. Su Windows una metrica di interfaccia più bassa sull'adattatore virtuale lo mantiene preferito. Su Linux un'operazione di sostituzione copre un solo prefisso. Tutte e tre sono soluzioni tampone, perché un client che riafferma le proprie rotte le annullerà.

Scrivete il controllo come script invece di una riconnessione cieca all'avvio. Un piccolo script che stampa la rotta del prefisso dell'ospite dopo ogni connessione trasforma un mistero in una riga di registro.

Se il profilo è un tunnel completo, chiedete al responsabile di rete un tunnel diviso o un'eccezione documentata. Aggiungere in silenzio rotte che aggirano una politica di sicurezza non è una correzione, è un secondo problema che arriva più tardi con un auditor al seguito.

Verificate la correzione su entrambi i lati

Verificate tre percorsi dopo la modifica: host verso ospite, ospite verso l'host aziendale e ospite verso internet. Una correzione che ne ripristina uno e ne rompe un altro è un cambiamento di configurazione mascherato da riparazione. Catturate le stesse uscite raccolte prima della modifica, così il confronto è tra pari.

Annotate l'interfaccia, la metrica e la rotta cambiate, insieme all'ora, perché la prossima occorrenza sia una ricerca e non una ricostruzione. Quella nota vale più di un lungo thread di ticket.

ip -4 route get 192.168.56.10
traceroute -n -m 4 10.20.0.15
curl -sS -o /dev/null -w '%{http_code}\n' https://example.com

Quando l'host raggiunge di nuovo l'ospite e l'ospite raggiunge la LAN, avete ripristinato il percorso da cui eravate partiti. Quando solo uno dei due funziona, il guasto rimanente è nel territorio dell'altro proprietario, e la differenza vi dice quale territorio sia.