La stessa sottorete su entrambi i lati: mappate la LAN remota su un intervallo libero

Casa e ufficio usano entrambi 192.168.1.0/24, quindi una richiesta a 192.168.1.1 ha due risposte possibili e il client ne sceglie una senza chiedere. Rinumerare una rete d'ufficio in funzione è raramente popolare, e gli indirizzi del router sono spesso incisi in stampanti, telecamere e documentazione. Una mappatura degli indirizzi lato client può invece presentare la rete remota sotto un intervallo libero, e la parte host può restare identica così che 192.168.1.20 appaia come 10.203.41.20. Il problema è che solo alcuni client la implementano, e non fa nulla per il percorso di ritorno.

Due viste dello stesso host

La mappatura conserva la parte host e cambia solo la parte di rete. La stessa macchina risponde allora a due indirizzi a seconda di dove ci si trova. Annotare entrambe le colonne prima di configurare qualsiasi cosa evita una lettura errata successiva dei log e delle regole del firewall.

I dispositivi locali di casa conservano i propri indirizzi 192.168.1.x, ed è questo il punto dell'esercizio. La stampante nella stanza accanto resta raggiungibile mentre l'ufficio appare sotto un intervallo che non entra in conflitto.

L'ordine degli argomenti è tutto il trucco

L'opzione accetta una direzione, una rete e una maschera, e un alias: la prima rete è ciò che vede il client, l'alias è ciò che vede il server. Per le risorse che vivono dietro il gateway remoto, la direzione è la forma di destinazione. Invertire le due reti perché l'ultimo argomento si chiama alias è l'errore che produce un tunnel che si connette e non mappa nulla.

push "route 10.203.41.0 255.255.255.0"
push "client-nat dnat 10.203.41.0 255.255.255.0 192.168.1.0"

La route è ciò che invia i pacchetti del client per il nuovo intervallo nel tunnel; la traduzione riscrive la destinazione lungo il percorso. Una risposta da 192.168.1.20 viene riscritta su 10.203.41.20 perché il socket sul client resti coerente. Un singolo host funziona allo stesso modo con una maschera a lunghezza piena, purché la route e la mappatura descrivano lo stesso indirizzo.

Questa è una mappatura di indirizzi, non una mappatura di porte. Due servizi su un solo host non si possono separare con essa, e un protocollo che incorpora indirizzi IP nel suo payload vedrà comunque quelli reali.

La mappatura non crea un percorso di ritorno

La traduzione avviene sul client, quindi il server deve ancora instradare le risposte verso il tunnel e il suo firewall deve ancora permetterle. Se il gateway remoto non sa come raggiungere la sottorete del tunnel, la richiesta arriva e la risposta esce dalla porta sbagliata; la mappatura fa solo sembrare il guasto un problema del client.

Le regole lato server dovrebbero descrivere gli indirizzi che esistono sul server dopo la traduzione, non l'intervallo visibile al client. Copiare l'alias in una regola di autorizzazione spreca un pomeriggio, perché nessun pacchetto da quel lato lo trasporta.

Scegliete un intervallo di alias che non entri in conflitto con nient'altro che il client instradi: un'altra VPN, una rete di container, un secondo ufficio. Un conflitto qui reintroduce l'ambiguità originale sotto un altro numero ed è più difficile da vedere perché gli indirizzi sembrano sconosciuti.

I nomi e i payload sopravvivono alla traduzione

Un nome host che si risolve nel vero 192.168.1.20 manda il browser sul dispositivo locale invece che su quello remoto, qualunque cosa dica la tabella di routing. La risposta del DNS privato deve puntare all'intervallo visibile al client, mentre il certificato TLS porta ancora il nome che l'applicazione si aspetta. Provate con il nome invece che con l'indirizzo, perché l'indirizzo può funzionare mentre il nome si risolve silenziosamente nella direzione sbagliata. Quando il gateway remoto serve anche quella zona, anche i suoi record hanno bisogno dell'intervallo visibile al client.

I reindirizzamenti, gli URL incorporati e le applicazioni che consegnano il proprio indirizzo in un payload possono rompersi in modi che nessuna mappatura di pacchetti può riparare. Trattateli come un problema dell'applicazione e dimensionate lo sforzo di conseguenza prima di promettere che rinumerare non serve.

Tre controlli prima di impegnarsi

Primo, confermate l'implementazione del client. Community OpenVPN supporta questa opzione; la base di codice di OpenVPN 3 la elenca tra le funzionalità non supportate, quindi un profilo inviato a un client in stile Connect può semplicemente ignorarla. Una direttiva accettata e mai applicata è peggio di un errore, perché il tunnel sembra sano.

Secondo, verificate la route e la traduzione separatamente con una breve finestra diagnostica ad alta verbosità, poi testate il servizio reale invece di un ping. Terzo, confermate che il router locale e la risorsa remota restino distinguibili dal client, perché era questo l'obiettivo iniziale.

Se il client non può fare la traduzione, chiedete aiuto al lato gateway o accettate una rinumerazione. Aggiungere altre route per lo stesso indirizzo non è una progettazione.