Perché l’ordine degli adattatori non decide la rotta VPN del laboratorio

Che l’adattatore 1 sia il primo nell’elenco dell’hypervisor è solo un ordine di visualizzazione, e la tabella di routing dell’ospite non lo legge. A decidere il percorso sono il prefisso, la metrica e qualsiasi regola di policy che si applichi prima di entrambi. Aggiungere un adattatore bridge a una VM di laboratorio può quindi creare un secondo percorso predefinito mentre la vecchia interfaccia NAT appare ancora come presente e numerata seconda. Il risultato è una VM che a volte usa il tunnel e a volte no, senza alcuna modifica di configurazione che lo spieghi.

Tre condizioni decidono il percorso

Le tre condizioni sono quale prefisso è più specifico, cosa fanno le metriche quando i prefissi sono pari e quali regole ha applicato l’ospite dopo la modifica hardware. A ciascuna si risponde con un solo comando, e nessuna riguarda la numerazione dell’hypervisor.

Proprio quest’ultimo punto è la decisione: se non sapete dire quale prefisso vince per l’indirizzo del punto di terminazione VPN stesso, non avete una policy di routing, avete una topologia che oggi funziona per caso.

Prima condizione: quale prefisso vince

Una rotta verso 10.8.0.0/24 batte una rotta predefinita per un indirizzo al suo interno, indipendentemente dalle metriche e dall’ordine degli adattatori. Per questo un client VPN che installa una rotta specifica continua a funzionare anche quando compare un secondo adattatore con metrica più bassa: la specificità vince prima che si consideri il costo. Verificate con ip route show la tabella che credete in uso, e con ip route get 203.0.113.9 la risposta che il kernel darebbe davvero per una destinazione precisa.

L’indirizzo del punto di terminazione stesso è il test che conta di più. Se l’indirizzo del server VPN si risolve attraverso un adattatore bridge appena aggiunto, il tunnel potrebbe non stabilirsi mai, oppure stabilirsi e poi perdere il proprio percorso di trasporto. Interrogate specificamente quell’indirizzo invece di dare per scontato che l’interfaccia del tunnel sia la risposta.

Seconda condizione: cosa fa la metrica e cosa non fa

Il suo ruolo è più stretto di quanto la maggior parte si aspetti. Le metriche risolvono i pareggi tra rotte verso lo stesso prefisso; non permettono a una rotta più ampia di battere una più specifica. In caso di pareggio si preferisce il numero più basso, e sistemi operativi diversi contano in direzioni opposte, per questo i consigli copiati tra Linux e Windows spesso si contraddicono.

Nell’ospite ip route show stampa la metrica accanto a ogni rotta, e Get-NetRoute su Windows stampa un InterfaceMetric più una metrica di rotta. Leggete entrambi, perché la preferenza effettiva può essere una somma e non un solo campo. Se esistono due rotte predefinite, questo è il risultato: l’ospite ha due uscite, e quale vince dipende da numeri che una modifica hardware può cambiare.

Terza condizione: cosa ha davvero applicato l’ospite

La configurazione non è la stessa cosa dello stato applicato. I nomi delle interfacce non sono stabili tra modifiche hardware su ogni piattaforma, e una configurazione che corrispondeva per nome ora potrebbe non applicarsi a nulla.

Verificate lo stato applicato e non quello previsto. ip -br link mostra le interfacce che esistono ora, e su un host con NetworkManager nmcli connection show mostra quale profilo è legato a quale dispositivo. Un profilo che non è riuscito a legarsi lascia l’interfaccia attiva senza indirizzamento, cosa che sembra un problema di routing ed è un problema di denominazione. Gli snapshot ripristinati peggiorano la cosa, perché lo stato salvato dell’ospite può fare riferimento a identità di adattatore che il nuovo hardware non fornisce più.

Mantenete riproducibile la topologia del laboratorio

Salvate i collegamenti di rete virtuale previsti accanto alla configurazione dell’ospite, così la mappatura da ruolo ad adattatore è scritta invece che dedotta da una posizione nell’elenco.

Di solito bastano quattro ruoli da nominare: collegamento privato, gestione, trasporto esterno e tunnel. Ognuno dovrebbe corrispondere a un adattatore preciso e a un’interfaccia ospite precisa, in un file.

Poi provate l’applicazione reale dopo una modifica hardware, un riavvio o uno snapshot ripristinato, e includete la rotta verso il punto di terminazione VPN in quella prova. Se una VM gateway deve essere l’unica uscita, verificate che la VM di prova non abbia un secondo percorso predefinito indesiderato, perché un adattatore bridge aggiunge esattamente un secondo percorso predefinito. Provate dall’ospite, non dalla console dell’hypervisor, dato che i due possono non essere d’accordo su quale interfaccia sia quale.

La documentazione di rete di VirtualBox descrive le modalità degli adattatori e a cosa si collega ciascuno, ed è la parte che vale la pena leggere prima di aggiungerne un secondo. Un laboratorio che identifica quale adattatore serve ogni ruolo rende spiegabile un cambio di rotta. Un laboratorio che si affida alla numerazione dell’hypervisor trasforma ogni modifica in un esperimento.