Un client VPN avec une adresse LAN n’est pas sur le LAN

Le client se connecte, reçoit 10.50.0.200 et ne peut pas joindre le serveur à 10.50.0.20 alors que les deux numéros se trouvent dans le même /24. La croyance derrière cette configuration est qu’une adresse du préfixe LAN fait du client une partie du LAN. Ce n’est pas le cas. Le client est sur un lien point à point, le serveur croit la destination locale, et la pièce manquante est une réponse de voisin que personne n’envoie.

Le mythe : même préfixe, même segment

Un préfixe d’adresse indique à un hôte quelles destinations il peut atteindre directement et lesquelles exigent un routeur. Il ne lui dit pas comment la destination est physiquement rattachée, et il ne garantit certainement pas que la destination puisse répondre à une requête de couche liaison. Ce sont des questions différentes, auxquelles répondent des tables différentes sur l’hôte. Le masque répond à la première et la table de voisinage à la seconde, et seule la première est sous votre contrôle côté VPN.

Quand le serveur envoie vers 10.50.0.200, il compare la destination à son propre masque, décide que l’adresse est on-link et demande au segment local l’adresse matérielle qui la possède. Cette requête part sur l’interface Ethernet, et le client VPN n’est pas là pour l’entendre.

Rien dans la configuration du client ne peut corriger cela de son côté. Le chemin de retour dépend d’un équipement du LAN qui répond au nom du client, ou du fait que le client ait une adresse que le serveur ne considère pas comme locale.

Ce que l’hôte local fait réellement de l’adresse

Le comportement est facile à observer et mérite de l’être avant de changer quoi que ce soit. Regardez la table de voisinage d’un hôte du LAN après qu’il a tenté de joindre le client : une entrée incomplète ou en échec, c’est tout le diagnostic en une ligne. Cette ligne vous dit aussi que la panne est locale au segment et non quelque part dans le tunnel.

ip neigh show 10.50.0.200
ip route get 10.50.0.200
arping -I eth0 -c 3 10.50.0.200

La recherche de route signalera la destination comme on-link via l’interface Ethernet, et c’est exactement le problème. Si l’entrée de voisinage reste incomplète tant que la session VPN est active, vous avez confirmé que la pièce manquante est la résolution de couche liaison, et non le routage ou la politique de pare-feu.

Faites la même vérification depuis un hôte d’un autre sous-réseau et comparez. Un hôte qui atteint le client via un routeur n’a pas besoin d’entrée de voisinage du tout, et cette différence est la décision de conception en miniature.

Comment le proxy ARP fournit un prochain saut

Le proxy ARP fait répondre la passerelle à la requête de couche liaison au nom d’une destination qu’elle peut atteindre par une autre interface. L’hôte du LAN reçoit une adresse matérielle, envoie la trame à la passerelle, et la passerelle achemine le paquet dans la session VPN. Du point de vue de l’hôte, le client semble simplement être derrière la passerelle. Rien dans la configuration du client ne change.

La documentation ARP de RouterOS de MikroTik décrit cet usage pour les clients dial-in qui empruntent l’espace d’adressage du LAN connecté. Le mécanisme est une réparation de la résolution de voisinage, et il fonctionne parce que la passerelle est réellement sur les deux chemins.

Ce n’est pas la même chose que pontrer le client dans le LAN. La passerelle doit toujours acheminer le paquet vers la bonne session active, et son routage et sa politique de pare-feu doivent toujours autoriser le service. Le proxy ARP change qui répond à la requête de voisinage, pas qui a le droit de parler.

Lisez attentivement les noms de mode de la plateforme. RouterOS distingue proxy-arp de local-proxy-arp, et le second traite le trafic qui entre et sort par la même interface. Ce ne sont pas des orthographes interchangeables, et activer les deux sans discernement n’est pas un raccourci.

Ce que le proxy ARP ne vous donne pas

Il ne fournit pas la découverte par broadcast ou multicast. Un client qui doit trouver un service par broadcast échouera quand même, car la passerelle achemine l’unicast vers la session et ne fait pas du client un membre du domaine de broadcast du LAN. Les protocoles de découverte qui reposent sur le broadcast sont une source fréquente de rapports « ça marche pour une chose et pas pour l’autre » dans les conceptions d’adresses empruntées.

Il ne réserve pas l’adresse. Si le numéro emprunté figure aussi dans un pool DHCP ou dans une attribution statique, deux appareils peuvent finir avec la même adresse et le comportement résultant dépend du moment. Une connexion réussie n’est pas une réservation.

Et il ne supprime pas le besoin de coordination avec le propriétaire du LAN. Une entrée proxy ARP qui surprend le propriétaire du plan d’adressage est un incident de support en attente d’une semaine calme.

Comparaison avec un pool routé séparément

L’alternative est de donner aux clients VPN leur propre préfixe et de laisser les hôtes du LAN router vers lui. Le serveur envoie alors des réponses hors lien à sa passerelle, la passerelle route le préfixe vers le point de terminaison VPN, et aucune résolution de voisinage n’est nécessaire sur le segment LAN. C’est moins de pièces mobiles qu’une adresse empruntée plus une réponse proxy.

Cette conception est plus facile à raisonner et à auditer, parce que la plage des clients est visiblement distincte de celle du LAN. Elle coûte une route, un chemin de retour et une règle d’accès, soit les mêmes éléments que la conception proxy ARP exige à un endroit moins évident.

Choisissez entre les modèles délibérément et non par accident. Le proxy ARP répare une relation précise ; un pool routé évite d’avoir besoin de cette réparation. Écrivez ce que vous avez choisi et pourquoi, et la personne suivante n’aura pas à le redécouvrir à partir d’une entrée de voisinage en échec.