Le tunnel complet a tué votre session SSH : épinglez la route retour

Lancez un OpenVPN client sur la machine où vous travaillez via SSH, et en pleine commande la session se fige. Le tunnel se dit connecté, l'hôte atteint Internet à travers lui, et vos frappes clavier arrivent encore alors que rien ne revient. Ce qui a changé n'est pas le tunnel : c'est le chemin de retour des paquets qui vous sont destinés, lequel correspond désormais à la nouvelle route par défaut et entre dans un tunnel que la passerelle distante n'utilisera pas pour rejoindre votre poste.

Ce que redirect-gateway installe réellement

Dans sa forme def1, redirect-gateway ajoute 0.0.0.0/1 et 128.0.0.0/1 au lieu d'écraser la route par défaut. Ces deux moitiés couvrent tout l'espace d'adresses tout en restant des préfixes plus longs que 0.0.0.0/0, donc toute destination sans correspondance plus spécifique part désormais dans le tunnel. C'est le mécanisme à retenir, car chacun des correctifs ci-dessous fonctionne en installant une correspondance plus spécifique.

Votre adresse d'administration est l'une de ces destinations.

Le serveur VPN achemine le trafic de ses clients vers Internet. Il n'a aucune route pour l'adresse publique depuis laquelle vous vous connectez, et aucune raison de traiter ces paquets autrement que comme du trafic venant d'un client, il les jette donc. Pendant ce temps, la requête que vous avez envoyée a bien atteint l'hôte, ce qui explique pourquoi la session ne paraît vivante que d'un côté.

ip route show table main | head -n 20
ip route get 198.51.100.23

Trouvez votre adresse source et le chemin d'avant le tunnel

Sur le serveur, listez la connexion SSH établie et notez l'adresse du pair d'où elle vient. Cette adresse est celle que votre route de retour doit couvrir, et ce n'est pas toujours celle que vous croyez : un hôte de rebond, une passerelle NAT ou un traducteur opérateur peut substituer une autre source.

Cherchez ensuite la passerelle physique et l'interface qui portaient le trafic avant le démarrage du tunnel. Dans la def1 disposition, la route par défaut est toujours présente sous les demi-routes par défaut, l'information est donc disponible, même si lire une longue table de routage à l'œil invite aux erreurs.

Notez les deux valeurs et le nom de l'interface ensemble, car la route que vous allez ajouter a besoin des trois. Si l'hôte utilisait une règle de routage par politique pour choisir son uplink, une route simple risque de n'être jamais consultée, et cette possibilité change le correctif.

Épinglez une route d'hôte qui prime sur les demi-routes par défaut

Une route /32 est plus longue que l'une ou l'autre demi-route par défaut, si bien que les réponses à votre adresse la prennent de préférence au tunnel. Le prochain saut est la passerelle d'avant le tunnel et le périphérique est l'interface physique, ce qui maintient le paquet sur le chemin qu'il utilisait avant l'existence du tunnel.

ip route add 198.51.100.23/32 via 203.0.113.1 dev eth0

Vérifiez par une recherche plutôt qu'en inspectant la table : la réponse doit nommer eth0 et la passerelle, jamais tun0.

OpenVPN ajoute déjà une route d'hôte vers l'adresse du serveur VPN lui-même pour la même raison, le schéma est donc familier et l'adresse d'administration n'est qu'une exception de plus. N'utilisez pas route-nopull pour corriger cela, car il écarte les routes poussées dont le tunnel a besoin, y compris le réseau distant et les options DNS.

Faites-lui survivre à une reconnexion

Une route ajoutée à la main disparaît lorsque le client se reconnecte et réinstalle la sienne, ce qui transforme un correctif en panne récurrente. Rattachez la commande à quelque chose qui s'exécute après l'installation des routes.

Un script route-up ou le hook pre-up du gestionnaire de réseau font tous deux l'affaire, et la vérification fiable est une reconnexion suivie de la même recherche.

Sous Windows, l'équivalent est une route persistante ajoutée avec -p, qui survit aux redémarrages mais doit toujours pointer vers la bonne passerelle après un changement de réseau. Quelle que soit la plateforme, écrivez la raison à côté de la route : le prochain administrateur doit savoir qu'elle existe pour protéger une session de gestion, et non parce que la conception du réseau l'exigeait.

Quand une route épinglée ne suffit toujours pas

Le filtrage par chemin inverse peut jeter un paquet qui arrive par une interface et repart par une autre, ce qui est exactement ce que crée une route épinglée. Vérifiez la valeur effective de rp_filter avant de désactiver quoi que ce soit globalement, et préférez corriger l'asymétrie plutôt que de couper le contrôle. C'est le réglage par interface qui s'applique, et le mode loose ne fait souvent qu'enregistrer l'asymétrie au lieu de jeter le paquet. Lisez les deux avant de conclure que le filtre est en cause.

Les hôtes en routage par politique ont besoin d'une règle autant que d'une route, car la base de règles choisit la table avant que la route qu'elle contient ne soit consultée. Une route de la table main est invisible pour un flux qui correspond à une règle pointant vers une autre table. Lisez les règles avant d'ajouter quoi que ce soit à main. Si une règle couvre déjà le trafic de gestion, l'exception appartient plutôt à la table de cette règle.

Gardez une console hors bande ouverte pendant vos tests, et revérifiez depuis une seconde connexion avant de déconnecter celle que vous utilisez. Une route qui envoie votre propre trafic de gestion dans le tunnel coupe la connexion à travers laquelle vous la réparez. Y revenir ensuite impose une console série ou un démarrage de secours, ce qui est un mauvais échange pour avoir sauté une étape de vérification.