Les clients OpenVPN ne se voient pas : sous-réseau ou net30 ?

Deux pannes sans rapport produisent la même plainte. Dans la première, un client n'atteint pas l'autre même par adresse de tunnel, parce que les adresses ne sont pas dans un même sous-réseau ou que le serveur ne transmet pas le trafic entre pairs. Dans la seconde, ping fonctionne et la liste d'appareils de l'application reste vide, parce que la découverte repose sur la diffusion qu'un tunnel de couche 3 ne peut pas transporter. Un seul ping les sépare, et le correctif de l'une ne ressemble en rien à celui de l'autre.

Un seul ping coupe le problème en deux

Depuis un client, faites un ping vers l'adresse de tunnel de l'autre client, pas vers son nom ni vers son adresse LAN. Si cela échoue, le problème est la transmission ou l'adressage et la découverte est sans objet tant qu'il n'est pas corrigé. Si cela réussit, la transmission fonctionne déjà et ce qui manque est la diffusion ou la résolution de noms.

ip addr show tun0

Lisez l'interface du client avant tout, car le masque de réseau nomme la topologie. Un /24 ou un autre masque de sous-réseau signifie un pool partagé ; un /30 avec une adresse de pair signifie l'ancienne disposition point à point, où chaque client a exactement un voisin, le serveur.

net30 contre sous-réseau, lu côté client

Avec net30, le serveur distribue un petit bloc par client, donc il n'existe pas de route vers l'adresse de tunnel d'un autre client à moins que le serveur ne la transmette. Avec un sous-réseau, tout le pool est un réseau, chaque client peut joindre chaque autre, et le serveur transmet entre eux. C'est pourquoi une configuration de serveur peut sembler saine alors que les ping entre pairs échouent : rien n'est cassé, les clients ne sont simplement pas dans un même réseau. Le client voit un lien qui fonctionne et une adresse de pair qui ne répond pas, ce qui se lit comme un pare-feu mais relève de l'adressage.

Changer la directive est une modification côté serveur plus un redémarrage, et elle s'applique à la connexion suivante, pas aux sessions déjà ouvertes. Reconnectez les clients avant de juger le changement. Si un appareil régénère la configuration depuis une interface web, notez la directive, le fichier et la date, et faites la modification via l'interface quand elle existe, car une reconstruction écrasera une modification manuelle au prochain enregistrement.

client-to-client est une porte séparée

Même dans un seul sous-réseau, le serveur rejette les paquets qui arrivent d'un client et sont adressés à un autre, sauf si client-to-client est activé. Ce mot-clé transforme le serveur en transmetteur du trafic entre pairs au lieu d'un point de terminaison qui ne fait que l'accepter. C'est la seconde condition que les gens oublient après avoir corrigé la topologie.

Cela ne s'étend pas à la diffusion. Le réglage transmet de l'unicast entre clients ; il ne transforme pas le tunnel en segment partagé, et aucune quantité n'acheminera une requête de découverte multicast vers chaque pair.

TUN contre TAP, et ce que chacun peut transporter

Ponter un périphérique tap dans le LAN place les clients distants dans le domaine de diffusion du bureau, ce qui résout complètement la découverte. Le prix est celui des plateformes qui n'implémentent pas TAP, d'un pont qui doit exister sur le serveur, et d'un domaine de panne où une tempête de diffusion sur le câble du bureau atteint chaque portable distant.

Pour deux ou trois postes de travail qui ont besoin de résolution de noms, une entrée hosts ou une adresse unicast coûte bien moins cher qu'un pont. Recourez à TAP quand un protocole que vous ne pouvez pas remplacer dépend de la découverte de couche 2, et pas avant.

Clients du même sous-réseau sans pont

Attribuer une adresse de la plage LAN ne met pas le client sur le câble. Le serveur route entre le tunnel et Ethernet, donc l'ARP pour cette adresse s'arrête à l'interface du serveur et le reste du LAN n'apprend jamais où elle habite.

ip neigh add proxy 10.50.1.250 dev eth0

Proxy ARP comble cet écart en faisant répondre le serveur à la place du client. Pour une plage, parpd gère les entrées au fil des arrivées et départs des clients, tandis que le sysctl net.ipv4.conf.eth0.proxy_arp=1 répond pour tout ce qui est routé ailleurs, ce qui est assez large pour créer ses propres surprises sur un segment chargé.

Quelle que soit la voie choisie, retirez NAT entre le tunnel et le câble. Une règle MASQUERADE masque exactement la question d'adressage à laquelle vous cherchez à répondre. Elle laisse aussi à la personne suivante une topologie qu'elle ne peut pas appréhender depuis le côté client.

Avant de changer quoi que ce soit, capturez une tentative sur le serveur avec tcpdump -ni tun0 et confirmez si le paquet du pair arrive. Qu'il arrive puis soit rejeté pointe vers client-to-client ; qu'il n'arrive jamais pointe vers la topologie ou le routage. Le manuel d'OpenVPN 2.6 documente les deux mots-clés et la topologie par défaut, ce qui vaut la peine d'être comparé à votre version avant de copier une ligne d'un message de forum.

• L'interface tun affiche un masque de pool plutôt qu'une paire de pairs /30.
• Un ping direct vers l'autre adresse de tunnel réussit avant que vous ne testiez la découverte.
• La configuration du serveur inclut client-to-client chaque fois que les pairs doivent échanger des paquets.
• Nommez le protocole de découverte que vous testez au lieu de dire que l'application échoue.
• N'utilisez TAP que si chaque plateforme cliente du groupe le prend en charge.
• Gardez NAT hors du chemin entre tunnel et LAN lorsque l'accessibilité au sein du même sous-réseau compte.