Due VPN su un solo computer Linux: provali separatamente senza mescolare i risultati

Due icone di connessione verdi sembrano un confronto e di solito sono una coincidenza. Se la richiesta di prova poteva usare uno dei due tunnel, il risultato descrive al meglio uno di essi e al peggio nessuno. Dai a ogni osservazione un contesto di rete, una destinazione prevista e un’aspettativa scritta prima che il test venga eseguito. Su una macchina Linux gestita da te, gli spazi dei nomi di rete con nome sono il modo più economico per comprare quella separazione.

Due luci verdi non sono un confronto

Uno spazio dei nomi separa tabelle di routing, interfacce e stato dello stack di rete, così una richiesta avviata dentro uno non può prendere in prestito in silenzio il tunnel di un altro. Ciò che non separa è una CPU, un collegamento fisico in salita o il demone resolver in esecuzione sull’host. È proprio in quest’ultima lacuna che la maggior parte di questi test fallisce senza che nessuno se ne accorga. Una ricerca che esce dallo spazio dei nomi e interroga il resolver dell’host restituisce una risposta senza alcun rapporto con il tunnel in prova.

Questa procedura presuppone due spazi dei nomi di prova già predisposti e approvati, con connettività esterna funzionante e client supportati. Non crea nulla, non registra nulla e non sostituisce alcuna configurazione. Le macchine virtuali separate restano la scelta onesta quando un client ha bisogno di una sessione desktop completa o rifiuta di funzionare fuori da una.

Fissa l’aspettativa prima della prima esecuzione

Decidi per ogni contesto come appare il successo: il resolver, il nome del servizio, l’indirizzo atteso e il comportamento richiesto quando il tunnel cade. Tieni quei valori pianificati nella loro colonna, perché un registro che mescola piano e osservazione è finzione con un timestamp. La lista di controllo qui sotto è la forma di cui il registro ha bisogno, e ogni riga deve poter essere compilata prima della prima connessione.

Il cablaggio del resolver merita una propria riga in quel registro, perché è il campo che più probabilmente mente. I file legati allo spazio dei nomi, come /etc/netns/vpn-a/resolv.conf compaiono ai loro percorsi abituali quando un comando viene eseguito dentro lo spazio dei nomi, come descrive la documentazione di iproute2 sugli spazi dei nomi, ma la configurazione della commutazione del servizio dei nomi e qualsiasi resolver locale che essa avvia possono ancora trascinare una ricerca di nuovo sull’host.

Un tunnel alla volta, l’altro disconnesso

Collega A tramite il suo proprietario esistente mentre B resta spento, poi esamina politica, rotte e percorso scelto dal contesto di amministrazione. Tre dei comandi qui sotto leggono lo stato; solo l’ultimo contatta un servizio dei nomi, e nessuno di loro invia una richiesta applicativa.

sudo ip -n vpn-a -4 rule show
sudo ip -n vpn-a -4 route show table all
sudo ip -n vpn-a -4 route get 10.55.10.20
sudo ip netns exec vpn-a getent ahostsv4 svc-a.lab.internal

Una ricerca di rotta risponde a una domanda ipotetica su una destinazione, quindi non può dimostrare che il servizio accetti traffico. Tieni questi due tipi di prova in colonne separate, perché una rotta sana accanto a una connessione rifiutata è un risultato reale e comune. Poi invia una richiesta autorizzata e innocua con l’applicazione reale, avviata nel contesto di A come il suo normale utente senza privilegi con la validazione dei certificati e l’autenticazione applicativa intatte, e registra l’esito insieme all’indirizzo sorgente che il servizio ha visto. Disconnetti A tramite il suo proprietario e ripeti l’intera linea di base per B, annotando ogni modifica di configurazione che fai, altrimenti le due linee di base smettono di essere confrontabili.

Entrambi su, poi uno giù alla volta

Lo stato stazionario è la parte facile. Con entrambi i tunnel connessi, ripeti la ricerca e la richiesta applicativa di ogni contesto, poi interrompi un tunnel e controlla l’altro. Riconnetti nella sequenza inversa quando è l’ordine di connessione stesso a essere la domanda.

sudo ip netns exec vpn-a tcpdump -ni any port 443 -c 5
sudo ip netns exec vpn-b getent ahostsv4 svc-b.lab.internal
sudo ip -n vpn-b -4 route get 10.55.20.20

La cattura risolve discussioni che un risultato applicativo non può: mostra se la richiesta è uscita dall’interfaccia che ti aspettavi o da qualcosa di completamente diverso. Per ogni transizione registra l’azione del proprietario, il timestamp, il risultato della rotta, il risultato del nome e l’esito dell’applicazione. Poi controlla il requisito di chiusura sicura dentro lo spazio dei nomi interessato, perché l’isolamento non è un interruttore di emergenza. Uno spazio dei nomi tiene separati due tunnel; non impedisce a nessuno dei due di portare traffico quando il suo profilo dice che il traffico deve fermarsi.

Cosa questo registro può e non può affermare

Una prova riuscita dimostra quelle osservazioni per questa disposizione, su questo host, in quel momento. Non dice nulla di due client che condividono una tabella di routing desktop, né del throughput mentre entrambi i tunnel portano carico. Sono domande separate con test separati, e un confronto vale quanto il contesto allegato a ogni riga.

Tieni i fallimenti nel registro accanto ai successi, etichettati con quale tunnel era attivo in quel momento. Una pagina pulita che nasconde lo stato al momento della misurazione è peggio di una brutta che lo mostra. Ciò che rende riutilizzabile il registro in seguito è il contesto, non il punteggio.

Due tunnel su una macchina possono essere confrontati onestamente, ma solo dentro tanti contesti quanti ne hai davvero controllati. Qualsiasi cosa oltre è un desiderio con un’icona verde accanto.