Assistant serveur OpenVPN : réseau plus masque, jamais CIDR

Une ligne de serveur qui mélange un suffixe CIDR et un masque en pointillés arrête le démon avant même qu’il n’ouvre un port. L’assistant server pour IPv4 veut deux arguments distincts : une adresse réseau alignée, puis le masque de réseau sous forme pointillée. Tout le reste sur cette ligne relève de la déduction, et c’est là que les tailles de pool et les masques des clients se trompent.

Les deux arguments que l’assistant accepte

Écrivez d’abord le réseau, puis le masque, sans rien coller à l’adresse :

server 10.72.16.0 255.255.240.0

C’est la forme pour un /20. La ligne ci-dessous est l’erreur, et elle échoue à l’analyse des options, pas à l’exécution :

server 10.72.16.0/20 255.255.240.0

Gardez les deux idées séparées quand vous déboguez cela. Une longueur de préfixe et un masque pointillé décrivent la même étendue, mais l’assistant n’accepte pas les deux à la fois, et une ligne rejetée produit une erreur d’options qui nomme la directive plutôt que l’arithmétique.

Alignez le réseau avant de saisir le masque

La première adresse est l’adresse réseau de la plage, pas une adresse client commode à l’intérieur. Pour un /20, l’étendue va de 10.72.16.0 à 10.72.31.255, et seule la première est un argument réseau valide. Un /21 utilise 255.255.248.0 et couvre de 10.72.16.0 jusqu’à 10.72.23.255, donc sa ligne est server 10.72.16.0 255.255.248.0.

Changer le préfixe change l’étendue et rien d’autre. Cela ne change pas le nombre d’adresses qu’un seul client reçoit, car c’est une propriété de la topologie, pas du masque de cette ligne.

Confirmez le pool depuis le côté serveur

Lancez l’instance au premier plan avec une journalisation détaillée et lisez les lignes que l’assistant émet. Le pool qu’il a construit est imprimé au démarrage, ce qui est plus fiable que de calculer l’arithmétique à la main :

openvpn --config /etc/openvpn/server.conf --verb 4 --dev tun9 --port 1195

Cherchez le résumé du pool près du haut de la sortie. Il liste la plage que l’assistant a réservée, et si cette plage ne correspond pas à votre intention, les arguments de la ligne sont faux quoi que dise l’arithmétique du masque.

Connectez ensuite un client et trouvez la ligne qui enregistre l’adresse qui lui a été remise. Cette adresse unique, à côté de la plage du pool, vous dit si le client a atterri dans le bloc réservé ou ailleurs que vous ne l’attendiez. Si les deux ne concordent pas, corrigez les arguments plutôt que le client. S’ils concordent et que le client n’atteint toujours rien, le pool n’a jamais été le problème.

Lisez le masque du client en gardant la topologie en tête

Un client qui affiche un /30 sur son interface de tunnel n’est pas la preuve d’un pool cassé. En adressage point à point, chaque client reçoit un petit bloc et le masque de son interface décrit ce bloc, tandis que le pool du serveur couvre l’ensemble. En topologie de sous-réseau, le masque du client correspond au contraire au masque du pool. Le masque seul indique donc quelle topologie est en jeu, pas si le pool a été correctement écrit.

Vérifiez la topologie configurée et l’adresse attribuée ensemble avant de conclure :

ip -4 addr show tun0

Si l’adresse est dans le pool et que le masque est plus étroit que le pool, c’est la topologie qui fait son travail. Si l’adresse est hors du pool, le pool est faux, et aucune inspection côté client ne le corrigera.

Modifier un pool en service

Choisissez une plage qui ne chevauche ni le pool actuel, ni le LAN, ni aucune route déjà poussée vers les clients. Le chevauchement est la panne qui survit à un redémarrage puis, des jours plus tard, se manifeste par un site injoignable depuis une direction.

Modifiez la ligne, redémarrez et relisez le pool de démarrage avant de laisser revenir les utilisateurs. Si la nouvelle plage entre en collision avec quelque chose, la même sortie de démarrage le montre aussitôt, et un retour en arrière est une modification d’une ligne plus un autre redémarrage.

Gardez l’ancienne plage réservée quelque temps après le changement. Les clients qui se reconnectent tard peuvent encore détenir une adresse du pool précédent, et une nouvelle plage qui réutilise ces adresses produit des attributions en double qui ressemblent à une panne de routage. Le manuel OpenVPN 2.6 documente les arguments de l’assistant et son expansion, ce qui vaut la peine d’être lu avant de supposer qu’une directive adopte la même notation que sa voisine.