Quelle adresse le pool attribuera-t-il à la prochaine reconnexion ?
Les adresses du pool suivent un ordre qui n’a rien d’aléatoire : d’abord l’adresse mémorisée, puis la libre la moins récemment utilisée. Lisez cet ordre avant d’épingler une règle.
Une règle qui correspondait hier ne correspond plus aujourd’hui, parce que le client est revenu avec une autre adresse de tunnel. L’allocateur n’est pourtant pas aléatoire, et connaître son ordre transforme cette surprise en événement prévisible. Il préfère l’adresse que le même client occupait auparavant, se rabat sur la libre la moins récemment utilisée et oublie tout si vous ne lui donnez pas de quoi se souvenir. Les règles qui supposent un bail continuent de correspondre jusqu’au jour où elles cessent discrètement de le faire.
L’ordre que suit l’allocateur
Avec une session par common name, l’allocateur cherche d’abord une adresse que le même client a utilisée auparavant et qui est actuellement libre. Si cette adresse a disparu, il prend l’adresse libre restée inactive le plus longtemps. Avec des sessions simultanées activées pour le même nom, la préférence pour l’adresse précédente ne s’applique pas et la première adresse libre est utilisée à la place, car les sessions sont traitées comme des pairs distincts.
| Situation | Address chosen | Practical effect |
|---|---|---|
| Reconnect, old address still free | The remembered address | Rules appear stable for days |
| Old address taken by another client | Least recently used free address | A working rule silently stops matching |
| Concurrent sessions, same name | First free address, per session | One identity can hold several leases |
Deux conséquences suivent immédiatement. Un client qui se reconnecte vite conserve généralement son adresse, ce qui explique que personne ne remarque le mécanisme avant qu’il change. Et un autre appareil qui se connecte pendant cette petite fenêtre peut prendre l’adresse tant qu’elle est brièvement libre, après quoi le premier client obtient autre chose et toute règle indexée sur l’ancien numéro est fausse. Aucun des deux événements ne produit une ligne de journal qui ressemble à une panne.
Pourquoi un bail paraît stable puis se déplace
La stabilité est ici une propriété émergente de reconnexions qui arrivent avant que quiconque revendique l’adresse. Ce n’est pas une promesse, et elle n’est pas garantie tant que le client est déconnecté. Prévoyez que l’adresse change plutôt que d’en être surpris. Un pool à peine plus grand que le nombre d’appareils rend les collisions habituelles, car le repli sur la libre la moins récemment utilisée n’a presque rien à choisir.
La concurrence de pointe est le chiffre sur lequel dimensionner, pas le nombre d’utilisateurs. Quelqu’un qui teste depuis deux appareils à la fois, ou un client qui se reconnecte avant l’expiration de l’ancienne session, occupe deux baux pendant un moment. Un pool dimensionné sur le seul nombre de personnes produira exactement le brassage que l’on reproche au serveur.
Le fichier de persistance se souvient, il ne réserve pas
Une adresse qui survit à un redémarrage du service a besoin d’un fichier de persistance. Il enregistre le nom du client et l’adresse à l’arrêt et les relit au démarrage du service, ce qui explique qu’un redémarrage planifié ne remue plus toutes les règles que vous avez écrites.
ifconfig-pool-persist /etc/openvpn/ipp.txt
server 10.8.0.0 255.255.255.0Ce qu’il ne fait pas, c’est retenir l’adresse pendant l’absence du client. Durant cet intervalle, l’allocateur est libre de donner le numéro à quelqu’un d’autre, et le fichier consigne alors une préférence périmée que la connexion suivante ne peut pas honorer. Traitez-le comme un indice qui améliore le comportement au redémarrage, non comme un adressage statique.
Vérifiez le pool contre chaque sous-réseau routé pendant que vous êtes dans le fichier. Une plage qui se chevauche distribue des adresses que le serveur ne peut pas router, et le symptôme est un client qui se connecte, reçoit une adresse et n’atteint rien.
Épingler une adresse correctement
Quand une règle de pare-feu ou un enregistrement DNS a réellement besoin d’une adresse fixe, attribuez-la plutôt que de l’espérer. Une entrée de configuration par client peut pousser une adresse et un masque directement, et cette entrée est indexée sur le nom effectif du client.
# client-config-dir entry for "laptop-acme"
ifconfig-push 10.8.0.50 255.255.255.0Gardez les adresses fixes hors du pool dynamique pour que l’allocateur ne remette jamais le même numéro à une autre session. Vérifiez ensuite la topologie du tunnel, car elle change le nombre d’adresses du pool consommées par chaque client : l’ancienne disposition point à point consomme un petit bloc par client, tandis qu’une disposition en sous-réseau n’utilise qu’une adresse par client. Un pool qui semble généreux sous une topologie peut être épuisant sous l’autre.
Confirmez le résultat sur le client au lieu de faire confiance à la comptabilité du serveur. Une fois la session revenue, regardez l’adresse de l’interface et la route poussée, car un journal côté serveur peut signaler l’adresse demandée alors que l’interface en détient une autre.
L’adresse distante est une question distincte
L’adresse de la ligne distante du client doit être joignable avant qu’un tunnel existe. Y placer une adresse du pool, comme le point de terminaison de tunnel du serveur, signifie que le client tente de joindre le point de terminaison à travers un tunnel qu’il n’a pas encore construit, et le résultat est une boucle ou un délai silencieux plutôt qu’un raccourci.
Utilisez le point de terminaison public fourni par l’opérateur, et réservez le pool à ce pour quoi il est conçu : les adresses à l’intérieur du tunnel. Consigner la plage du pool, les attributions fixes et le chemin de persistance au même endroit évite au suivant de traiter chaque bail comme arbitraire.