Le tunnel complet est-il plus simple qu’une longue liste de tunnel fractionné ?

Une liste de tunnel fractionné commence avec trois applications et finit par couvrir la majeure partie de la machine, et chaque nouvelle ligne est l’exception de quelqu’un. À ce stade, la liste est devenue discrètement un réglage par défaut avec des étapes en plus. Le tunnel complet inverse la disposition : tout entre dans le tunnel sauf si une exclusion documentée dit le contraire. Que ce soit plus simple dépend de la passerelle et des services locaux que vous casseriez.

Commencez par compter les règles que vous maintenez

Comptez les entrées, puis comptez combien ont un propriétaire nommé et une date de dernière vérification. C’est le second nombre qui compte, car une exception que personne ne possède ne peut pas être évaluée quand le logiciel auquel elle renvoie est renommé ou remplacé. Les règles liées à un chemin d’exécutable échouent silencieusement après une mise à jour, et la panne ressemble à un VPN instable plutôt qu’à une règle périmée. Écrivez la liste avant d’avoir un avis sur elle.

Chaque entrée devrait répondre à trois questions : qu’est-ce qui casse sans elle, qui l’a décidé et comment remarqueriez-vous que la raison a expiré. Les entrées incapables de répondre aux trois sont candidates à la suppression plutôt qu’à la migration, et les supprimer d’abord rend la comparaison ultérieure honnête.

Si la plupart des entrées routent une large part du trafic, vous exploitez déjà un tunnel complet avec une charge de maintenance attachée. La décision porte alors sur l’endroit où vit le réglage par défaut, pas sur son existence.

Vérifiez si la passerelle peut porter le réglage par défaut

Le tunnel complet déplace chaque paquet vers un seul appareil, ce qui change en même temps sa charge processeur, sa table conntrack, la traduction d’adresses et le besoin de bande passante montante. Une passerelle qui servait confortablement quelques sous-réseaux internes n’a peut-être pas été dimensionnée pour toute la navigation d’un utilisateur. Regardez le plus grand nombre de sessions simultanées que vous attendez plutôt que la moyenne, car c’est le pic qui casse en premier.

ip -s link show dev tun0
conntrack -C
ss -s

Mesurez la même charge avant et après le changement au lieu de raisonner à partir de spécifications. Un seul après-midi d’usage ordinaire sur une machine montrera si la passerelle approche d’une limite, et cela ne coûte rien comparé au fait de le découvrir un lundi matin.

Vérifiez aussi la MTU du chemin de bout en bout, car un réglage par défaut complet expose chaque application à la taille maximale de paquet du tunnel. Des applications qui fonctionnaient hors du tunnel peuvent désormais dépendre d’un comportement de fragmentation que vous n’aviez jamais eu à considérer.

Confirmez que les services locaux et le DNS privé fonctionnent encore

Énumérez ce qui doit rester local par protocole plutôt que par nom d’application : protocoles de découverte pour imprimantes et écrans, un pont domotique, la page d’administration d’un routeur, un serveur de développement local joignable par un nom qui ne se résout que sur le LAN. Ces éléments cassent quand la route par défaut commence à pointer dans un tunnel, et ils cassent discrètement parce que rien ne consigne d’erreur chez le client.

Le DNS privé est l’autre dépendance. Si les noms internes étaient auparavant résolus par le résolveur du tunnel, rien ne change ; s’ils étaient résolus localement, un réglage par défaut complet doit les porter vers un résolveur qui connaît les zones. Testez un nom interne et un nom public après le changement au lieu de supposer que la liste de résolveurs a survécu.

Écrivez les exceptions locales dans le profil qui les possède. Une exception gardée uniquement dans la mémoire de quelqu’un est la première chose que la migration suivante perd.

Migrez un profil et vérifiez les frontières

Modifiez le profil via sa propre configuration au lieu de superposer un nouveau réglage par défaut sur des routes manuelles laissées par des expériences antérieures. Ces routes résiduelles sont la cause habituelle d’une migration qui semble fonctionner et se comporte de façon incohérente un jour plus tard. Gardez l’ancien profil disponible pour qu’un retour soit une sélection et non une reconstruction.

Vérifiez ensuite deux frontières séparément : que les destinations publiques et privées fonctionnent toutes deux, et que le trafic indésirable ne sort pas en dehors du tunnel. Un chargement de page réussi prouve la première et ne dit rien de la seconde.

ip route get 203.0.113.10
ip route get 10.40.8.15
resolvectl query intranet.example
curl -sS -o /dev/null -w "%{remote_ip}\n" https://example.com

Répétez le contrôle après une reconnexion et après une coupure, car un commutateur qui bloque le trafic pendant une coupure est une propriété différente d’une route qui se rétablit correctement ensuite. La conception la plus simple est celle dont vous pouvez encore expliquer la couverture réelle après qu’une application ou un réseau a changé.