VPN attiva, VM irraggiungibile? La rotta probabilmente non è mai stata il problema

Connettete la VPN e la VM di sviluppo che rispondeva un minuto fa ammutolisce. La storia ovvia si scrive da sola: il tunnel ha preso la rotta, l'host ora invia il traffico dell'ospite nella rete aziendale, e la correzione è aggiungere una rotta statica o passare l'adattatore in modalità bridge. Quella storia a volte è vera. Ma non è la causa abituale, e agire su di essa per prima di solito rompe qualcos'altro.

Il networking host-only è una rete software di proprietà dell'host e condivisa con i suoi ospiti, separata da qualsiasi collegamento fisico. Nulla nell'interfaccia propria del client VPN cambia quella rete, quindi prima di toccarla, scoprite quale dei quattro livelli ha davvero fallito.

La rotta di solito resta locale

Chiedete al kernel invece che alla prima pagina della tabella di routing. Su Linux, ip route get 192.168.56.10 riporta la rotta, l'interfaccia e l'indirizzo di origine esatti che verrebbero usati, che è una risposta diversa dal leggere una rotta predefinita e tirare a indovinare. Se l'output nomina l'interfaccia host-only, il tunnel non è affatto coinvolto in quel percorso.

Due cose possono davvero romperla, ed entrambe sono problemi di indirizzi e non di VPN. Una sottorete remota che si sovrappone al prefisso host-only fa vincere la rotta più specifica, e un client VPN che installa una rotta ampia con metrica più bassa può portare via il prefisso. Entrambe sono visibili nello stesso comando: l'interfaccia nominata nell'output sarà il tunnel, e la correzione spetta a chi possiede quel piano di indirizzamento.

Selezione della rotta e ammissione dei pacchetti sono decisioni diverse

Questa è la parte che il modello mentale di solito trascura. Anche con una rotta locale perfetta, un client VPN può rifiutare il pacchetto. Molti client applicano una politica di accesso locale alla rete che decide quali destinazioni sono consentite fuori dal tunnel, e una sottorete connessa non aggiorna quell'elenco automaticamente.

Così il guasto sembra identico a un problema di routing dal lato dell'applicazione, e del tutto diverso dal lato del client. Se ip route get nomina l'interfaccia giusta e la connessione scade comunque, smettete di modificare rotte e leggete invece il comportamento documentato di accesso locale del client. Alcuni client espongono una lista di autorizzati per le sottoreti locali, altri bloccano tutto ciò che non è il tunnel, e altri bloccano solo quando è attivo un kill switch.

Questa distinzione conta perché le correzioni non sono intercambiabili. Aggiungere una rotta non soddisfa un filtro, e disattivare un filtro per raggiungere un solo ospite è una decisione molto più grande di quanto suggerisca il sintomo.

L'ospite ha tre modi per dire di no

Un ospite che può navigare su internet non ha dimostrato nulla sul servizio che volete. Il listener può essere legato a 127.0.0.1 dentro l'ospite, e in quel caso nessuna richiesta dall'host può arrivare, per quanto buono sia il percorso. Verificate con ss -ltn nell'ospite e guardate la colonna dell'indirizzo locale, non solo la porta.

Poi c'è il firewall dell'ospite stesso. Un'immagine di sviluppo con un valore predefinito restrittivo può accettare i pacchetti dell'host e scartarli al confine del servizio, il che produce un timeout che sembra esattamente un buco nero di routing. Infine c'è la configurazione del servizio stesso: un'applicazione web legata a un nome host specifico, o una lista di indirizzi client consentiti, rifiuterà una richiesta dalla sottorete host-only anche quando arriva ogni pacchetto.

Esaminate questi tre punti prima di considerare di cambiare la modalità di rete della VM. Ciascuno è un cambiamento più piccolo che ripensare il collegamento dell'ospite, e ciascuno ha un test chiaro.

Cos'è davvero un bridge, e quanto costa

Passare l'adattatore in modalità bridge non è una riparazione del percorso host-only. È la decisione di mettere l'ospite su un'altra rete, di solito la LAN fisica, dove diventa visibile a tutto il resto che vive lì. Potrebbe essere esattamente ciò che volete. Ma non è ciò che faceva la configurazione originale.

Usatelo quando l'ospite deve davvero essere un pari su quella LAN e l'esposizione è approvata. Non usatelo perché un singolo servizio ha smesso di rispondere, dato che il cambiamento può togliere l'ospite dall'isolamento che rendeva sicuro sviluppare su di esso.

Dopo ogni correzione approvata, provate in un ordine fisso: una nuova richiesta dall'host all'ospite, una risorsa aziendale necessaria attraverso il tunnel, e il comportamento di rifiuto previsto con il tunnel abbassato. Se l'ultimo non vale più, la correzione è andata oltre il problema.

La sezione di VirtualBox sul networking host-only descrive l'interfaccia software lato host e in cosa differisce da un collegamento in bridge, che è il riferimento da leggere prima di supporre che le due modalità siano intercambiabili.