Pourquoi net.ipv4.conf.default.forwarding laisse tun0 tranquille

Vous définissez net.ipv4.conf.default.forwarding=1, vous redémarrez le VPN, et le tunnel continue de jeter des paquets que la passerelle devrait router. Le réglage semble correct dans le fichier, et l'interface signale toujours que le transfert est désactivé. Rien n'est cassé : vous avez modifié la valeur dont héritent les futures interfaces, pas celle qu'utilise le tunnel actif.

Parcourez cela sur l'hôte qui possède le tunnel, dans le namespace réseau où le tunnel existe réellement. Un conteneur ou un namespace réseau peut détenir l'interface pendant que l'hôte affiche d'autres chiffres.

Lisez les trois valeurs ensemble

Commencez par comparer l'interrupteur global de la passerelle, le modèle des nouvelles interfaces et l'interface qui vous intéresse. Remplacez tun0 par l'interface d'entrée réelle, et lisez aussi l'interface de retour, car le transfert est évalué au point où le paquet arrive.

sysctl net.ipv4.ip_forward
sysctl net.ipv4.conf.default.forwarding
sysctl net.ipv4.conf.tun0.forwarding

Un résultat courant est ip_forward = 0, default.forwarding = 1 et tun0.forwarding = 0. Les deux premières ne s'accordent pas sur le rôle de l'hôte, et la troisième montre ce que fait réellement l'interface. Cette combinaison correspond à un hôte qui n'a jamais été configuré comme routeur, mais qui a seulement reçu une valeur de modèle. Les trois nombres ne se contredisent pas ; ils répondent à trois questions différentes. Écrire la valeur du modèle ne décide pas non plus du rôle de l'hôte.

Pourquoi c'est l'interrupteur global qui bouge

net.ipv4.ip_forward est le contrôle global de la passerelle. Le modifier met à jour les réglages de transfert par interface dans la même opération, ce qui explique qu'une seule écriture puisse faire commencer le transfert d'un tunnel existant. default.forwarding ne sème que les interfaces initialisées ensuite, donc un tunnel qui existait déjà garde la valeur avec laquelle il est né.

La documentation du noyau signale ip_forward comme particulier pour une raison liée : le modifier réinitialise un ensemble d'autres paramètres IPv4 aux valeurs par défaut d'hôte ou de routeur. Cela en fait un outil brutal. Le définir une fois dans le cadre de l'établissement du rôle de passerelle est acceptable ; le basculer à répétition comme astuce de débogage peut réécrire silencieusement une configuration que vous avez mis du temps à obtenir.

Les valeurs par interface existent aussi pour une raison. Une passerelle gérée volontairement peut garder le transfert désactivé sur une interface qui ne devrait jamais router, même lorsque l'hôte transfère ailleurs. C'est pourquoi lire l'interface active compte et pourquoi la valeur globale seule n'est pas toute la réponse. Lisez une telle exception comme une décision délibérée, et notez pourquoi cette interface est différente. Sinon, l'ingénieur suivant la "réparera" bien aimablement.

Rendez le réglage permanent au bon endroit

Un sysctl -w ponctuel réussi prouve que le noyau accepte la valeur. Il ne survit pas à un redémarrage, et il ne survit pas à un gestionnaire de réseau qui réapplique sa propre idée de la configuration de l'interface à la reconnexion. Placez le rôle de passerelle dans le fichier de configuration sysctl ou dans le gestionnaire de réseau qui possède l'hôte, puis redémarrez le service qui l'applique.

L'ordre compte avec les tunnels. Si le gestionnaire crée l'interface au démarrage et applique le transfert ensuite, l'interface peut hériter de l'ancien défaut. Un redémarrage de service qui recrée le tunnel est aussi un événement de création, et il est facile de le manquer quand l'unité semble saine. Vérifiez la séquence, pas seulement le contenu final du fichier.

Relisez les mêmes trois valeurs après la reconnexion du VPN et de nouveau après un redémarrage. Un tunnel nouvellement créé est une nouvelle interface, et une nouvelle interface prend le défaut en vigueur au moment de la création. Si les chiffres changent au fil de ces événements, la configuration est appliquée par quelque chose que vous n'avez pas encore identifié.

Ne réparez pas cela avec le mauvais outil

Quand le transfert semblait cassé, la tentation est de vider le pare-feu ou d'ajouter du masquerading. Ni l'un ni l'autre ne traite l'interrupteur de transfert. L'état du transfert, l'autorisation de transférer, une route vers la destination et un chemin de retour sont quatre exigences distinctes, et seule la première est le sysctl.

Testez aussi avec le bon flux. Une requête faite sur la passerelle elle-même n'exerce pas du tout le transfert ; c'est du trafic généré localement. La question est de savoir si un paquet venant d'un client VPN ou d'un hôte du LAN est accepté et routé plus loin, donc le test doit partir de derrière la passerelle.

Gardez le cas IPv6 à part

Ici, tout est IPv4. Le transfert IPv6, les annonces de routeur et le comportement d'accept_ra ont leurs propres contrôles, et copier un chemin ipv4 dans un réglage ipv6 produit un fichier qui semble plausible et ne fait rien d'utile. Une passerelle double pile a besoin que les deux ensembles soient configurés délibérément.

Une dernière vérification : une fois les valeurs d'accord, confirmez que la route du tunnel est sélectionnée pour la destination et que le chemin de retour existe. Le transfert activé sur une interface sans route reste un trou noir, et cette panne est identique vue du côté client.