Comment planifier un pool d'adresses de clients VPN qui tienne

Commencez par le champ du pool sur le serveur VPN, pas dans un tableur. Ce que vous y saisissez devient l'espace d'adresses interne de chaque client qui se connecte ensuite, et il doit coexister avec le LAN que ces clients atteignent, les sites routés derrière lui et toute adresse que le client détient déjà chez lui. Connectez un client dès que le pool est enregistré, car cette première connexion vous dit si la valeur fonctionne en pratique. De là, la visite s'étend vers l'extérieur : l'adresse que le client a reçue, le chemin que prend une réponse et l'enregistrement que vous laissez derrière vous.

Commencez au champ du pool, avant qu'aucun client ne se connecte

Chaque produit l'expose différemment, alors trouvez l'objet qui attribue réellement les adresses. OpenVPN a une directive de pool côté serveur qui distribue la prochaine adresse libre, une passerelle IKEv2 a une section de pool liée à la configuration du pair, et WireGuard n'en a aucune des deux car chaque pair porte sa propre adresse dans son fichier de configuration. Une directive de pool et une adresse par pair ne sont pas interchangeables, et modifier la mauvaise gaspille le reste de la visite.

Une fois le champ en main, listez les plages qui existent déjà : le LAN du bureau, chaque site routé, le VPC du cloud et tout autre pool encore en service. Le chevauchement se décide par arithmétique de préfixe, pas par le fait que les numéros d'hôte semblent familiers, alors comparez l'agrégat à chacune de ces plages. Deux plages qui ressemblent toutes deux à 10.x sont inoffensives quand leurs agrégats ne se coupent pas et un incident de support quand ils se coupent.

Décidez ensuite si l'adresse est fonction de qui se connecte ou de quand il se connecte. L'attribution dynamique distribue ce qui est libre, tandis que l'attribution par identité lie une adresse fixe à un identifiant. Notez le choix, car il change l'allure qu'une reconnexion doit avoir plus tard.

Lisez l'adresse que le client a réellement reçue

Connectez un client et lisez ce que le tunnel rapporte, pas ce que le pool avait promis. Le client affiche son adresse interne dans l'état de connexion, et sous Linux l'interface la porte directement.

Comparez cette adresse à la plage que vous avez enregistrée. Si elle se trouve hors de la plage, vous regardez un autre chemin d'attribution que celui que vous avez modifié. Vérifiez aussi la longueur du préfixe, car un client qui détient un /32 n'a aucun pair sur le lien et envoie chaque destination par sa route par défaut.

ip -4 addr show tun0
ip route get 192.168.50.20

Un client qui se connecte depuis un routeur domestique utilisant la même plage se connectera puis n'atteindra presque rien. Le client conserve sa route locale pour ce préfixe, si bien que l'adresse du tunnel entre en collision avec le réseau derrière lui et que le trafic sort par la mauvaise interface. Ce cas ne se répare pas sur le serveur ; le remède documenté est de renuméroter le réseau domestique ou de choisir une plage de pool assez éloignée pour que les collisions restent rares. Notez à la fois la panne et le remède, car le service d'assistance le rencontrera de nouveau.

Reconnectez le même client et observez l'adresse. Un pool dynamique peut renvoyer la même valeur ou une autre et les deux sont correctes, tandis qu'un pool par identité qui change l'adresse ne respecte pas la liaison. Cette vérification prend quelques secondes et tranche si le mode que vous avez noté dans la première section est le mode en vigueur.

Suivez une réponse en retour depuis le service

Le pool ne fonctionne que lorsque les réponses peuvent y revenir. Un service sur le LAN répond à l'adresse interne, donc sa passerelle a besoin d'une route pour le pool ou d'une traduction devant le service. Quand une requête arrive par le tunnel et que la réponse repart par un autre chemin, un pare-feu à états ou un contrôle de chemin inverse la rejette, et le client voit un service qui se connecte puis reste bloqué. Placez le pool dans la conception du routage comme un seul bloc résumable au lieu d'ajouter des routes par hôte.

La traduction change ce que voit le reste du système. Quand la source est réécrite, l'adresse dans le pare-feu de l'hôte et dans le journal de l'application est la traduction, si bien qu'une règle écrite contre l'adresse du pool ne correspond à rien et qu'une ligne de journal ne peut pas être rattachée à un client. La documentation de transfert de strongSwan couvre la moitié côté serveur de ce chemin pour une passerelle IKEv2. Le DNS porte la même contrainte, car un nom qui résout vers une adresse que le client ne peut pas atteindre échoue plus tard et ailleurs.

Deux clients, puis une révocation

Connectez deux clients en même temps et lisez les deux adresses. Elles doivent être distinctes, utilisables et à l'intérieur du pool, et chacune doit atteindre le service auquel elle est destinée. Un pool qui distribue des adresses en double se révèle généralement ici et non au premier test à un seul client.

Révoquez un identifiant pendant que l'autre client reste connecté, puis essayez le service depuis le client survivant. Une révocation qui perturbe l'autre session indique un état partagé, le plus souvent un identifiant ou une adresse réutilisée entre appareils. Reconnectez le client révoqué et confirmez qu'il est refusé plutôt qu'on lui remet l'adresse libérée.

Terminez par une destination qui devrait être refusée. Un client qui atteint tout a été connecté, pas testé.

Écrivez les quatre valeurs là où le prochain changement les trouvera

L'enregistrement est court : la plage et le préfixe du pool, le mode d'attribution, le chemin de retour ou la traduction en usage et la portée DNS qui répond pour ces destinations. Placez-le à côté de la configuration du serveur plutôt que dans un ticket, et datez-le. Quiconque modifie l'une des quatre plus tard a besoin des trois autres devant lui, car un redimensionnement du pool casse la route et un changement de route casse la réponse DNS.

Gardez avec lui la note de propriété : la plage du tunnel appartient au serveur VPN, et une réservation faite dans l'étendue DHCP du LAN ne réserve rien pour un client à l'intérieur du tunnel. Cette seule ligne évite la reprise la plus courante, où quelqu'un ajoute une réservation et s'attend à ce que l'adresse du tunnel la suive.