Utilisateur passerelle dans Access Server : router le LAN de la branche d’un client

Vous pouvez pinguer l’adresse de tunnel d’un client OpenVPN sans pour autant atteindre un hôte du LAN situé derrière. Access Server attribue à ce client une adresse du pool VPN, et l’adresse du pool est tout ce que le serveur sait posséder. Le préfixe de la branche est un fait distinct qu’il faut déclarer, et même alors la branche a besoin d’un relais et le siège d’un chemin de retour. Une route saisie au mauvais endroit ressemble à un correctif et ne change rien.

Deux adresses, deux revendications de propriété différentes

Quand un client se connecte, Access Server lui attribue une adresse du pool VPN configuré, par exemple 10.90.0.0/24. Cette attribution est un bail pour un seul hôte. Rien dans la connexion ne dit que le même client se trouve aussi devant 10.60.0.0/24, et le serveur ne devinera pas : un préfixe LAN n’est joignable via un client précis que si un administrateur le déclare.

C’est pourquoi une route statique sur une autre machine ne sert à rien. La route dit envoyez 10.60.0.0/24 vers cette adresse, mais si l’adresse appartient à un client jamais marqué comme passerelle, le serveur n’a aucune raison de livrer ces paquets là-bas, et la pile du client peut les rejeter. La déclaration et la route sont les deux moitiés d’un même mécanisme.

Ce que le réglage de passerelle installe réellement

Dans l’interface d’administration, la déclaration est une propriété d’utilisateur : activez Configure VPN gateway sur l’utilisateur connecteur et saisissez le préfixe réel de la branche dans Network on the VPN client side. Cet utilisateur s’authentifie comme les autres : il lui faut donc une politique d’identifiants adaptée à un appareil sans surveillance, et son profil de connexion automatique est un secret, pas un fichier de confort.

Derrière cette case, le serveur traite le préfixe comme joignable via l’adresse de pool de ce client, et la configuration de routage sous Access Controls décide de ce qu’on annonce aux autres clients : les routes poussées aux clients ordinaires et les règles d’accès autorisant le trafic des réseaux du siège vers les adresses et sous-réseaux des clients. Activez le routage pour les réseaux qui doivent atteindre la branche et gardez la liste autorisée courte.

Une directive de style Community collée dans un fichier généré ne participe pas à ce modèle. Le produit possède la table de routage qu’il pousse ; une ligne modifiée à la main est écrasée à la génération suivante ou ignorée.

Complétez les chemins de retour des deux réseaux

Un plan concret : siège 10.40.0.0/24, branche 10.60.0.0/24, pool VPN 10.90.0.0/24, et Access Server joignable à une adresse privée côté siège. Le routeur du siège a besoin de routes pour le préfixe de la branche et pour le pool, toutes deux vers Access Server. Sans elles, le tunnel transporte la requête et la réponse sort par la passerelle par défaut, ce qui produit la classique connexion à demi ouverte.

Dans la branche, le connecteur doit transférer les paquets qui ne lui sont pas adressés : transfert IP dans son système d’exploitation plus une autorisation de transfert limitée aux interfaces du tunnel et du LAN ; sous Linux c’est net.ipv4.ip_forward=1 avec les règles de la chaîne forward, sous Windows c’est routing and remote access. Les hôtes de la branche ont ensuite besoin d’un chemin de retour : soit le connecteur est leur passerelle par défaut, soit la passerelle existante porte des routes spécifiques pour les préfixes du siège et du pool.

La table de routage du connecteur ne reconfigure pas chaque hôte du LAN de la branche. Si les hôtes pointent vers un autre routeur, les routes de retour lui appartiennent, et il doit accepter que l’adresse source qu’il voit ne soit pas un voisin du sous-réseau local.

Lire une panne comme un chemin, non comme une autorisation

Testez dans un ordre fixe. D’abord un service autorisé depuis Access Server vers un hôte de la branche, puis le même service depuis un hôte ordinaire du siège, puis le sens inverse si la politique l’autorise. Si le premier passe et le second échoue, ce sont les routes poussées ou les règles d’accès. Si les deux passent mais qu’aucune réponse n’arrive, examinez le transfert dans la branche et la route de retour au siège.

Le pare-feu de l’hôte est le suspect suivant, car avec un accès routé la destination voit comme source une adresse du siège ou du pool. Une règle écrite pour le sous-réseau local ne correspondra pas et le paquet est rejeté alors que le routage fonctionnait parfaitement.

Deux conceptions demandent davantage. Des préfixes qui se chevauchent entre sites rendent la destination ambiguë et exigent une renumérotation ou une traduction, et un Access Server en cluster exige que chaque nœud dispose d’un chemin fonctionnel vers le connecteur de la branche, pas qu’un seul nœud détienne la route. Appliquez les changements par le chemin habituel d’enregistrement et de mise à jour, reconnectez le connecteur et vérifiez à nouveau des deux côtés ; un redémarrage complet de chaque machine ne fait pas partie de la procédure.

Le tutoriel site-to-site d’Access Server énumère les mêmes réglages dans l’ordre du produit ; cela vaut la peine de le suivre une fois avant d’adapter la conception à vos propres préfixes.