Tunnel complet FortiClient : ne router que le sous-réseau du bureau

Le tunnel monte, l'icône passe au vert et le réseau local disparaît : imprimantes, le NAS et le routeur du bureau cessent tous de répondre. FortiClient fait ce que le profil a demandé. La passerelle a poussé une route par défaut, le client l'a installée, et chaque paquet a désormais un chemin dans le tunnel. La réparation est une modification de la table de routage suivie d'une modification DNS, et l'ordre de ces modifications décide si la machine s'en sort mieux ou moins bien.

Ce que le client a installé, et pourquoi le LAN a disparu

Commencez par lire la table plutôt que l'interface du client. Sous macOS, netstat -rn imprime toute la table et route -n get default nomme l'interface et la métrique qui l'emportent actuellement ; sous Linux, la paire est ip route show et ip route get 8.8.8.8. Les deux répondent à une question : quelle entrée portera un paquet qui ne correspond à rien de plus précis.

Le nom du périphérique de tunnel n'est pas fixe. Un profil IKEv2 sous macOS affiche généralement utun avec un numéro, le client SSL VPN affiche ppp0, et OpenVPN affiche tun0. Deux routes par défaut peuvent aussi être présentes en même temps avec des métriques différentes, et l'entrée du client peut ne prendre le dessus qu'après une reconnexion plutôt qu'à l'instant où elle apparaît. C'est pourquoi deux vidages de la table pris à cinq minutes d'intervalle peuvent raconter des histoires différentes.

Pourquoi la route par défaut du tunnel doit partir en premier

Le noyau choisit le préfixe correspondant le plus long, et lorsque plusieurs routes sont aussi précises, il choisit celle dont la métrique est la plus basse. Un client qui installe 0.0.0.0/0 avec une meilleure métrique gagne donc chaque destination sans supprimer la route par défaut d'origine, et c'est pourquoi la route physique est toujours dans la table et explique toujours la panne. Retirer d'abord la route par défaut du tunnel restaure le comportement précédent. C'est seulement ensuite qu'une route de préfixe par le tunnel fait ce que son auteur voulait.

Ajouter des préfixes avant cette étape est l'erreur qui produit une machine à moitié fonctionnelle. Le trafic du nouveau préfixe suit le tunnel, et tout ce qui n'est pas listé suit aussi la route par défaut du tunnel, donc rien ne semble cassé avant que quelqu'un ouvre un service que personne n'a ajouté. Supprimez, restaurez, puis ajoutez, et l'état intermédiaire reste prévisible.

La séquence sous macOS et sous Linux

Sous macOS, la séquence supprime la route par défaut du tunnel, restaure la route par défaut physique et renvoie un préfixe du bureau dans le tunnel. Remplacez les noms d'interface illustratifs ici par ceux de votre propre table.

sudo route delete -net default -interface utun4
sudo route add -net 0.0.0.0 -interface en0
sudo route add -net 10.20.0.0 -netmask 255.255.0.0 -interface utun4

Sous Linux, le même ordre utilise un autre outil, avec la passerelle du LAN pour la route par défaut et le périphérique de tunnel pour le préfixe du bureau. L'ancienne commande route accepte encore l'ancienne syntaxe, mais ip route est la forme qui correspond à la documentation actuelle.

sudo ip route del default dev tun0
sudo ip route add default via 192.168.50.1
sudo ip route add 10.20.0.0/16 dev tun0

Lorsque la route a besoin d'un saut suivant plutôt que d'un périphérique, prenez le peer dans la sortie du client. Deviner produit l'une de deux erreurs, et elles signifient des choses différentes : une passerelle erronée donne network unreachable immédiatement, tandis qu'une cible de tunnel erronée donne un délai d'attente. Lisez laquelle vous avez obtenue avant de changer à nouveau la commande.

Préfixes, le résolveur et la DMZ qui reste sombre

Un préfixe couvre rarement le travail. Les serveurs d'applications, les réseaux d'administration, la DMZ et les serveurs DNS eux-mêmes peuvent chacun se trouver dans une plage différente, alors listez toutes les plages que vous pouvez nommer avant de commencer et testez une résolution à côté de chaque ping. Une destination découverte en cours de test est celle qu'on oublie dans le journal des changements. Une route qui répond par adresse mais échoue par nom est généralement un problème de résolveur déguisé en routage.

Le résolveur est une décision distincte. Lorsque le profil a poussé des serveurs DNS internes, retirer la route par défaut peut laisser ces adresses inaccessibles pour les noms publics ou accessibles seulement par le tunnel, et les deux états produisent des résultats partiels déroutants. Routez les adresses du résolveur par le tunnel, ou configurez une résolution par domaine pour que les requêtes publiques utilisent le résolveur local.

Le client SSL Linux a une panne spécifique à un champ qu'il vaut la peine de connaître : le tunnel se connecte, le LAN du bureau répond, et une plage DMZ reste sombre. La pièce manquante est une route pour cette plage via la passerelle du tunnel, et la passerelle diffère d'une machine à l'autre, donc une adresse codée en dur est la façon dont le prochain portable casse. Dérivez-la de l'état du client et gardez la commande autodocumentée :

PEER=$(ip -4 addr show dev ppp0 | awk '/peer/ {print $4}' | cut -d/ -f1)
sudo ip route add 192.168.30.0/24 via "$PEER"

Lisez les deux valeurs avant de l'exécuter. peer est l'extrémité distante d'un tunnel point à point, et c'est l'adresse dont la route DMZ a besoin ; sur un tunnel routé, l'équivalent est l'interface ou la passerelle que le client rapporte. Si aucune n'apparaît, le client n'est pas dans le mode que vous supposiez.

Après la prochaine connexion, et quand cesser de le faire en local

FortiClient se reconnecte après une veille ou un changement de réseau et réinstalle ce que le profil spécifie. Les routes manuelles ne survivent donc que jusqu'à la prochaine connexion, ce qui est exactement l'intervalle où un seul test réussi peut ressembler à une correction. Une route qui disparaît pendant la nuit est un comportement attendu, pas une nouvelle panne.

Il existe deux réponses durables. Un script qui relance la correction après chaque connexion est un contournement qui peut survivre à son auteur, tandis que un profil de tunnel partagé fourni par l'administrateur de la passerelle est la vraie correction, car le client n'installe alors que les plages dont le travail a besoin. Demandez la seconde et n'utilisez la première que pendant l'attente. Vérifiez aussi la politique que vous avez acceptée avant de partager un tunnel complet en local, car le réseau distant peut compter sur la visibilité de tout votre trafic.

La liste de contrôle est courte : lisez la table, supprimez la route par défaut du tunnel, restaurez la route par défaut du LAN, ajoutez chaque préfixe, corrigez la résolution séparément, et attendez-vous à ce que les routes reviennent à la reconnexion.