SoftEther SecureNAT: DHCP e NAT sono due decisioni

SecureNAT è un’unica casella di controllo che attiva due servizi, ed è qui la fonte della maggior parte della confusione che lo riguarda. Un server DHCP virtuale assegna al client un indirizzo, una maschera, un gateway e spesso un resolver. Un NAT virtuale inoltra i pacchetti oltre quel gateway usando la pila di rete dell’host del server. I due stanno fianco a fianco nella configurazione e falliscono in modo indipendente: un client può avere un lease perfetto e nessun percorso funzionante, oppure un percorso funzionante con impostazioni che puntano al resolver sbagliato. Verificali come due decisioni e la diagnosi diventa breve.

Due servizi dietro una casella di controllo

Il lato DHCP virtuale risponde a una domanda di configurazione: quali impostazioni riceve questo client all’interno di questo hub virtuale. Il lato NAT virtuale risponde a una domanda di inoltro: quando un client invia un pacchetto a un indirizzo esterno all’hub, il server lo traduce e lo inoltra. Il primo è locale all’hub e non richiede alcuna rete a monte. Il secondo dipende interamente dall’host.

L’interfaccia host virtuale appartiene alla prima decisione, non alla seconda. Il suo indirizzo, spesso qualcosa come 192.168.30.1 per impostazione predefinita, è il gateway offerto dal servizio DHCP. Non è l’indirizzo di ascolto pubblico del server, e confondere i due produce regole del firewall e impostazioni client dirette a una macchina che non esiste su quella rete.

Decisione 1: chi fornisce l’indirizzo

Se il DHCP virtuale è attivo, i client dovrebbero ricevere un lease nel pool configurato, con l’interfaccia host virtuale come gateway e il resolver fornito. Ispeziona il lease e non il testo di stato del client, perché «connesso» descrive il tunnel e non l’assegnazione dell’indirizzo:

vpncmd localhost /SERVER /CMD SecureNatStatusGet
vpncmd localhost /SERVER /CMD DhcpGet
ip -4 addr show
ip route

Due modalità di guasto vale la pena conoscerle prima di eseguire il debug di qualunque altra cosa. Un client con un indirizzo statico residuo di un progetto precedente lo conserverà e ignorerà il lease, cosa che sembra un DHCP che rifiuta di rispondere. E una seconda fonte DHCP su un segmento in bridge gareggerà per gli stessi client, producendo indirizzi intermittenti e una coda di supporto che non riesce a riprodurre il problema.

Anche i pool sovrapposti rientrano qui. Se il pool del DHCP virtuale si sovrappone alla sottorete LAN dell’host o al pool di un altro hub, il client riceve un indirizzo che viene instradato in modo ambiguo, e ogni test successivo non è conclusivo.

Decisione 2: chi inoltra oltre il gateway virtuale

Con il NAT virtuale attivo, il traffico in uscita dall’hub viene tradotto dal server e inviato attraverso la tabella di routing dell’host. Ciò significa che la catena di inoltro è: client verso il gateway virtuale, NAT virtuale verso la pila dell’host, pila dell’host verso la sua rotta predefinita. Ogni anello può fallire senza toccare gli altri, e le firme di guasto sono diverse.

Metti alla prova la seconda decisione con qualcosa che deve uscire dall’hub, non con qualcosa di locale ad esso. Fare ping al gateway virtuale dimostra il primo anello e nulla di più:

vpncmd localhost /SERVER /CMD NatGet
vpncmd localhost /SERVER /CMD NatTable
dig +short example.com
ip route get 203.0.113.10

Se la risoluzione dei nomi funziona ma le connessioni a un indirizzo pubblico falliscono, sei nella catena di inoltro e non nel DHCP. Se falliscono entrambe, controlla prima il resolver, perché un resolver spinto come indirizzo interno irraggiungibile farà sembrare un percorso funzionante del tutto rotto.

L’inoltro di SecureNAT è implementato dal processo del server, non dal percorso di inoltro del kernel che useresti con un bridge. È comodo e più lento del bridging, e significa anche che le regole del firewall e le decisioni di routing dell’host valgono ancora per il traffico tradotto. Il NAT virtuale non aggira la politica dell’host; la usa.

Il percorso proprio dell’host è una terza cosa

Tutto quanto sopra presuppone che l’host del server possa raggiungere la destinazione. Un host senza una rotta a monte funzionante, con una politica in uscita restrittiva o con una famiglia di indirizzi che non possiede fallirà la seconda decisione, per quanto corretta sia la configurazione dell’hub. Controlla l’host per conto suo, fuori dal tunnel, prima di attribuire il suo guasto a SoftEther.

SecureNAT non è nemmeno un’autorizzazione a raggiungere ogni rete collegata al server. Traduce e inoltra il traffico che lo raggiunge; decidere a cosa l’host può arrivare resta compito del firewall e del routing dell’host, e un progetto che si affida al tunnel per concedere l’accesso è a una regola sbagliata dal concederne troppo.

Le famiglie di indirizzi meritano un controllo a sé. Un esempio IPv4 DHCP funzionante non stabilisce che ogni capacità IPv6 sia presente nella tua build, quindi leggi il manuale per la versione che esegui davvero prima di promettere un comportamento dual-stack. La sezione SecureNAT del manuale copre le funzioni NAT e DHCP virtuali per la release attuale.

Verifica ogni decisione con il suo test

Accetta la prima decisione con un controllo del lease: indirizzo nel pool, gateway uguale all’interfaccia host virtuale, resolver quello configurato. Accetta la seconda con una richiesta in uscita dal client e uno sguardo alla tabella NAT sul server, perché un numero di sessioni crescente è l’unica prova diretta che la traduzione avviene e non solo che è abilitata.

Poi annota la separazione nella nota di progetto: quale componente fornisce l’indirizzo, quale componente inoltra e da quale interfaccia host esce il traffico. Quando un riavvio cambia il comportamento, quella nota ti dice quale dei tre ispezionare invece di riavviare tutto sperando che il sintomo si sposti.

Una decisione in più appartiene al registro, anche se oggi non la prendi: SecureNAT e un bridge locale sono progetti diversi per lo stesso hub, e un hub che ha bisogno di entrambi è un hub che ha bisogno di un altro piano. Scegli deliberatamente, annota il perché, e la prossima persona non dovrà ricostruirlo al contrario da una configurazione in esecuzione.