Une passerelle VPN a besoin du transfert IP : quoi vérifier

Votre client peut pinguer l’adresse de la passerelle alors que toutes les ressources derrière elle restent injoignables. Cette paire d’observations décrit un hôte qui vous parle et un routeur qui ne route pas, deux rôles différents sur la même machine. Le transfert est l’interrupteur entre les deux.

Les deux rôles sont indépendants, tout comme les deux familles d’adresses.

Répondre à sa propre adresse ne prouve rien

Quand un paquet est adressé à la passerelle elle-même, la pile locale le consomme et aucune décision de transfert n’a lieu. C’est pourquoi un ping réussi vers l’adresse du tunnel ou une interface de gestion vous dit que le démon est vivant et le tunnel monté, sans rien dire du trafic destiné à un réseau derrière la boîte. Le noyau ne consulte son chemin de transfert que pour les paquets qui ne lui sont pas adressés.

Lisez l’exigence comme un rôle, pas comme un réglage : cet hôte doit déplacer des paquets entre deux interfaces. Un ordinateur portable qui a seulement besoin d’atteindre un réseau distant n’assume jamais ce rôle, et un point de terminaison site à site l’assume toujours. Lire l’exigence ainsi explique pourquoi une configuration client qui fonctionne échoue lorsqu’elle est déplacée vers une passerelle.

La même phrase s’applique au pare-feu devant la décision de transfert, qui a sa propre politique sur ce qui peut être transféré.

Vérifiez chaque famille d’adresses séparément

Le transfert IPv4 est un interrupteur, et le transfert IPv6 en est un autre avec son propre comportement par interface. Activer le premier ne dit rien du second, et un client double pile peut atteindre la moitié d’un réseau tandis que le reste reste sombre. Deux clients de familles différentes peuvent donc être en désaccord sur la même passerelle. Demandez quelle famille le client en échec a utilisée avant de modifier l’un ou l’autre réglage. Confirmez les deux avant de conclure que la conception du routage est erronée.

sysctl net.ipv4.ip_forward
sysctl -a --pattern 'net.ipv6.conf.(all|default).forwarding'
nft list ruleset | head -n 40

Sur de nombreuses distributions, la valeur que vous lisez à l’exécution y a été placée par un service ou un fichier de configuration, si bien qu’une modification faite avec une commande unique peut disparaître au redémarrage. Trouvez le fichier qui possède le réglage avant de modifier la valeur d’exécution.

Le transfert est l’une des quatre exigences

Un flux transféré qui fonctionne a besoin de quatre choses à la fois : le client doit savoir que la destination est derrière le tunnel, la passerelle doit avoir une route vers l’avant, les réponses doivent avoir un chemin de retour, et le pare-feu doit autoriser le trafic. La traduction de source fait partie de cette conception comme option plutôt que comme règle, car un réseau routé privé à chemins symétriques n’en a pas besoin et un réseau asymétrique en a généralement besoin. Chacune des quatre échoue indépendamment, ce qui explique pourquoi réparer l’une déplace rarement le symptôme. Écrivez les quatre avant d’en changer une.

Les plateformes cloud ajoutent une cinquième considération. Certaines appliquent des contrôles de source et de destination sur les instances, ce qui supprime les paquets transférés quel que soit ce que le noyau de l’invité est configuré pour faire. La documentation réseau de la plateforme elle-même fait autorité, pas la sortie de sysctl dans la VM.

Testez depuis le client, pas depuis la passerelle

Un test lancé dans le shell de la passerelle elle-même ne parcourt aucune partie du chemin de transfert que vous venez d’activer. Générez le trafic depuis le client qui a le problème et confirmez qu’il atteint quelque chose derrière la passerelle plutôt que la passerelle elle-même. C’est le seul test qui exerce le rôle que vous avez modifié.

Gardez les règles d’écoute et les règles de transfert distinctes dans votre tête et dans le journal des changements. Ouvrir le port VPN admet les clients au service ; cela ne leur accorde rien sur le réseau derrière, et les deux se ressemblent dans une liste de pare-feu qui a grossi pendant des années.

Si les paquets arrivent et que le service rejette ensuite l’utilisateur, vous avez dépassé le réseau. Continuez avec l’autorisation applicative au lieu d’élargir à nouveau la politique de transfert.