DHCP au travers d’un VPN : pont vers le broadcast ou relais ?

Un nouvel ordinateur portable de l’autre côté du tunnel n’obtient pas d’adresse, alors que le même portable fonctionne au siège. La première supposition habituelle est que le tunnel bloque DHCP. Le plus souvent, le broadcast n’a jamais eu de chemin : un client non configuré émet vers 255.255.255.255, et un routeur IP ordinaire ne transmet pas ce paquet. Le tunnel fait exactement ce que fait un tunnel routé.

Deux conceptions peuvent changer cela, et elles ne sont pas équivalentes. L’une transporte le broadcast ; l’autre relaie la requête.

Le broadcast ne traverse jamais le routeur

Un client DHCPv4 sans adresse émet depuis 0.0.0.0 vers l’adresse de broadcast limité sur les ports UDP 67 et 68. Ce paquet reste sur son lien par conception. Un routeur qui le transmettrait inonderait chaque segment qu’il dessert.

Ainsi, un tunnel routé de site à site relie le relais à un serveur. Il n’étend pas le domaine de broadcast du client, et aucune règle de pare-feu n’y parviendra.

Ce qu’un tunnel ponté étend réellement

Un VPN délibérément ponté peut transporter le broadcast Ethernet dans sa topologie prise en charge, et DHCP peut alors passer comme trafic local. C’est une option réelle, mais c’est un choix de conception de couche 2. Vous étendez le domaine de panne et la frontière d’accès en même temps que le broadcast.

Le pontage change aussi ce qu’une tempête de broadcast, un balayage ARP ou un serveur DHCP pirate peuvent atteindre. Si vous ne brancheriez pas l’agence distante sur le même commutateur, ne pontez pas le tunnel juste pour distribuer des adresses. Testez ce rayon d’impact avant de l’activer.

C’est une décision plus lourde que celle de fournir une adresse, et elle doit être prise délibérément.

Relayez plutôt la requête

La réponse habituelle est un relais sur le réseau local du client. Il reçoit le broadcast, le transforme en requête unicast et place sa propre adresse dans le champ d’adresse de passerelle. Le serveur répond à cette adresse de relais.

Pour une agence distante illustrative, le relais se trouve sur le LAN de l’agence et le serveur est joint via le VPN du site. Configurez l’étendue pour cette agence, les identités du relais et du serveur, ainsi que le chemin de retour complet. Autoriser UDP 67 à travers le tunnel n’indique pas au serveur quel pool utiliser.

Un relais qui transmet mais ne reçoit jamais de réponse est généralement un problème de chemin de retour. Vérifiez la route vers l’adresse du relais avant de modifier l’étendue.

Séparez DHCP d’ARP et de l’adressage du tunnel

DHCP passe par UDP/IP. Sur Ethernet, un hôte peut aussi utiliser ARP pour vérifier si une adresse candidate est déjà utilisée. Ce contrôle de conflit est une opération locale au lien distincte, et non le transport des messages DHCP. Dire que DHCP est essentiellement ARP est faux ; dire que les deux n’ont jamais de rapport est trop large.

Un client VPN peut aussi obtenir son adresse de tunnel du protocole VPN ou du pool du serveur plutôt que d’un broadcast DHCP. Une option dont le nom contient DHCP peut décrire des paramètres client poussés, et non un paquet DHCP relayé. Vérifiez le pool du serveur avant de supposer que DHCP est impliqué.

Consignez le réseau destinataire, le propriétaire de l’allocation, l’étendue, l’existence d’un relais et le comportement attendu pendant une panne. Puis testez un nouveau bail et un renouvellement via ce modèle. Si deux sites peuvent servir le même pool non géré, vous avez un conflit qui attend le premier portable itinérant.