CIDR de groupe Access Server : adresses des membres ou réseau de ressources

Deux champs d’un groupe Access Server acceptent une notation CIDR, et à première vue ils ressemblent au même type de saisie : l’un décrit les adresses remises aux membres VPN, l’autre décrit les réseaux que ces membres peuvent atteindre. Remplir le mauvais champ est accepté sans erreur, et c’est précisément ce qui rend la faute coûteuse. Le premier modifie votre plan d’adressage du tunnel, le second décide quelles destinations sont autorisées, et aucun des deux n’implique l’autre. Il existe aussi un troisième objet que l’on amalgame à ces deux-là, le sous-réseau situé derrière une passerelle de branche, et il n’appartient à aucun des deux champs.

Même syntaxe, questions différentes

Demandez-vous ce que la valeur désigne. Un CIDR d’adresses de membres répond à la question « quelles adresses internes les clients qui se connectent reçoivent-ils », et le mécanisme d’attribution le consomme avant que le moindre trafic ne circule. Un CIDR de ressources répond à la question « quelles destinations ce groupe peut-il utiliser », et les règles d’accès le consomment au moment où un paquet est évalué. L’un est une définition de pool, l’autre une autorisation.

Les conséquences d’une confusion sont opposées. Un LAN de destination collé dans le champ du pool peut distribuer des adresses qui existent déjà sur ce LAN, ce qui produit un comportement de doublon d’adresses, ou décaler le pool d’une façon qui casse silencieusement chaque règle de pare-feu écrite pour l’ancienne plage. Un pool collé dans une règle d’accès n’accorde rien d’utile, car aucune destination ne s’y trouve. Les deux erreurs se présentent comme « le tunnel est monté mais quelque chose cloche ».

Allocation : l’espace d’adresses des membres

Le pool doit être sans chevauchement avec chaque LAN qu’un membre peut atteindre et avec chaque autre pool VPN du déploiement. C’est une contrainte de planification, pas un réglage du produit : avec deux sites utilisant tous deux 10.90.40.0/24 pour les membres, un membre d’un site ne peut pas joindre l’autre sans traduction, et aucune règle d’accès n’y remédie.

Le mode d’attribution compte aussi. Un pool dynamique remet à chaque membre la prochaine adresse libre, tandis qu’une attribution statique par utilisateur l’épingle. Les attributions statiques sont ce qu’il vous faut quand des règles de pare-feu ou la supervision désignent des membres individuels, et elles rendent aussi visible un changement de plan d’adressage : l’adresse épinglée tombe encore dans le nouveau pool, ou elle n’y tombe pas. Relevez l’adresse de tunnel d’un membre connecté avant et après toute modification de ce champ.

Permission : les réseaux de destination vont dans les règles d’accès

L’accessibilité s’exprime dans les règles d’accès, qui nomment le groupe ou les utilisateurs, un réseau ou service de destination, et la méthode d’accès. Cette dernière partie est là où la plupart des configurations à moitié finies échouent : une règle peut router le trafic vers la destination ou le traduire par NAT, et les deux exigent des choses différentes du réseau. Un chemin routé demande au côté destination de savoir renvoyer le trafic vers le pool VPN, tandis qu’un chemin NAT masque les membres derrière une adresse que la destination accepte déjà. La documentation des groupes Access Server garde le réseau du groupe séparé des règles d’accès du groupe, et les libellés ont bougé d’une version à l’autre.

Une destination autorisée a encore besoin d’un chemin utilisable. La règle permet, la route achemine, le chemin de retour répond et le service sur l’hôte accepte. Quatre choses, quatre endroits à regarder, et seule la première vit dans la règle d’accès. Une permission au vert avec un traceroute mort signifie généralement que la route de retour manque sur la passerelle de la destination, et non que la règle est fausse.

Le troisième objet : un sous-réseau de branche derrière une passerelle

Déclarer qu’un client donné possède un sous-réseau est une affirmation de routage à propos d’un site, ni une attribution d’adresse ni une permission. En termes Access Server, c’est la configuration de passerelle prise en charge pour un réseau qui se connecte, et elle existe parce qu’un routeur de branche peut annoncer le LAN situé derrière lui. Les membres reçoivent toujours leurs adresses depuis le pool, et ils ont toujours besoin d’une règle d’accès pour utiliser ce LAN de branche.

Garder les trois séparés paie au moment de la revue. Un sous-réseau de branche enregistré comme espace d’adresses de membres d’un groupe semble correct sur une capture d’écran et casse l’allocation pour tout le groupe. Le même sous-réseau enregistré uniquement dans une règle d’accès accorde l’accès sans l’affirmation de propriété, si bien que le trafic de retour n’a nulle part où aller. Mettez chaque objet dans sa propre colonne de la conception et l’erreur cesse d’être possible.

Comment savoir lequel vous avez sous les yeux

Lisez le libellé avec ses voisins. Un champ voisin d’un mode d’attribution, d’une taille de pool ou d’une dérogation par utilisateur concerne l’allocation. Un champ voisin d’un sélecteur de groupe, d’un service ou d’un port, et d’une méthode de routage concerne la permission. Les versions renomment les choses, mais les voisins restent à peu près à leur place, et c’est pourquoi le texte d’une vieille capture d’écran est un mauvais guide de navigation.

Vérifiez ensuite avec un seul membre plutôt qu’avec tout le groupe : son groupe effectif, son adresse de tunnel attribuée et la règle qui autorise sa destination visée. Confirmez la route, le NAT ou le chemin routé, le trafic de retour et la permission du service dans cet ordre, et ne changez que le champ qui correspond à l’écart démontré. Tenez ensuite les registres d’allocation et de permission séparés, afin qu’un changement de pool ultérieur ne soit pas lu comme un changement de ce que le groupe peut atteindre.