VPN guest su ESXi: routing o bridging, decidete prima del port group
Un TUN instradato richiede rotte di ritorno; un TAP in bridge richiede raggiungibilità di livello 2 e una politica del port group più ampia. Stabilite il ruolo prima di ampliare la modalità promiscua.
Instradate i pacchetti o estendete il dominio Ethernet: la modifica del port group segue quella scelta. Da un'applicazione con un indirizzo privato i risultati possono sembrare identici, mentre i requisiti dell'hypervisor non si somigliano affatto. Per questo il port group viene ampliato per primo e la domanda di progettazione trova risposta dopo, di solito dopo una tempesta di broadcast. Seguite questi controlli in ordine e fermatevi finché il requisito è ancora vago, perché nessuna impostazione del port group ripara un progetto che non è mai stato scelto.
La decisione spetta al proprietario del servizio; la configurazione dell'hypervisor deve attuarla, non determinarla per caso.
Verificate di cosa ha davvero bisogno l'estremità remota
Elencate i servizi che i client remoti devono raggiungere e i protocolli che usano. Se l'elenco è una manciata di servizi TCP su prefissi noti, il routing basta. Se qualcosa ha davvero bisogno di adiacenza di livello 2 — scoperta dipendente dal broadcast, protocolli non IP, un dispositivo che non accetta un gateway — il routing non può imitarlo e va detto presto. Siate onesti sulle voci non IP di quell'elenco, perché è lì che un progetto instradato fallisce in silenzio una settimana dopo.
Poi verificate il pool di client. Un progetto instradato richiede un intervallo di indirizzi e una rotta di ritorno esplicita dall'altra parte; un progetto in bridge richiede che il dominio Ethernet esteso possieda l'assegnazione degli indirizzi e l'isolamento. Qualunque cosa scegliate, qualcuno fuori da questa VM deve accettarla.
Cosa chiede ogni progetto alla rete virtuale
I due progetti differiscono in ciò che la rete virtuale deve tollerare, e la tabella è il modo più breve per vederlo:
| Progetto | Ruolo lato guest | Cosa deve assorbire la rete virtuale | Modalità di guasto se scegliete male |
|---|---|---|---|
| TUN instradato | Router tra prefissi separati | Un pool di client instradato più percorsi di ritorno dall'altra parte | I client raggiungono il gateway e non raggiungono mai il servizio dietro di esso |
| TAP in bridge | Bridge di livello 2 per i client che si uniscono | Identità Ethernet aggiuntive, traffico broadcast e regole VLAN | Lo vSwitch scarta frame, oppure il progetto richiede una modalità promiscua che nessuno ha approvato |
Il routing lascia il dominio di broadcast dov'è e offre un posto naturale per limitare quali servizi attraversano il gateway. Il bridging sposta il confine: i client diventano partecipanti del dominio Ethernet esteso, e assegnazione degli indirizzi, isolamento e qualsiasi politica di livello 2 ora valgono per loro. Scrivete la riga scelta nel registro delle modifiche. Una frase come «TUN instradato, pool di client 10.90.0.0/24, rotta di ritorno sul core» impedisce al prossimo ingegnere di riaprire il dibattito sul progetto partendo dalle impostazioni del port group.
Chi deve poter vedere i frame di chi
Ponete una domanda al proprietario della piattaforma prima di toccare il port group: il progetto richiede che questa VM riceva frame indirizzati ad altri partecipanti? Se la risposta è no, nulla in questa sezione si applica, perché un TUN instradato non ha mai bisogno di quella visibilità. Se la risposta è sì, la guida Broadcom sulla modalità promiscua è la lettura che conta: spiega quanto più dello vSwitch la VM può vedere e raccomanda di confinare quella politica a un solo port group.
Trattatelo come una verifica del requisito, non come un permesso. Attivate l'impostazione per un collegamento dedicato quando l'esigenza di bridge è scritta, e lasciatela disattivata ovunque altro. Un trunk VLAN ampio copiato da un altro esempio di bridge è la parte che nessuno ricorda di rimuovere, e un progetto a VLAN singola deve restare a VLAN singola.
Registrate quale port group è cambiato e perché, nello stesso posto in cui avete scritto la riga del progetto. È quella coppia a rendere possibile il prossimo audit.
Mantenete espliciti gli oggetti del guest
Dentro Linux, l'appartenenza al bridge e la proprietà dell'indirizzo sono oggetti separati, e confonderli causa lo stato confuso di semi-funzionamento. Assegnate gli indirizzi all'interfaccia del bridge o al tunnel instradato, non a entrambi i lati dello stesso percorso, e mantenete le porte membro libere da configurazione IP.
Evitate di mettere una subnet in modo indipendente su un TUN instradato e su un'interfaccia Ethernet non correlata. Quella configurazione produce due percorsi verso lo stesso prefisso, risposte asimmetriche e un thread di supporto sul flapping che non menziona nessuno dei due percorsi. Se il guest ospita anche container o un hypervisor locale, verificate che non stiano già facendo bridge verso lo stesso uplink. Due bridge su una NIC sono un progetto, non un incidente che volete scoprire durante una finestra di modifica.
Confermate con un percorso di pacchetto, non con un ping
Verificate il percorso reale, non solo la raggiungibilità. Da un client, confermate quale indirizzo sorgente arriva al servizio remoto, poi che la risposta torni per lo stesso percorso. Sul guest, controllate i contatori di inoltro per il flusso specifico, e sul port group confermate che non sia stata abilitata visibilità aggiuntiva oltre a quella richiesta dal progetto scelto.
Infine, provate la direzione del guasto. Fermate il tunnel o staccate il client e verificate che il traffico non ricada in silenzio su un percorso instradato che credevate inutilizzato, perché quella ricaduta è il modo in cui un progetto in bridge diventa in silenzio un router involontario.