MULTI : adresse source invalide du client : à qui était cette adresse ?

Le journal du serveur affiche MULTI: bad source address from client, rejette le paquet, et la session reste connectée. Cette combinaison désoriente ceux qui lisent le message comme un échec d’authentification. Ce n’est pas le cas : le client s’est authentifié, et le paquet arrivé portait une adresse source interne que le serveur n’a pas pu rattacher à cette instance du client. Le contrôle a lieu avant la livraison, et c’est pourquoi le tunnel paraît sain alors que rien d’utile ne le traverse.

Ce que le serveur compare avant la livraison

Pour chaque paquet provenant d’un client, le serveur en espace utilisateur examine l’adresse source à l’intérieur du tunnel et demande à son état de routage interne à quel client cette adresse appartient. Si le propriétaire est une autre instance, ou s’il n’y a aucun propriétaire, le paquet est écarté et l’avertissement est émis.

La livraison ordinaire par l’interface du tunnel n’a jamais lieu.

Cet ordre explique un détail qui déroute : les compteurs du pare-feu de l’hôte ne bougent pas, car le paquet n’a jamais atteint le pare-feu. Ajuster le filtrage de chemin inverse sur l’hôte ne change rien ici, puisque le rejet a eu lieu dans le contrôle d’association du démon lui-même. Lisez le message comme une affirmation sur la propriété, puis déterminez laquelle des trois situations l’a produit.

Trois origines d’une adresse interne incohérente

Le client émet peut-être depuis une adresse qui ne lui a pas été attribuée, depuis un réseau que personne n’a déclaré comme le sien, ou depuis un double d’une identité qui a déjà un propriétaire. Les trois produisent la même ligne de journal. Elles diffèrent par ce qu’il faut changer. Commencez par l’adresse et par la liste d’attributions en cours, et laissez ces deux faits choisir le cas.

Les distinguer demande deux faits : l’adresse rejetée dans le journal, et les attributions que le serveur tient pour actuelles. Le second est disponible dans la vue d’état ou de gestion de l’instance en cours d’exécution, et c’est la seule autorité qui vaille d’être consultée, car un fichier de configuration consigne des intentions et non l’état présent.

Notez les deux avant de changer quoi que ce soit, puis classez. Une capture d’écran prise ensuite n’est pas un relevé de l’état qui a produit l’avertissement. Conservez aussi l’horodatage, car les attributions se déplacent d’une session à l’autre.

Le LAN derrière un client et iroute

Quand un client de site route son propre réseau privé, ce réseau doit être déclaré comme appartenant au client. Un fichier propre au client contenant une entrée iroute s’en charge, et l’entrée nomme le préfixe que le client est autorisé à transporter.

Une route du noyau pointant le même préfixe vers le tunnel est une exigence distincte, et l’ajouter ne change rien à la propriété interne du démon.

# /etc/openvpn/server/ccd/site-b
iroute 192.168.70.0 255.255.255.0

Vérifiez que l’identité effective correspond au nom du fichier, car une divergence signifie que le fichier n’est jamais chargé et le symptôme est identique à une entrée absente. N’ajoutez pas d’iroute large pour faire taire l’avertissement, car cela transforme une source inattendue en source autorisée sans répondre à pourquoi le client l’a envoyée. Le manuel d’OpenVPN 2.6 documente iroute, duplicate-cn et le mappage d’identité comme des contrôles distincts.

La même identité sur deux machines

Un profil copié sur un second ordinateur portable porte le même certificat et le même nom commun. Selon les réglages du serveur, la connexion la plus récente peut remplacer la plus ancienne, et l’instance qui détient la propriété gagne le contrôle d’association.

Cela fait paraître la panne intermittente et ne la fait apparaître que lorsque les deux appareils sont éveillés.

Autoriser des noms communs en double laisse les deux se connecter, mais ne leur donne pas d’adresses statiques indépendantes ni de propriété indépendante. Si deux appareils doivent coexister, enregistrez-les séparément pour que chacun ait sa propre identité et sa propre attribution. Traiter le réglage des doublons comme une réparation de cet avertissement laisse le mystère en place et en ajoute un second.

Prouvez que l’association a changé

Appliquez la correction par le propriétaire de la configuration, puis reconnectez le client concerné pour que la nouvelle politique soit chargée.

Répétez le même parcours et confirmez trois choses : la source interne du paquet, l’instance du client à laquelle le serveur l’associe, et le comportement de la destination ensuite.

Si l’avertissement cesse mais que l’application échoue encore, le problème s’est déplacé au lieu de disparaître. Le transfert, les règles du pare-feu et le chemin de retour sont des étapes distinctes, et franchir le contrôle d’association signifie seulement que le paquet a été autorisé à quitter le tunnel.