Pourquoi l’ordre des adaptateurs ne décide pas de la route VPN de votre labo

Que l’adaptateur 1 soit le premier dans la liste de l’hyperviseur n’est qu’un ordre d’affichage, et la table de routage de l’invité ne le lit pas. Ce qui décide du chemin, c’est le préfixe, la métrique et toute règle de stratégie qui s’applique avant les deux. Ajouter un adaptateur pont à une VM de labo peut donc créer un second chemin par défaut alors que l’ancienne interface NAT apparaît toujours comme présente et numérotée seconde. Le résultat est une VM qui utilise parfois le tunnel et parfois non, sans aucun changement de configuration qui l’explique.

Trois conditions décident du chemin

Les trois conditions sont le préfixe le plus spécifique, ce que font les métriques lorsque les préfixes sont à égalité, et les règles que l’invité a appliquées après la modification matérielle. Chacune se règle avec une seule commande, et aucune ne dépend de la numérotation de l’hyperviseur.

Ce dernier point est la décision : si vous ne pouvez pas dire quel préfixe l’emporte pour l’adresse propre du point de terminaison VPN, vous n’avez pas de stratégie de routage, vous avez une topologie qui fonctionne aujourd’hui par hasard.

Première condition : quel préfixe l’emporte

Une route vers 10.8.0.0/24 l’emporte sur une route par défaut pour une adresse à l’intérieur, quelles que soient les métriques et quel que soit l’ordre des adaptateurs. C’est pourquoi un client VPN qui installe une route spécifique continue de fonctionner même lorsqu’un second adaptateur apparaît avec une métrique plus faible : la spécificité l’emporte avant que le coût soit pris en compte. Vérifiez avec ip route show la table que vous croyez utilisée, et avec ip route get 203.0.113.9 la réponse que le noyau donnerait réellement pour une destination précise.

L’adresse propre du point de terminaison est le test qui compte le plus. Si l’adresse du serveur VPN se résout via un adaptateur pont récemment ajouté, le tunnel peut ne jamais s’établir, ou s’établir puis perdre son propre chemin de transport. Interrogez précisément cette adresse au lieu de supposer que l’interface du tunnel est la réponse.

Deuxième condition : ce que fait la métrique et ce qu’elle ne fait pas

Son rôle est plus étroit que la plupart ne l’imaginent. Les métriques départagent les routes vers le même préfixe ; elles ne permettent pas à une route plus large de battre une route plus spécifique. Un nombre plus faible est préféré en cas d’égalité, et différents systèmes d’exploitation comptent dans des sens opposés, ce qui explique que les conseils copiés entre Linux et Windows se contredisent souvent.

Dans l’invité, ip route show affiche la métrique à côté de chaque route, et Get-NetRoute sous Windows affiche une InterfaceMetric plus une métrique de route. Lisez les deux, car la préférence effective peut être une somme et non un seul champ. Si deux routes par défaut existent, c’est le constat : l’invité a deux sorties, et laquelle gagne dépend de nombres qu’une modification matérielle peut changer.

Troisième condition : ce que l’invité a réellement appliqué

La configuration n’est pas la même chose que l’état appliqué. Les noms d’interface ne sont pas stables lors des modifications matérielles sur toutes les plateformes, et une configuration qui correspondait à un nom peut désormais ne s’appliquer à rien.

Vérifiez l’état appliqué plutôt que l’état prévu. ip -br link montre les interfaces qui existent maintenant, et sur un hôte NetworkManager nmcli connection show montre quel profil est lié à quel périphérique. Un profil qui n’a pas pu se lier laisse l’interface active sans adressage, ce qui ressemble à un problème de routage et en est un de nommage. Les instantanés restaurés aggravent la chose, car l’état enregistré de l’invité peut référencer des identités d’adaptateur que le nouveau matériel ne fournit plus.

Gardez la topologie du labo reproductible

Enregistrez les raccordements réseau virtuels prévus à côté de la configuration de l’invité, afin que la correspondance entre rôle et adaptateur soit écrite plutôt que déduite d’une position dans une liste.

Quatre rôles suffisent généralement à nommer : liaison privée, gestion, transport extérieur et tunnel. Chacun devrait correspondre à un adaptateur précis et à une interface d’invité précise, dans un fichier.

Testez ensuite l’application réelle après une modification matérielle, un redémarrage ou un instantané restauré, et incluez la route vers le point de terminaison VPN dans ce test. Si une VM passerelle doit être l’unique sortie, vérifiez que la VM de test n’a pas de second chemin par défaut involontaire, car un second chemin par défaut est exactement ce qu’ajoute un adaptateur pont. Testez depuis l’invité, pas depuis la console de l’hyperviseur, car les deux peuvent ne pas être d’accord sur l’interface qui est laquelle.

La documentation réseau de VirtualBox décrit les modes d’adaptateur et ce à quoi chacun se rattache, et c’est la partie qui vaut la peine d’être lue avant d’en ajouter un second. Un labo qui identifie quel adaptateur sert chaque rôle rend un changement de route explicable. Un labo qui s’appuie sur la numérotation de l’hyperviseur transforme chaque changement en expérience.