IP statique OpenVPN par client : ifconfig-push, pas ipp.txt

Modifier une ligne dans ipp.txt donne l'impression de réserver une adresse, et ce n'est pas le cas. Ce fichier, nommé par ifconfig-pool-persist, enregistre quelle adresse un nom commun avait la dernière fois, afin que le pool puisse rendre la même quand cela arrange. Rien n'y lie la connexion suivante à ce numéro.

Exécutez les vérifications ci-dessous dans l'ordre. Chacune confirme le mécanisme ou vous dit de vous arrêter et de réparer une entrée.

À quoi sert le fichier de persistance

Le fichier existe pour garder les adresses stables entre les redémarrages, ce qui rend les reconnexions plus agréables et les journaux plus lisibles. Il est lu comme un historique et écrit comme un historique, et le chemin d'allocation reste libre de choisir une autre adresse quand l'indice ne convient pas : un autre pool, une affectation en conflit ou un client arrivé après que le pool s'est rempli. C'est pourquoi une modification manuelle peut sembler parfaite dans le fichier sans rien changer à la connexion. Traitez-le comme un cache des décisions passées, pas comme une source de politique.

Si vous avez besoin d'une adresse précise pour un client précis, le mécanisme documenté est ifconfig-push, et il appartient à la configuration qui possède ce client.

Vérifiez que le bon client est sélectionné

Une affectation explicite est recherchée par le nom commun du client, donc un fichier nommé pour la mauvaise identité n'est tout simplement jamais lu. Confirmez ce que le serveur considère comme le nom de ce client, en particulier là où username-as-common-name le change après l'authentification. Confirmez ensuite que le nom du fichier correspond exactement à cette valeur, majuscules et minuscules comprises.

Pensez à la concurrence pendant que vous y êtes. Si duplicate-cn est autorisé, plusieurs appareils peuvent présenter la même identité, et une adresse fixe ne peut pas être unique pour tous. Décidez si l'adresse fixe vaut le refus des sessions simultanées pour cette identité, car ces deux exigences ne peuvent pas être satisfaites ensemble.

Vérifiez que les nombres correspondent à la topologie

Le sens des arguments dépend de la topologie du tunnel, et c'est ici qu'un exemple copié fait le plus de dégâts. Dans l'ancienne disposition net30, chaque client occupe un bloc de quatre adresses, donc le push fournit une paire d'adresses. En topologie de sous-réseau, le client reçoit une adresse plus le masque du pool, et la forme en paire est incorrecte. Lisez la topologie depuis la configuration en cours avant d'écrire la ligne.

# /etc/openvpn/ccd/partner-a   (subnet topology)
ifconfig-push 10.44.0.61 255.255.255.0

Vérifiez l'adresse contre tout ce qui pourrait la posséder : une autre affectation explicite, la plage du pool dynamique et toute route statique qui suppose un hôte fixe. Une adresse qui chevauche le pool fonctionnera jusqu'à ce que le pool la donne à quelqu'un d'autre, et cette défaillance semblera aléatoire.

Vérifiez le résultat sur une nouvelle connexion

Une session existante conserve l'adresse qui lui a été donnée, donc le seul test significatif est une nouvelle connexion. Déconnectez le client, reconnectez-le et lisez l'adresse qu'il a réellement reçue avec les routes qui sont arrivées avec elle. Si l'adresse est toujours dynamique, l'affectation n'a pas été appliquée, et l'étape suivante est la recherche dans la configuration plutôt qu'une nouvelle modification du fichier d'historique.

Gardez les preuves ensemble : le nom du client, le fichier qui a correspondu, l'adresse attribuée et le pool d'où elle vient.

Enfin, une adresse de tunnel fixe n'est pas un justificatif d'appareil. Elle identifie un emplacement dans le plan d'adressage, tandis que l'authentification repose toujours sur le certificat et le compte. Confondre les deux transforme un conflit d'adresses en une hypothèse de sécurité que personne n'a écrite.