Les routes VPN importées diffèrent du client qui fonctionne ? Comparez les deux

Certains services privés répondent via le VPN tandis que le trafic internet ordinaire se comporte très différemment de ce qu'il fait sur la machine d'un collègue, et la tentation est de conclure que le client Ubuntu est cassé. Cette conclusion saute une étape. Une opération privée qui fonctionne et un chemin public différent sont deux observations, et la différence se trouve généralement dans la politique de trafic installée par chaque client, pas dans le client lui-même.

Comparer la configuration enregistrée à l'état réel du réseau demande trois commandes et répond à la question que les suppositions tentaient de résoudre.

D'abord le profil enregistré, ensuite l'état effectif

Une connexion OpenVPN importée devient un profil NetworkManager à part entière. Le fichier .ovpn dont elle provient cesse d'être la source de vérité dès que l'importation se termine, donc modifier ce fichier plus tard ne change rien à la connexion que vous utilisez. C'est le premier endroit où la comparaison se trompe, et elle se trompe silencieusement.

nmcli -f connection.id,connection.uuid,ipv4.never-default,ipv4.routes,ipv4.dns connection show office-vpn

Lisez l'UUID lorsque les noms entrent en collision ; les noms en double survivent aux réinstallations et aux restaurations de profils, et vous pouvez passer une heure à modifier la copie qui n'est pas utilisée. Les valeurs affichées décrivent l'intention enregistrée : si le profil peut prendre la route par défaut, quelles routes ont été stockées et quels résolveurs et domaines de recherche il demande. Elles ne décrivent pas ce qui s'est passé à l'activation de la connexion, car un greffon ou une poussée du serveur peut ajouter un état que le profil ne mentionne pas. C'est pourquoi la commande suivante compte.

Regardez ensuite ce que le système a réellement fait de cette intention, y compris les règles de politique et toutes les tables, pas seulement la table principale. Les propriétés enregistrées sont des entrées, et les tables installées sont le résultat.

ip -4 rule show
ip -4 route show table all

Deux destinations, une comparaison

Choisissez une destination privée qui fonctionne et une destination publique ordinaire, puis demandez au noyau quel chemin chacune prendrait. C'est le fait de le faire sur les deux machines qui transforme une différence vague en différence précise.

ip -4 route get 10.40.0.20
ip -4 route get 203.0.113.20

Les adresses sont des exemples à remplacer par les vôtres ; l'important est la paire, pas les nombres. Comparez l'interface, l'adresse source et la table nommée dans chaque sortie. Quand la recherche privée nomme le tunnel et que la recherche publique nomme aussi le tunnel, vous avez un tunnel complet et l'autre client peut en avoir un divisé, ou l'inverse.

N'exigez pas que les deux clients impriment un texte identique. Dans OpenVPN, redirect-gateway def1 s'exprime souvent par deux routes de demi-préfixe plutôt que par une route par défaut, et un gestionnaire qui les affiche différemment n'en est pas incorrect pour autant. Jugez la couverture, que montrent les recherches, et non le formatage.

Où les deux clients diffèrent légitimement

Les valeurs par défaut des clients sont des choix de politique, et elles ont le droit de diverger. Un produit peut préférer un tunnel complet, un autre peut conserver la valeur locale par défaut et ne router que les préfixes privés, et un troisième peut suivre ce que le serveur a poussé. Une différence n'est un défaut que lorsqu'elle contredit l'exigence qui vous a été donnée.

Comparez donc chaque client à l'intention approuvée de tunnel divisé ou complet, et non l'un à l'autre. Si l'exigence est que le trafic privé utilise le tunnel et que le chemin internet local reste local, alors un tunnel complet est le défaut et un tunnel divisé est correct, quel que soit le client qui a fait quoi. Écrivez l'intention avant de regarder l'une ou l'autre configuration, sinon le premier client que vous inspectez devient discrètement la référence.

Le DNS est un second axe et il échoue indépendamment. Une route correcte peut encore envoyer des requêtes à un résolveur qui ne sait pas répondre pour la zone privée, et un résolveur correct ne corrige pas une route erronée. Vérifiez les deux, et considérez un nom privé qui se résout alors qu'une adresse privée ne le fait pas comme la preuve que les deux couches sont résolues séparément.

Gardez la comparaison propre

N'exécutez qu'un seul propriétaire de connexion à la fois. Une session OpenVPN en ligne de commande qui tourne à côté du profil importé installe ses propres routes et son propre état de résolveur, et le mélange obtenu n'est le comportement d'aucun des deux clients. Arrêtez l'une avant de mesurer l'autre. Redémarrez si vous n'êtes pas sûr de ce qui détient encore un état, car une route périmée d'il y a une heure ressemblera exactement à un problème de politique.

Gardez aussi tout le reste fixe : le même point de terminaison, le même compte, les mêmes versions logicielles, le même réseau. Un succès sur l'ordinateur portable Windows d'un collègue teste un autre client, une autre intégration de résolveur et peut-être un autre profil de serveur, ce n'est donc pas une preuve concernant le gestionnaire Ubuntu.

La référence des paramètres IPv4 de NetworkManager définit précisément never-default et les propriétés de routes enregistrées, ce qui vaut la peine d'être lu avant de modifier une valeur gérée. Et rappelez-vous la portée de cette comparaison : elle couvre IPv4 et ne dit rien de la politique IPv6 correspondante, qui a ses propres valeurs par défaut et sa propre façon de vous surprendre.