Une adresse MAC modifiée sur un Pi : quelle interface a changé ?
Un pont, un périphérique TAP et une liaison physique portent chacun leur propre identité. Comparez le même objet avant et après la connexion, puis trouvez qui l’a configuré.
Après l’installation d’un VPN sur un Pi, plusieurs identités d’interface peuvent sembler s’être déplacées. L’adresse Ethernet d’hier ne correspond plus à la liste d’aujourd’hui, et la conclusion s’écrit d’elle-même : le VPN a changé la MAC. En général, ce n’est pas le cas. Comparer une liaison physique à un pont ou à un adaptateur virtuel n’est pas une comparaison, et le premier travail consiste à décider quel objet vous regardez vraiment.
Nommez l’interface et l’observateur
Notez le nom du périphérique, le type d’interface, l’adresse actuelle de la couche de liaison et le gestionnaire qui la possède. Ajoutez l’horodatage, car un affichage modifié au démarrage est un événement différent de celui qui a changé lorsque le tunnel est monté.
Faites-le pour la même interface avant et après l’événement de connexion. Deux observations d’un même objet sont une preuve ; une seule observation de deux objets est une coïncidence à laquelle on a collé une histoire. La différence, c’est toute l’enquête. Trompez-vous d’objet et chaque mesure ultérieure est perdue.
Si une réservation DHCP fait partie du problème, notez quelle identité client l’allocateur a réellement reçue. Une liste de bureau, une identité de pont et une ancienne entrée de bail sont trois enregistrements différents, et un seul d’entre eux est ce que le routeur a vu.
TUN, TAP et la liaison sont des objets différents
Le noyau trace une frontière nette entre les deux types virtuels. TUN transporte des paquets IP et n’a aucune identité Ethernet. TAP transporte des trames Ethernet et en a donc une.
Cela signifie qu’une adresse côté TAP n’est pas l’adresse de la liaison physique, et qu’une adresse TUN routée ne remplace pas une MAC Wi-Fi. Ce sont des couches différentes de la même machine.
Un pont est un troisième objet. Il possède sa propre adresse de couche de liaison, dérivée ou configurée indépendamment des ports qui y sont rattachés, si bien qu’un pont qui monte peut changer ce qu’affiche une liste sans toucher au moindre matériel. Les ports conservent leurs propres adresses en dessous. Son adresse peut aussi être fixée explicitement, et rien alors n’en dérive du matériel.
Qui est réellement à l’origine d’un vrai changement
Si la même interface physique change réellement d’adresse, examinez le profil de connexion actif avant d’attribuer une cause. Les réglages de confidentialité, les réglages de clonage et un périphérique virtuel recréé produisent tous ce symptôme sans aucune intervention du VPN.
La proximité dans le temps n’est pas une causalité. Un tunnel qui démarre et un profil réappliqué surviennent souvent dans la même seconde parce que l’un a déclenché l’autre, et le changement d’adresse appartient au profil. Lisez le profil avant de lire le journal du tunnel.
Distinguez aussi une interface recréée d’un périphérique existant. La configuration persistante et l’interface d’exécution sont des objets liés, et ni l’une ni l’autre n’est une identité matérielle permanente.
Ce que signifient les valeurs de clonage d’un gestionnaire
La référence des réglages Ethernet de NetworkManager sépare une adresse explicitement attribuée de valeurs spéciales telles que preserve, permanent, random et stable, avec des orthographes différentes en ligne de commande et dans l’interface D-Bus.
Ces valeurs sont une capacité prise en charge par un seul gestionnaire. Elles ne prouvent pas que cette image exécute ce gestionnaire, que ce profil a utilisé la randomisation ou qu’un processus VPN a réécrit une carte réseau. Seule la configuration active sur cet hôte répond à cela.
Vérifiez le propriétaire du réglage plutôt que d’installer un second gestionnaire pour le rendre disponible. Deux gestionnaires qui se disputent une interface produisent exactement l’instabilité que les gens imputent ensuite au tunnel.
Corrigez l’exigence d’identité, pas l’affichage
Là où une réservation locale est nécessaire, suivez le mécanisme d’identité client propre à l’allocateur et faites-le concorder avec la configuration de l’interface. Épingler une adresse de pont ou de tunnel sans rapport pour qu’une liste paraisse stable ne résout rien. Cela crée aussi une seconde identité que personne n’a documentée.
Un VPN routé distant authentifie son propre pair et attribue des adresses selon son propre modèle. Figer une adresse LAN n’enrôle pas ce pair et ne crée pas d’attribution de tunnel fixe.
Avant un changement d’identité approuvé, gardez la configuration précédente récupérable, surtout sur une machine sans écran auprès de laquelle vous ne pouvez pas vous rendre. Vérifiez ensuite la même interface et le même service local après une reconnexion.
Le constat qui mérite d’être écrit est celui de l’objet qui a changé, de qui l’a configuré et de la question de savoir si cela viole le contrat d’identité que vous vouliez. Tout ce qui est plus large est une supposition habillée en conclusion. Les constats étroits survivent aussi à la relecture.