Pourquoi les clients Access Server sont inaccessibles depuis le LAN

L’ordinateur portable se connecte, le tunnel est actif et les requêtes vers un service interne restent bloquées à la connexion. Sur le service lui-même, la requête arrive d’une adresse comme 10.90.0.25, la réponse part vers la passerelle par défaut, et rien ne revient, car cette passerelle n’a aucune idée de l’endroit où se trouve 10.90.0.25. Depuis l’autre extrémité, la même panne ressemble à un hôte interne incapable de pinguer un client connecté. Les deux ne sont qu’un objet manquant : une route de retour vers le pool de clients VPN, que seul le réseau privé peut ajouter.

Lisez l’adresse source que voit le service

Ce seul champ décide de tout le reste. Si le service interne voit l’adresse du pool, Access Server route au lieu de masquer le trafic des clients, et chaque réponse doit être routée vers le pool. S’il voit à la place l’adresse privée du serveur lui-même, le serveur fait du masquerade et le chemin de retour fonctionne déjà, au prix de la perte de toute identité par client dans les journaux et les règles d’accès du service.

Comparez les deux extrémités avant de changer quoi que ce soit. Sur le serveur, listez les interfaces du tunnel et leurs adresses ; sur le client, confirmez laquelle de ces adresses il détient réellement ; sur l’hôte interne, regardez une connexion active.

ip -br addr show
ss -tnp state established '( dport = :443 )'
ip route get 10.90.0.25

La dernière commande est celle qui échoue dans le cas cassé : soit elle signale le préfixe du tunnel comme inaccessible, soit, pire, elle renvoie votre passerelle par défaut, et c’est ainsi que les réponses finissent sur internet.

Ne supposez pas un seul pool. Un serveur peut avoir une plage dynamique plus des affectations statiques par utilisateur, et l’adresse statique peut se situer entièrement hors du préfixe dynamique. Si vous ne routez que la plage dont vous vous souvenez, les utilisateurs à adresse fixe restent cassés et tous les autres signalent le problème comme résolu.

Ajoutez la route là où la réponse est décidée

La route appartient à la passerelle que le service interne utilise déjà, pas au service, sauf s’il route son propre trafic. Pointez-la vers l’adresse privée joignable d’Access Server, qui diffère de l’adresse de tunnel détenue par un client.

ip route add 10.90.0.0/24 via 10.0.1.5
ip route get 10.90.0.25

Dans un réseau cloud, la même instruction devient une entrée de table de routage dont la cible est l’instance ou l’interface réseau qui exécute le serveur, avec la vérification de source et de destination désactivée sur cette interface. Notez ce que cette entrée ne fait pas : une route n’est pas une autorisation d’accès, donc les groupes de sécurité, les ACL réseau et le pare-feu de l’hôte doivent encore autoriser le trafic.

Rendez-la persistante et gardez des tailles de pool honnêtes. Deux pools non contigus nécessitent deux routes, et un pool qui dépasse son préfixe configuré produit silencieusement des clients dont les réponses n’ont nulle part où aller. Si vous contrôlez les plages des pools, choisissez un résumé que vous pouvez router une fois et laisser tranquille.

Le transfert et les filtres doivent s’accorder avec la route

Le routage n’est que la moitié du chemin. Le serveur doit être autorisé à transmettre entre le tunnel et l’interface privée, ce qui sous Linux signifie net.ipv4.ip_forward plus une chaîne de transfert qui autorise la paire d’interfaces, et sur un hôte durci généralement une règle explicite par direction.

sysctl net.ipv4.ip_forward
nft list ruleset | grep -A5 forward

Le filtrage avec état explique un symptôme qui envoie les gens sur la mauvaise piste. Une réponse au sein d’un flux établi n’a pas besoin d’une nouvelle règle entrante, donc une connexion qui reste bloquée après le SYN-ACK n’est pas bloquée par une règle d’acceptation manquante ; elle est abandonnée ou mal routée. Gardez cette distinction, car elle sépare un changement de routage d’un changement de pare-feu.

Les chemins de retour asymétriques sont la version plus discrète du même problème. Si deux routes atteignent le pool et que la réponse emprunte celle qui sort par une interface différente de celle où la requête est arrivée, le filtrage strict du chemin inverse la rejette et le flux échoue pour certains clients seulement.

Routé ou masqué : choisissez délibérément

Le mode routé préserve l’adresse du pool du client sur le service, ce qui rend possibles la journalisation et la politique par client, et en échange chaque réseau interne qui doit répondre à un client a besoin de la route du pool. Le mode masqué supprime cette exigence parce que les réponses reviennent au serveur, mais le service ne distingue plus un client d’un autre et ne peut rien initier vers un client précis.

Changer ce comportement sur un serveur en production coupe les sessions existantes, alors testez d’abord avec un client et un flux. Si le basculement est la bonne réponse, c’est une décision de configuration sur le serveur, pas quelque chose que l’on contourne en ajoutant des routes qui deviendront inutiles.

Un sous-réseau derrière le client est une tâche distincte

Atteindre un appareil sur le LAN propre de l’ordinateur portable n’est pas la même chose qu’atteindre l’adresse de tunnel de l’ordinateur portable. Cela exige que le client agisse comme une passerelle de sous-réseau : un réseau déclaré côté client, le transfert activé dans le système d’exploitation du client, et une route sur ce LAN vers le client. Ajouter une route de réseau privé pour la plage domestique de l’ordinateur portable ne fait pas cela, et crée des conflits lorsque deux utilisateurs ont la même plage domestique.

La direction est aussi une question de politique. L’autorisation pour un client d’ouvrir une connexion vers un service interne ne permet pas automatiquement à un hôte interne d’ouvrir une connexion vers ce client. Vérifiez la politique d’accès du serveur et le pare-feu de l’hôte client avant de conclure que le chemin est cassé.

Vérifiez avec un flux et une capture

Prouvez le chemin avec une seule connexion plutôt qu’un test de joignabilité général. Observez le même flux aux deux extrémités : la requête qui arrive au service et la réponse qui le quitte.

tcpdump -ni any host 10.90.0.25 and port 443

Avant la correction, la capture montre la réponse partant vers une passerelle qui ne la routera pas. Après la correction, la réponse part vers le serveur et le flux se termine. Confirmez ensuite la route que la passerelle utiliserait pour une deuxième adresse client, afin qu’un pool non couvert apparaisse maintenant et non dans une semaine.

Terminez par les quatre vérifications qui closent le sujet : l’adresse source au niveau du service correspond au mode voulu, la passerelle a une route vers chaque pool utilisé, le transfert et les filtres autorisent les deux directions, et un flux réel aboutit de bout en bout. La FAQ sur le routage d’Access Server énonce le même principe pour la version installée, dont l’interface de configuration prise en charge peut différer des guides plus anciens.