Indirizzi client OpenVPN statici dietro OPNsense

I nomi hanno bisogno di indirizzi che non si spostano, e il file pool di OpenVPN rende un indirizzo solo appiccicoso. Perdi quel file, o riemetti un certificato con un nome comune diverso, e il client che ritorna atterra altrove nel pool mentre il suo record DNS punta ancora al vecchio indirizzo. La risposta duratura è una sovrascrittura specifica del client che fissa l’indirizzo, più una rete tunnel più ampia in modo che gli indirizzi fissati stiano fuori dall’intervallo dinamico. L’aritmetica dietro quell’ampliamento è dove vive la maggior parte della confusione.

OPNsense conserva queste sovrascritture nelle impostazioni specifiche del client sul server, indicizzate per nome comune del certificato, il che rende il nome comune parte del piano degli indirizzi.

Una locazione appiccicosa non è un indirizzo statico

Il file pool scrive mappature indirizzo-client e le restituisce quando un client noto si riconnette. È una comodità, non un contratto: il file può essere rigenerato, la mappatura scompare quando cambia l’identità del client, e due server che condividono un pool non saranno d’accordo. Una sovrascrittura specifica del client funziona diversamente, perché l’indirizzo viene dalla configurazione e non dalla cronologia. Sopravvive anche a un riavvio e a una reinstallazione dell’appliance, purché la sovrascrittura sia salvata insieme al resto della configurazione.

L’alternativa dinamica, collegare la VPN al DNS con uno script di connessione client e aggiornamenti dinamici, funziona e richiede un resolver che accetti gli aggiornamenti più uno script a ogni connessione. Su un’appliance sei limitato ai pacchetti forniti dal produttore, ed è di solito lì che quel piano si ferma.

L’aritmetica /30 che nessuno gradisce

Con la topologia net30 predefinita, ogni client riceve il proprio /30: il primo indirizzo utilizzabile va al lato server, il secondo al client. Le sovrascritture devono quindi stare fuori dalla rete tunnel dinamica del server, il che significa ampliare prima quella rete. Un server su 10.8.0.0/24 può passare a 10.8.0.0/23, lasciando metà del vecchio intervallo ai client dinamici e l’altra metà alle sovrascritture. Aggiungi il /24 originale come rete locale IPv4 aggiuntiva, così il traffico verso entrambe le metà entra nel tunnel.

Ogni indirizzo di sovrascrittura deve cadere su un confine /30, quindi l’ultimo ottetto è un multiplo di quattro. Un /30 su 10.8.1.0 dà al client 10.8.1.2, e questo è l’indirizzo che il record DNS porta. Scegliere invece 10.8.1.3 produce un client che si connette e non riesce a far passare traffico, perché l’indirizzo appartiene a una sottorete che la topologia non gli ha mai assegnato.

Il piano è più facile da mantenere se le sovrascritture vengono allocate dall’alto dell’intervallo ampliato verso il basso, così il pool dinamico si espande nello spazio libero invece che intorno a isole fisse.

Reti locali e la zona che i client interrogano

Il traffico da client a client ha bisogno di un proprio permesso. L’elenco delle reti locali IPv4 del server deve includere entrambe le metà dell’intervallo, dinamica e statica; senza di esso il server accetta un pacchetto da un client e non ha alcuna policy che lo lasci passare a un altro. Il sintomo si legge come un guasto DNS, perché il nome si risolve e la connessione fallisce comunque. Controlla contemporaneamente l’impostazione da client a client, dato che una voce di rete locale da sola non abilita l’inoltro tra peer.

Pubblica i record nella zona che i client remoti interrogano davvero. Un record in una zona servita solo dal resolver della LAN è invisibile a un client il cui resolver spinto punta altrove, e aggiungere altri record alla zona sbagliata non lo ripara mai. Conferma l’opzione DNS spinta e il dominio di ricerca prima di aggiungere qualsiasi cosa.

Cosa controllare su una nuova connessione

Riconnetti il client e conferma che l’indirizzo assegnato corrisponda alla sua sovrascrittura prima di testare qualsiasi altra cosa. Poi risolvi il nome da un secondo client e connettiti al servizio per nome, il che mette alla prova insieme il record DNS, la rotta e il firewall. Conferma il percorso di risposta sul lato server, perché un nome che si risolve mentre il servizio resta irraggiungibile è un problema di routing o di policy, non di denominazione. Tieni la tabella delle sovrascritture accanto all’elenco dei certificati, così entrambe vengono riviste insieme.

Un certificato riemesso con un nome comune diverso smette di corrispondere alla sua sovrascrittura e riporta il client nel pool dinamico. Aspettatelo dopo ogni cambio di identità.