VPN nel guest e VPN sull’host: quale rotta vince davvero

Due client girano insieme, ciascuno convinto di possedere la rotta predefinita, e il sintomo arriva come qualcosa di strano: un’applicazione del guest funziona, un’altra si risolve nel posto sbagliato. Un VPN dentro un guest e un VPN sull’host possono convivere, ma solo quando il percorso esterno e la politica interna concordano su chi trasporta cosa. Avviarli entrambi non crea una catena di per sé. Annota prima il collegamento, poi cambia una cosa alla volta.

Annota prima il collegamento del guest

Il guest raggiunge il suo server VPN attraverso il percorso che l’hypervisor gli ha dato: NAT dietro l’host, un bridge sul segmento fisico o una rete solo host con routing aggiunto sopra. Ogni collegamento cambia ciò che il guest può vedere e ciò che l’host può fare al suo traffico. Sotto NAT i pacchetti del guest sembrano arrivare dall’host, così il tunnel dell’host può trasportarli senza che il guest ne sappia nulla. Sotto un bridge il guest ha una propria presenza sul segmento e un proprio gateway predefinito.

Annota il collegamento prima di toccare qualsiasi configurazione, insieme a quale client deve trasportare quale applicazione. Quella frase risolve la maggior parte di questi casi, perché i due client sono di solito costruiti su presupposti diversi. Un guest che deve usare il tunnel dell’host non deve avere anche una propria rotta predefinita concorrente.

Segui l’endpoint del guest verso l’esterno

Un VPN del guest ha bisogno di un percorso utilizzabile verso il proprio server prima che qualsiasi altra cosa funzioni. Quando il tunnel dell’host è attivo e il guest sta dietro NAT, l’handshake del guest esce dal tunnel dell’host, che è o il progetto o un incidente che nessuno ha documentato. Quando il tunnel dell’host cade e il guest dipendeva da esso, il guest perde la connettività senza un solo cambiamento dalla sua parte. Seguire l’endpoint verso l’esterno ti dice quale dei due casi hai davvero.

Una rotta ampia in entrambi i contesti cattura traffico che l’altro client si aspettava. Una rotta 0.0.0.0/0 dentro il guest e un client host con tunnel completo rivendicano entrambi tutto, e vince quello che si applica per ultimo. Le sovrapposizioni tra le reti virtuali del guest, la LAN locale e le reti remote producono lo stesso effetto per i prefissi privati, con guasti che assomigliano a problemi di autenticazione; il comportamento di traduzione degli indirizzi è quello descritto per le reti dei container.

Confronta una registrazione prima e dopo

Prendi una linea di base con il tunnel dell’host spento, o in qualunque stato controllato che la tua politica consenta, e annota la rotta e il resolver del guest. Poi applica la configurazione combinata e confronta le due registrazioni, mantenendo intatti i requisiti di privacy. Se una linea di base diretta non è appropriata, scrivi quel limite nella registrazione invece di saltare il confronto.

ip route get 10.20.30.41
ip rule show
resolvectl status --no-pager | head -12

La query di rotta nomina l’interfaccia e l’indirizzo di origine che trasporterebbero una destinazione specifica, ed è la riga più utile di questa indagine. L’elenco delle regole mostra se il routing per policy manda alcune destinazioni attraverso una seconda tabella. L’output del resolver mostra se il DNS ha seguito il tunnel del guest o è rimasto sul percorso dell’host. Esegui gli stessi tre comandi prima e dopo la modifica, e il delta nomina il colpevole.

Mantieni chiara la proprietà tra i riavvii

La restrizione di accesso locale di un client host può bloccare il traffico verso un NAT virtuale o un bridge, e quella restrizione viene spesso confusa con un problema di credenziali del guest. Leggi il comportamento documentato del client invece di disattivare la restrizione per far passare un test. Dopo una correzione supportata, riprova l’applicazione del guest e la politica di errore che richiedi. Un host che si riconnette con successo non dimostra nulla sulla rotta o sul resolver del guest.

Decidi quale lato possiede la rotta predefinita e scrivilo nel manuale operativo. Un riavvio del guest o un cambio di rete sull’host che inverte silenziosamente la proprietà produce una segnalazione di bug su un VPN che non ha mai avuto colpa. L’accorgimento dovrebbe sopravvivere a un riavvio senza che nessuno ricordi perché funzionava.