Perché la tua VPN guest fallisce dietro il NAT di VirtualBox?

Un browser dentro la macchina virtuale funziona, e il client VPN sullo stesso guest non riesce a trasportare dati. Il guest ha chiaramente connettività, quindi il guasto sta in ciò che richiede il protocollo esterno della VPN e in ciò che il NAT virtuale lascerà passare. Tre condizioni decidono l'esito: quale processo possiede la VPN, che aspetto ha lo scambio esterno sul filo e se la modalità dell'adattatore è quella che pensi. Nominare la condizione che puoi cambiare è tutta la decisione.

Individua il processo VPN prima di dare la colpa alla rete

Decidi prima se la VPN gira dentro il guest o sull'host, perché i due assetti falliscono in modo diverso. Un client dentro il guest costruisce la propria connessione esterna attraverso l'adattatore del guest e qualsiasi traduzione stia dietro. Una VPN dell'host cattura il traffico del guest secondo la politica dell'host e dell'hypervisor, che è un punto di cattura separato con le proprie regole. Possono girare insieme e confondere le prove, quindi identifica quella che dovrebbe trasportare questo traffico prima di toccare l'una o l'altra.

Annota ora la modalità dell'adattatore del guest, prima di cambiare qualsiasi cosa. Quel singolo valore spiega la maggior parte di ciò che segue, ed è la prima cosa che chiunque ti chiederà più avanti.

Lo scambio esterno decide la compatibilità

La guida di rete di VirtualBox elenca limitazioni del NAT che contano qui: non lascerà passare protocolli diversi da TCP e UDP, GRE è indicato come non supportato e PPTP è dato come esempio interessato. PPTP usa uno scambio di controllo TCP e GRE per i dati, quindi la connessione di controllo può riuscire mentre il percorso dati non può attraversare lo stesso confine. Sono due prove diverse, e solo una riguarda il trasporto del traffico. Consentire la porta TCP 47 in una regola del firewall non è lo stesso che consentire il protocollo IP 47, e i due vengono continuamente confusi.

Tieni la limitazione legata a questo assetto NAT e non a ogni dispositivo che usa la parola NAT. Un router fisico può lasciar passare GRE senza lamentarsi mentre il NAT virtuale lo scarta, e un altro hypervisor fa la propria scelta su ciò che inoltra. Dove l'organizzazione offre un trasporto approvato dentro TCP o UDP, usa il suo client e profilo supportati per quel percorso. La compatibilità è un requisito tra vari, e non stabilisce né la fiducia nel server né il permesso dell'account né rotte private funzionanti.

Cosa cambia davvero il bridge

Un bridge consegna l'indirizzo MAC del guest al segmento fisico invece di nasconderlo dietro la traduzione. Il guest prende allora un indirizzo da qualunque server DHCP che serve quel segmento, risponde ARP per quell'indirizzo e appare allo switch a monte come una porta in più. Questo elimina il percorso di traduzione virtuale, che è esattamente il motivo per cui una vecchia ricetta lo consiglia, e cambia altre tre cose nello stesso momento. L'indirizzamento ora viene dal segmento locale e non dall'hypervisor, l'esposizione significa che il guest è visibile a quel segmento, e l'ammissione dipende dalla porta dello switch e dalla sua politica. Ognuna di queste può essere un motivo per rifiutare il cambiamento, e nessuna riguarda il protocollo VPN.

Il bridging non installa un plugin mancante, non fornisce un agente segreto non disponibile e non ripara un rifiuto dell'autenticazione. Non rende nemmeno un protocollo obsoleto una buona scelta, e dove l'operatore ha un sostituto mantenuto, la decisione è quello e non cambiare l'hypervisor. L'inoltro di porta è un terzo ruolo del tutto: pubblica un servizio in ingresso e non fa nulla per il protocollo esterno di un client in uscita.

Due tunnel, due tracce di prove

Una VPN guest ha bisogno di un percorso utilizzabile dall'interfaccia del guest al suo peer prima che qualsiasi indirizzo interno o rotta privata conti. Dove è presente una VPN dell'host, può inoltrare o bloccare quello scambio esterno secondo la propria politica, e il tunnel interno del guest inizia solo dopo che quello esterno riesce. La copertura di nessuno strato può essere letta da una singola icona connessa né dall'indirizzo pubblico del browser dell'host.

Conserva il primo messaggio di errore e non l'ultimo, perché il guasto più precoce nomina lo strato. Cambia un assetto di rete supportato alla volta, con lo stesso profilo guest e le stesse credenziali, così che il confronto significhi qualcosa. Decidi dal guasto quale fase si è rotta: integrazione locale, trasporto, autenticazione o accesso alle risorse una volta alzato il tunnel. Ognuna ha un proprietario diverso, e solo una è una questione di hypervisor.

Quale condizione ti blocca davvero

Ormai la decisione si restringe a tre domande con risposte diverse. Se il protocollo esterno sta fuori da TCP e UDP, la modalità NAT è il vincolo, e la via davanti è il bridge o un trasporto TCP/UDP approvato. Se lo scambio esterno si completa e il percorso dati no, il vincolo è lo stesso visto nella seconda prova. Se il tunnel si alza e le risorse non rispondono, il problema è già passato oltre l'hypervisor verso l'instradamento o la politica.

Scrivi la risposta con la modalità dell'adattatore accanto, altrimenti la persona successiva ripeterà lo stesso pomeriggio. Prova l'applicazione reale e la risoluzione dei nomi dentro il guest dopo ogni correzione, poi riconnettiti ed esercita la politica di guasto. Una pagina web che funziona attraverso il tunnel dimostra solo che il percorso web funziona, che è un'affermazione più piccola di quanto sembri sul momento.