Serveur OpenVPN avec nopool : déclarez une plage de pool explicite

Les assistants du serveur configurent un sous-réseau puis le remplissent avec un pool dynamique de leur choix. Ce comportement par défaut reste commode jusqu’à ce que certaines adresses doivent rester hors de l’attribution, qu’elles soient réservées à des affectations fixes ou gardées pour un segment futur. Supprimer le pool automatique et déclarer soi-même la plage demande deux lignes et une décision réfléchie sur les adresses qui ne sont pas destinées à l’attribution. Le reste est de la discipline opérationnelle : inventaire, application, vérification, retour arrière.

Il s’agit d’une modification d’un service en production, alors traitez-la comme une tâche opérationnelle : inventaire d’abord, application par le cycle de vie habituel, vérification avec un nouveau client et retour arrière préparé.

Partez du sous-réseau que vous avez déjà

Lisez la configuration actuelle du serveur et les adresses que les clients détiennent réellement. Le changement de pool n’a de sens que par rapport à cette référence, et la référence n’est pas toujours ce que le fichier suggère, car un produit géré ou un générateur de configuration peut posséder le fichier que vous lisez.

grep -nE '^(topology|server|ifconfig-pool|max-clients|client-config-dir)' /etc/openvpn/server/lab.conf
ip -4 addr show tun0

Confirmez la topologie en vigueur. En topologie de sous-réseau, chaque client prend une adresse du pool ; les anciennes dispositions net30 allouent un petit bloc par client et l’arithmétique est complètement différente. Si le serveur est encore en net30, cette page est le mauvais guide de migration et les numéros du pool ne signifieront pas ce que vous attendez. Vérifiez cette ligne avant de copier une arithmétique d’adresses d’ailleurs.

Notez l’adresse du serveur lui-même, chaque affectation fixe du répertoire de configuration des clients et toute adresse dont dépend une route ou une règle d’accès. Ce sont les adresses qui doivent rester hors de la plage dynamique. Les écrire d’abord, c’est ce qui fait de la plage une décision plutôt qu’une supposition. Cela donne aussi au retour arrière quelque chose de concret à restaurer.

Ajoutez nopool et déclarez la plage

Le mot-clé assistant accepte nopool, qui conserve la configuration du sous-réseau et supprime le pool dynamique automatique, comme le décrit le manuel d’OpenVPN 2.6. La ligne explicite ifconfig-pool fournit ensuite la plage inclusive visée, et son masque de réseau correspond au sous-réseau. Les deux lignes appartiennent au même bloc de serveur, car un pool sans son sous-réseau n’a aucun sens. L’ordre entre elles n’importe que pour la lisibilité, puisque l’assistant déploie la paire au démarrage du service.

topology subnet
server 10.70.0.0 255.255.255.0 nopool
ifconfig-pool 10.70.0.50 10.70.0.120 255.255.255.0

Les deux bornes sont incluses, l’exemple propose donc soixante et onze adresses. Gardez l’adresse du serveur et chaque affectation fixe hors de cette étendue ; une affectation fixe qui tombe dans la plage dynamique produit une collision qui dépend de l’ordre des connexions, le pire type à déboguer. Laissez une marge entre l’ensemble réservé et la plage si les affectations fixes risquent de croître.

La taille de la plage et la simultanéité sont deux limites distinctes. Cent adresses ne signifient pas cent clients simultanés si max-clients dit le contraire, et un pool plus grand que la limite de simultanéité est normal plutôt que du gaspillage. L’important est que les deux limites soient choisies délibérément au lieu d’être héritées d’une valeur par défaut.

Gardez les affectations fixes hors de la plage dynamique

Un ifconfig-push propre à un client est un mécanisme différent de l’attribution par le pool, et il doit utiliser des paramètres adaptés à la topologie active. En mode sous-réseau, c’est une seule adresse et un masque de réseau ; reporter une paire net30 parce qu’elle figurait dans un vieil exemple est une erreur fréquente.

L’historique d’attribution est un indice, pas une autorité. Un fichier persist retient quel client avait quelle adresse, si bien que les clients qui se reconnectent ont tendance à recevoir la même, et il ne réserve pas d’adresses, ne les libère pas et ne remplace pas une affectation fixe. Si un appareil précis doit toujours détenir une adresse précise, utilisez une affectation fixe plutôt que de compter sur le fichier persist.

Vérifiez ensuite les chemins qui dépendent des adresses. Une route poussée aux clients, une règle de pare-feu qui admet un sous-réseau ou un contrôle de supervision qui attend un hôte particulier peuvent tous présumer l’ancienne plage. Changer le pool sans les lire déplace la panne vers un endroit qui semble sans rapport.

Appliquez par le cycle de vie, puis vérifiez

Appliquez le changement comme le service reçoit habituellement sa configuration, qu’il s’agisse d’un fichier direct suivi d’un redémarrage ou d’une couche de gestion qui régénère le fichier. Une modification manuelle d’un fichier généré survit jusqu’à la génération suivante, et pas plus longtemps. Notez quel mécanisme possède le fichier, car l’opérateur suivant devra savoir où faire le même changement. Redémarrez ensuite une fois et lisez le journal avant d’inviter un client.

systemctl restart openvpn-server@lab
journalctl -u openvpn-server@lab -n 30 --no-pager
# on a fresh client
ip -4 addr show tun0

Connectez un client qui ne l’était pas auparavant et confirmez que l’adresse tombe dans la plage déclarée et hors de l’ensemble réservé. Confirmez ensuite le chemin de retour : le client doit atteindre ce que la politique autorise et rien de plus. Une adresse conforme au plan mais sans route fonctionnelle n’est pas un changement réussi.

Reconnectez un client qui détenait une adresse de l’ancienne plage. Il devrait recevoir une adresse de la nouvelle plage, et tout état au niveau de la session lié à l’ancienne adresse devrait avoir disparu. S’il conserve l’ancienne adresse, quelque chose d’autre la lui attribue et le pool n’est pas le propriétaire que vous croyez.

Revenir sur un changement de plage

Conservez les trois lignes précédentes dans votre journal de changement, pas seulement le fichier précédent. Les restaurer et redémarrer ramène l’attribution à l’ancien comportement, et les clients qui se reconnectent ensuite en recevront des adresses.

Deux mises en garde figurent dans le journal. Les clients déjà connectés au moment du retour arrière conservent leurs adresses actuelles jusqu’à leur reconnexion, si bien qu’un retour arrière n’est pas instantané sur toute la flotte. Et si l’ancienne plage chevauchait une affectation fixe, la restaurer restaure aussi la collision ; ce chevauchement est la raison du changement, et il exige un correctif différent d’un retour arrière.

Un changement de pool est terminé quand un nouveau client reçoit une adresse dans la plage, qu’une adresse réservée n’est jamais distribuée et que les routes et règles qui consomment ces adresses se comportent toujours comme prévu. Tout le reste laisse la personne suivante découvrir laquelle des trois est fausse.