Faites persister le transfert IPv4 après un redémarrage de la passerelle VPN

Le ping de la passerelle fonctionne et l’accès à quoi que ce soit derrière elle non, et c’est la forme d’un problème de transfert plutôt que d’un problème de tunnel. La remise locale à la passerelle prouve que le tunnel est monté et que l’attribution d’adresse a fonctionné ; elle ne dit rien sur la question de savoir si le noyau fera passer un paquet d’une interface à une autre. Avant de toucher un sysctl, confirmez que la machine est censée router ce trafic et localisez le contexte réseau qui contient l’interface tournée vers le client. Lisez ensuite la valeur là, et non là où le dernier guide que vous avez lu a regardé par hasard.

Atteindre la passerelle n’est pas la même chose que transférer

Deux décisions distinctes ont lieu à l’intérieur du noyau. La remise à une adresse locale termine le voyage du paquet ; le transfert le renvoie par une autre interface, et cette seconde décision est régie par espace de noms réseau. Une passerelle peut être parfaitement joignable alors que le transfert est désactivé, et depuis une invite ping les deux pannes se ressemblent.

Notez par quelle interface le paquet client arrive et par quelle interface le chemin suivant sort. Les deux appartiennent à un seul espace de noms, et cet espace de noms détient le réglage qui compte.

Lisez la valeur là où les paquets se trouvent réellement

Sur une passerelle qui route dans l’espace de noms de l’hôte, une seule commande répond à la question : sysctl net.ipv4.ip_forward. Quand le chemin d’entrée et le chemin suivant vivent dans un espace de noms nommé, interrogez cet espace de noms : ip netns exec vpn-gw sysctl net.ipv4.ip_forward. La valeur de l’hôte ne remplace pas la valeur de l’espace de noms, et un un sur l’hôte ne prouve rien.

Tous les contextes de routage n’ont pas d’étiquette que vous puissiez transmettre à ip netns. Les environnements d’exécution de conteneurs et les services créent des espaces de noms qui ne sont jamais enregistrés sous un nom convivial, et pour ceux-là vous utilisez les outils d’inspection de l’environnement. Remplacez vpn-gw par le nom réel, ou par le mécanisme de l’environnement qui atteint le même contexte, et cessez de deviner au niveau de l’hôte.

Donnez au réglage un seul propriétaire

Sur une passerelle hôte systemd classique, la forme durable est un fichier drop-in portant un nom choisi par l’administrateur, comme /etc/sysctl.d/60-vpn-forwarding.conf, contenant net.ipv4.ip_forward = 1. Écrivez le fichier, puis chargez ce fichier précis pour que l’état actif change aussi : sudo sysctl -p /etc/sysctl.d/60-vpn-forwarding.conf, suivi d’une relecture. Le nom du fichier est un exemple et non un chemin VPN réservé, et le nombre initial compte parce que les fichiers triés plus tard gagnent.

La précédence est l’endroit où la persistance se casse en silence. Vérifiez à la fois le chargeur de la distribution et votre propre drop-in, car procps sysctl --system lit aussi /etc/sysctl.conf à la fin, tandis que l’ordre sysctl.d de systemd est une séquence entièrement différente. Une affectation plus tardive peut remettre la même clé, laissant votre fichier correct et la valeur effective fausse. N’écrasez pas un fichier d’administrateur existant pour gagner ce débat ; trouvez le propriétaire et modifiez-le là.

Un espace de noms créé après le démarrage n’est pas du tout régi par un drop-in de l’hôte. Son réglage appartient à ce qui le crée, que ce soit l’environnement d’exécution des conteneurs ou l’unité de provisionnement de l’espace de noms. Accorder à un conteneur de larges privilèges d’hôte pour esquiver la question est un pire marché que de passer dix minutes à identifier le bon propriétaire.

Sachez ce que coûte l’interrupteur avant de le basculer

ip_forward n’est pas un booléen inoffensif. La documentation du noyau note que le changer réinitialise plusieurs autres paramètres IPv4 à leurs valeurs par défaut d’hôte ou de routeur, si bien qu’un basculement de diagnostic peut jeter un réglage fait ailleurs sans jamais le mentionner. Traitez-le comme un changement de configuration avec des effets secondaires, et non comme une sonde que l’on lance à la légère.

Cela exclut aussi de le désactiver puis de le réactiver chaque fois qu’un client n’atteint pas un hôte. Si la valeur vaut déjà un, la panne est ailleurs sur le chemin, et réécrire la même clé une troisième fois ne la déplacera pas.

Prouvez la persistance, puis testez le reste du chemin

Relisez la valeur à quatre moments : juste après le changement, après l’apparition de l’interface VPN, après une reconnexion et après un redémarrage planifié. Une valeur qui revient en arrière à l’un de ces points a un second propriétaire, et une écriture ponctuelle de plus ne fait que la cacher jusqu’au prochain redémarrage.

Le transfert activé laisse encore trois choses à vérifier. Le client a besoin d’une route vers la destination, la passerelle a besoin d’une route suivante plus l’autorisation de l’utiliser, et la destination a besoin d’un chemin de retour vers l’adresse du tunnel du client. Un LAN privé routé n’a pas automatiquement besoin de NAT, donc n’ajoutez pas de masquerading avant de savoir laquelle des trois manque, et testez depuis le client prévu plutôt que depuis la passerelle elle-même, car une requête née sur la passerelle ne touche jamais le chemin de transfert que vous venez d’activer. IPv6 porte sa propre politique de transfert et de routage, donc un test IPv4 qui fonctionne ne dit rien à son sujet.

Gardez ensemble dans le runbook le chemin du drop-in, le propriétaire de l’espace de noms et la commande de relecture. Celui qui reprendra cela ensuite doit pouvoir lire la valeur, voir qui la possède et décider en une minute si le problème est la persistance ou le reste du chemin.