Adreces de client OpenVPN estàtiques darrere d’OPNsense

Els noms necessiten adreces que no es moguin, i el fitxer de pool d’OpenVPN només fa que una adreça sigui enganxosa. Perdeu aquest fitxer, o reemeteu un certificat amb un nom comú diferent, i el client que torna aterra en un altre lloc del pool mentre el seu registre DNS encara apunta a l’adreça antiga. La resposta duradora és una substitució específica del client que fixa l’adreça, més una xarxa de túnel més àmplia perquè les adreces fixades quedin fora del rang dinàmic. L’aritmètica que hi ha darrere d’aquesta ampliació és on viu la major part de la confusió.

OPNsense guarda aquestes substitucions a la configuració específica del client del servidor, indexades pel nom comú del certificat, cosa que fa que el nom comú formi part del pla d’adreces.

Un arrendament enganxós no és una adreça estàtica

El fitxer de pool escriu mapes d’adreça a client i els torna quan un client conegut es reconnecta. Això és comoditat, no un contracte: el fitxer es pot regenerar, el mapa desapareix quan canvia la identitat del client, i dos servidors que comparteixen un pool no hi estaran d’acord. Una substitució específica del client funciona diferent, perquè l’adreça ve de la configuració i no de l’historial. També sobreviu a un reinici i a una reinstal·lació de l’aparell, sempre que la substitució es guardi amb la resta de la configuració.

L’alternativa dinàmica, connectar la VPN al DNS amb un script de connexió de client i actualitzacions dinàmiques, funciona i requereix un resolutor que accepti actualitzacions més un script a cada connexió. En un aparell estàs limitat als paquets que distribueix el fabricant, i normalment és aquí on s’atura aquest pla.

L’aritmètica /30 que ningú no gaudeix

Amb la topologia net30 per defecte, cada client rep el seu propi /30: la primera adreça utilitzable va al costat del servidor i la segona al client. Per tant, les substitucions han de quedar fora de la xarxa de túnel dinàmica del servidor, cosa que vol dir ampliar primer aquesta xarxa. Un servidor a 10.8.0.0/24 pot passar a 10.8.0.0/23, deixant la meitat de l’antic rang per als clients dinàmics i l’altra meitat per a les substitucions. Afegiu el /24 original com a xarxa local IPv4 addicional perquè el trànsit cap a les dues meitats entri al túnel.

Cada adreça de substitució ha de caure en una frontera /30, així que l’últim octet és múltiple de quatre. Un /30 a 10.8.1.0 dona al client 10.8.1.2, i aquesta és l’adreça que porta el registre DNS. Triar 10.8.1.3 en lloc seu produeix un client que es connecta i no pot passar trànsit, perquè l’adreça pertany a una subxarxa que la topologia mai li va assignar.

El pla és més fàcil de mantenir si les substitucions s’assignen des de dalt del rang ampliat cap avall, de manera que el pool dinàmic s’expandeixi cap a l’espai lliure en lloc de fer-ho al voltant d’illes fixes.

Xarxes locals i la zona que consulten els clients

El trànsit de client a client necessita el seu propi permís. La llista de xarxes locals IPv4 del servidor ha d’incloure les dues meitats del rang, dinàmica i estàtica; sense això, el servidor accepta un paquet d’un client i no té cap política que el deixi passar a un altre. El símptoma es llegeix com una fallada de DNS, perquè el nom es resol i la connexió encara falla. Comproveu alhora el paràmetre de client a client, ja que una entrada de xarxa local per si sola no habilita el reenviament entre iguals.

Publiqueu els registres a la zona que els clients remots consulten realment. Un registre en una zona servida només pel resolutor de la LAN és invisible per a un client el resolutor empès del qual apunta a un altre lloc, i afegir més registres a la zona equivocada no ho arregla mai. Confirmeu l’opció DNS empesa i el domini de cerca abans d’afegir res.

Què cal comprovar en una connexió nova

Reconnecteu el client i confirmeu que l’adreça assignada coincideix amb la seva substitució abans de provar res més. Després resoleu el nom des d’un segon client i connecteu-vos al servei pel nom, cosa que exercita alhora el registre DNS, la ruta i el tallafoc. Confirmeu el camí de resposta al costat del servidor, ja que un nom que es resol mentre el servei continua inaccessible és un problema d’encaminament o de política, no de noms. Mantingueu la taula de substitucions al costat de la llista de certificats perquè tots dos es revisin junts.

Un certificat reemès amb un nom comú diferent deixa de coincidir amb la seva substitució i retorna el client al pool dinàmic. Espereu-ho després de qualsevol canvi d’identitat.