ifconfig-push : adresse de pair en net30 ou masque de sous-réseau en subnet ?

Les clients dynamiques se connectent et le routage fonctionne, mais le seul client à adresse fixe n’atteint pas du tout le serveur. Rien n’a changé dans le pare-feu, et la ligne CCD paraît plausible. La cause habituelle est un deuxième argument écrit pour une topologie TUN différente de celle que le serveur exécute. La panne est silencieuse : le client monte avec une adresse et le serveur accepte la connexion, mais aucun trafic ne passe.

En net30, ce champ est une adresse de pair ; en subnet, c’est un masque de sous-réseau. Les deux formes sont des alternatives, jamais une séquence.

Les deux formes, côte à côte

Dans un déploiement net30 classique, chaque client possède un bloc /30 : une adresse réseau, deux adresses utilisables et une adresse de diffusion. ifconfig-push prend l’adresse du client et l’adresse de pair, et le pair est l’autre adresse utilisable du même bloc, utilisée par le côté serveur de la liaison point à point.

# net30: client address and its peer
ifconfig-push 10.99.0.6 10.99.0.5
# topology subnet: client address and the pool netmask
ifconfig-push 10.99.0.20 255.255.255.0

Sous topology subnet, le client partage un sous-réseau avec le serveur, et la même directive prend une adresse et un masque de sous-réseau. L’adresse du serveur lui-même vient de la directive server, pas du deuxième champ. Mélanger les formes produit un client qui croit être sur une liaison point à point alors que le serveur le route comme un hôte de sous-réseau, ou l’inverse. C’est pourquoi un masque de sous-réseau ne doit jamais être associé à net30.

Les deux lignes du bloc sont des lignes uniques pour un fichier CCD. Chaque client en reçoit exactement une.

Lisez la topologie que le serveur exécute réellement

Lisez la configuration en cours plutôt qu’une valeur par défaut du paquet, car la topologie a pu être définie il y a des années et recopiée. Cherchez topology subnet ou son absence, puis vérifiez comment la ligne server attribue les adresses. Une configuration qui ne mentionne jamais la topologie n’est pas la même qu’une qui définit subnet.

Lisez ensuite les paramètres reçus par le client. L’adresse, le masque et le pair qu’il rapporte indiquent quelle interprétation le serveur a appliquée.

Gardez l’adresse fixe hors du pool dynamique

Une adresse fixe doit se trouver hors du pool dynamique, sinon deux clients peuvent recevoir la même adresse. Avec la topologie subnet, nopool sur la ligne server supprime le pool automatique, et une plage ifconfig-pool explicite définit ce que les clients dynamiques reçoivent.

dev tun
topology subnet
server 10.99.0.0 255.255.255.0 nopool
ifconfig-pool 10.99.0.100 10.99.0.210 255.255.255.0
client-config-dir /etc/openvpn/ccd

Le serveur prend 10.99.0.1 pour lui-même, et l’adresse fixe du client se trouve hors de la plage du pool. Le fichier CCD est nommé d’après l’identité effective du client, non d’après le nom du fichier de profil, et il ne prend aucune extension supplémentaire. Si username-as-common-name est actif, le nom d’utilisateur authentifié est l’identité à faire correspondre. Deux appareils qui partagent une identité partageront aussi l’adresse fixe, ce qui est un problème de politique et non de routage.

Vérifiez l’attribution que le client a réellement reçue

Reconnectez le client voulu et confirmez quel fichier CCD a été sélectionné avant de vérifier quoi que ce soit d’autre. Vérifiez ensuite l’adresse, le masque ou le pair, et la route de retour vers le serveur. Un client qui affiche une adresse de pair dans un déploiement subnet utilise encore la mauvaise forme.

Changer de topologie affecte chaque client et chaque dérogation, alors traitez cela comme une migration et non comme une réparation d’un seul client. Corriger la ligne statique pour correspondre à la topologie déjà utilisée est généralement le changement le plus petit. référence server-options documente l’assistant et les dérogations propres au client.