Adresses clients OpenVPN statiques derrière OPNsense

Les noms ont besoin d’adresses qui ne bougent pas, et le fichier de pool d’OpenVPN ne fait que rendre une adresse collante. Perdez ce fichier, ou réémettez un certificat sous un autre nom commun, et le client qui revient atterrit ailleurs dans le pool tandis que son enregistrement DNS pointe toujours vers l’ancienne adresse. La réponse durable est une surcharge propre au client qui épingle l’adresse, plus un réseau de tunnel plus large pour que les adresses épinglées sortent de la plage dynamique. L’arithmétique derrière cet élargissement est là où vit l’essentiel de la confusion.

OPNsense conserve ces surcharges dans les paramètres propres au client du serveur, indexés par le nom commun du certificat, ce qui fait du nom commun une partie du plan d’adressage.

Un bail collant n’est pas une adresse statique

Le fichier de pool écrit des correspondances adresse-client et les rend lorsqu’un client connu se reconnecte. C’est une commodité, pas un contrat : le fichier peut être régénéré, la correspondance disparaît quand l’identité du client change, et deux serveurs qui partagent un pool ne seront pas d’accord. Une surcharge propre au client fonctionne autrement, car l’adresse vient de la configuration et non de l’historique. Elle survit aussi à un redémarrage et à une réinstallation de l’appliance, à condition que la surcharge soit sauvegardée avec le reste de la configuration.

L’alternative dynamique, câbler le VPN dans le DNS avec un script de connexion client et des mises à jour dynamiques, fonctionne et exige un résolveur qui accepte les mises à jour, plus un script à chaque connexion. Sur une appliance, vous êtes limité aux paquets fournis par le vendeur, et c’est généralement là que ce plan s’arrête.

L’arithmétique /30 que personne n’apprécie

Avec la topologie net30 par défaut, chaque client reçoit son propre /30 : la première adresse utilisable va du côté du serveur, la seconde au client. Les surcharges doivent donc se situer hors du réseau de tunnel dynamique du serveur, ce qui suppose d’élargir d’abord ce réseau. Un serveur sur 10.8.0.0/24 peut passer à 10.8.0.0/23, laissant la moitié de l’ancienne plage aux clients dynamiques et l’autre moitié aux surcharges. Ajoutez le /24 d’origine comme réseau local IPv4 supplémentaire pour que le trafic vers les deux moitiés entre dans le tunnel.

Chaque adresse de surcharge doit tomber sur une frontière /30, donc le dernier octet est un multiple de quatre. Un /30 sur 10.8.1.0 donne au client 10.8.1.2, et c’est l’adresse que porte l’enregistrement DNS. Choisir plutôt 10.8.1.3 produit un client qui se connecte et ne peut pas faire passer de trafic, car l’adresse appartient à un sous-réseau que la topologie ne lui a jamais attribué.

Le plan est plus facile à tenir si les surcharges sont allouées du haut de la plage élargie vers le bas, afin que le pool dynamique s’étende dans l’espace libre plutôt qu’autour d’îlots fixes.

Réseaux locaux et la zone que les clients interrogent

Le trafic de client à client a besoin de sa propre autorisation. La liste des réseaux locaux IPv4 du serveur doit inclure les deux moitiés de la plage, dynamique et statique ; sans elle, le serveur accepte un paquet d’un client et n’a aucune règle qui le laisse passer vers un autre. Le symptôme se lit comme une panne DNS, car le nom se résout et la connexion échoue quand même. Vérifiez en même temps le réglage client à client, car une entrée de réseau local seule n’active pas le transfert entre pairs.

Publiez les enregistrements dans la zone que les clients distants interrogent réellement. Un enregistrement dans une zone servie uniquement par le résolveur du LAN est invisible pour un client dont le résolveur poussé pointe ailleurs, et ajouter davantage d’enregistrements à la mauvaise zone ne répare jamais cela. Confirmez l’option DNS poussée et le domaine de recherche avant d’ajouter quoi que ce soit.

Ce qu’il faut vérifier sur une nouvelle connexion

Reconnectez le client et confirmez que l’adresse attribuée correspond à sa surcharge avant de tester quoi que ce soit d’autre. Résolvez ensuite le nom depuis un second client et connectez-vous au service par nom, ce qui met à l’épreuve ensemble l’enregistrement DNS, la route et le pare-feu. Confirmez le chemin de retour côté serveur, car un nom qui se résout alors que le service reste injoignable est un problème de routage ou de stratégie, pas de nommage. Gardez la table des surcharges à côté de la liste des certificats pour que les deux soient revus ensemble.

Un certificat réémis sous un autre nom commun cesse de correspondre à sa surcharge et renvoie le client dans le pool dynamique. Attendez-vous à cela après tout changement d’identité.