Quel identifiant votre réservation VPN doit-elle utiliser ?

Trois conditions décident quel identifiant une réservation doit utiliser : quel système distribue l’adresse, si ce système voit jamais une trame de couche 2 et ce qu’il utilise comme clé client. Un routeur domestique en DHCP, un VPN ponté et un tunnel routé répondent différemment à ces questions. Choisir l’identifiant est plus durable que de vouloir figer chaque adresse MAC qu’un adaptateur signale, car l’identifiant est ce que l’allocateur lit réellement.

Partez de l’allocateur et remontez ; l’identifiant côté client est ce que ce système accepte.

Interrogez d’abord l’allocateur

Un serveur DHCP alloue dans un pool et compare les réservations à un identifiant qu’il reconnaît, qui peut être l’adresse matérielle, une chaîne d’identifiant de client ou un DUID selon la version du protocole. Un serveur VPN alloue dans son propre pool et compare à ce que son modèle de configuration expose, souvent le Common Name authentifié. Un réseau ponté peut confier le même problème au serveur DHCP qui sert déjà le LAN. Chacun est une recherche différente, et une réservation valable dans l’un est invisible aux autres.

Confirmez ce que le serveur voit réellement avant de configurer quoi que ce soit. Une réservation qui nomme le mauvais identifiant échoue en silence : le client reçoit simplement une adresse du pool, et l’erreur ressemble à un problème de client.

Là où une adresse MAC compte encore

Sur une liaison Ethernet ou Wi-Fi physique, l’adresse matérielle identifie une interface sur ce segment. Les fonctions de confidentialité la font tourner, les adaptateurs virtuels en créent de nouvelles, et un ordinateur portable peut présenter des valeurs différentes en Wi-Fi et sur une station d’accueil. Un tunnel TUN routé transporte des paquets IP et ne transmet pas l’identité sans fil d’origine à un serveur DHCP distant, donc une réservation basée sur MAC sur ce chemin n’a rien à comparer. TAP diffère : il transporte des trames Ethernet et peut rejoindre un domaine ponté où les identifiants de couche 2 comptent encore.

Même là, l’adresse pertinente est celle utilisée sur ce domaine, pas automatiquement celle de la liaison physique montante.

Les adresses de tunnel et les clés de pair ont leur propre espace

Un déploiement OpenVPN routé attribue des adresses via son propre modèle : une configuration par client indexée par un nom authentifié, ou un pool explicite. Modifier la réservation DHCP d’un routeur LAN ne crée pas cette attribution, et ajouter une réservation de tunnel n’influence pas le LAN. WireGuard va plus loin, car un pair est identifié par sa clé publique et ses adresses autorisées, et non par un identifiant matériel. Aucune réservation Ethernet générique ne remplace la configuration de pair à cet endroit.

Tenez un inventaire qui sépare quatre objets : l’identifiant d’appareil, l’adaptateur virtuel, l’identifiant de l’allocateur et l’adresse attribuée. Une même machine physique peut avoir plusieurs adaptateurs, adresses et sessions.

Une adresse stable n’est pas une identité

Une adresse prévisible est pratique sur le plan opérationnel et n’est pas un identifiant d’authentification. Les règles d’accès qui reposent sur une adresse cessent d’être des contrôles d’identité dès qu’elle est réattribuée, partagée ou usurpée. Si une règle dépend de l’adresse, coordonnez la réattribution et la révocation avec le propriétaire de l’identité, et gardez la vraie décision d’authentification ailleurs. Ainsi, une commodité ne devient pas la seule preuve de l’appareil qui s’est connecté.

Enregistrez ensemble l’allocateur, l’identifiant et l’adresse attribuée. Quand l’un change, les deux autres sont ce que vous vérifiez.

Si deux systèmes prétendent tous deux allouer pour le même sous-réseau, décidez lequel le possède avant d’ajouter des réservations à l’un ou l’autre.