Lab domestico e tunnel diviso: instrada ciò che serve, non tutto

Il consiglio che un lab domestico richieda un tunnel completo di solito viene da un tutorial che ne aveva uno, non da un requisito. Lo split tunneling non è la versione compromessa di una VPN corretta; è la versione di cui sai spiegare la tabella di routing. Un lab con cinque servizi e un’interfaccia di gestione non ha bisogno che ogni pacchetto che esce di casa attraversi un tunnel. Ciò che gli serve è un inventario e una route per ogni voce di quell’inventario.

Il mito: lo split tunneling è un compromesso

Il mito sopravvive perché un tunnel completo è più facile da configurare una volta e più difficile da diagnosticare dopo. Questo scambio è ragionevole per un portatile su Wi-Fi pubblico e sbagliato per un rack in cantina.

Nasconde anche una seconda ipotesi: l’indirizzamento del lab non ha nulla in comune con la rete da cui ti connetti.

Inventaria le risorse prima delle route

Annota ogni sottorete del lab, il servizio che vi abita, il nome con cui la risolvi e chi è autorizzato a raggiungerla; le note di inoltro della tua gateway descrivono il percorso di ritorno su cui stai pianificando. Aggiungi gli intervalli dei container e gli intervalli LAN che il client remoto potrebbe già usare, perché la sovrapposizione è il guasto che questo inventario previene. Una route che copre ogni indirizzo privato entrerà in collisione con una rete domestica prima o poi. L’inventario è anche il piano di test, per questo vale la pena farlo prima della configurazione e non dopo.

Assegna a ogni risorsa un percorso: attraverso il tunnel, diretto o negato. Una risorsa senza percorso assegnato è quella che genera più tardi la domanda di supporto confusa.

Cinque righe e una colonna di decisioni battono una tabella di routing che nessuno riesce a leggere.

La gateway ha bisogno di un percorso di ritorno

L’inoltro sulla gateway è solo metà. Al lab serve una route di ritorno verso il pool di client, o una disposizione di traduzione supportata che renda possibile il ritorno. Se le risposte non trovano il client, il tunnel sembra connesso e ogni richiesta scade; è un sintomo di routing, non un guasto della VPN. Controlla il percorso di ritorno come parte del progetto, non come passo di risoluzione dei problemi.

Un pool di client che si sovrappone all’indirizzamento del lab è l’altra metà di questo problema, e fallisce esattamente allo stesso modo.

Correggi il piano, non i sintomi, quando i due intervalli si scontrano.

I ruoli di gestione e internet sono separati

Decidi se solo il traffico del lab usa il tunnel o se diventa anche un’uscita internet. Non aggiungere una route predefinita solo perché un tutorial ne usava una, perché quella decisione cambia dove vanno ogni query DNS e ogni controllo degli aggiornamenti. Conserva un percorso esterno verso l’endpoint VPN stesso, altrimenti il tunnel cercherà di portare la propria connessione esterna. Mantieni l’accesso di gestione stretto e raggiungibile tramite un metodo di recupero approvato.

Si può scegliere un DNS privato per i nomi del lab senza presumere che ogni query pubblica richieda lo stesso resolver. È una decisione sul resolver, non una decisione sulla route.

Tenerli separati è ciò che rende distinguibili più tardi le modalità di guasto.

Prova da fuori, non dalla LAN

Usa una connessione esterna autorizzata invece di un test dalla stessa LAN, perché un test dalla stessa LAN può nascondere del tutto una route di ritorno mancante. Verifica un indirizzo del lab, il suo nome host privato, una destinazione diretta prevista e il comportamento di guasto richiesto. Il caso di guasto conta quanto quello di successo: una risorsa che non dovrebbe essere raggiungibile deve esserlo davvero non raggiungibile. Registra tutti e quattro i risultati prima di dichiarare il progetto finito.

Poi salva la configurazione di route e DNS accanto all’inventario, con un proprietario nominato. Quando il lab guadagna un’altra sottorete, aggiorna entrambi e ritesta.

Una route inspiegata che si sovrappone a una rete domestica esistente è il risultato predefinito di saltare quel passaggio.

Il progetto finito è piccolo, documentato e noioso, che è esattamente ciò che un lab vuole dalla sua rete. La versione interessante è quella che si rompe mentre sei lontano da casa.