Le VPN de la FRITZ!Box se connecte mais rien ne répond : WireGuard ou IPSec

Le tunnel indique qu’il est connecté, l’icône est verte, et rien sur le LAN domestique ne répond. C’est la plainte la plus fréquente concernant l’accès distant de la FRITZ!Box, et ce n’est presque jamais le tunnel lui-même. Le plan d’adressage, l’identité du sous-réseau ou la table de routage du client sont faux. Lequel de ces éléments vous finirez par déboguer dépend de votre choix entre WireGuard et l’ancien IPSec Fernzugang, alors commencez par savoir ce que vous avez réellement configuré.

Le tunnel monte et le LAN reste muet

Un tunnel qui s’établit prouve que les clés et le point de terminaison sont corrects. Il ne prouve pas que le client a reçu une adresse vers laquelle la box peut router, ni que le client sait quels préfixes appartiennent au tunnel. Ce sont deux succès distincts, et seul le second vous permet d’atteindre une imprimante.

Vérifiez d’abord l’adresse du client, puis sa table de routage.

Si l’adresse attribuée se trouve hors du sous-réseau du LAN, la box n’a rien vers quoi router en retour. Si elle se trouve dans la plage DHCP, la box peut attribuer la même adresse à un appareil local. Les deux produisent un tunnel qui se connecte et un LAN qui vous ignore.

Ce que chaque option configure réellement

L’option IPSec génère un fichier de configuration pour un utilisateur, contenant la clé prépartagée et l’adressage. Vous l’importez dans un client qui parle le même profil, ce qui sous Windows signifie généralement l’outil du fabricant et non le client intégré. L’option WireGuard génère un peer pour un appareil : une paire de clés, une adresse à l’intérieur du tunnel et un point de terminaison.

Cette différence décide de votre modèle de maintenance. Chaque appareil WireGuard est un peer distinct avec sa propre clé, donc révoquer un téléphone perdu revient à supprimer un peer pendant que les autres continuent de fonctionner. IPSec révoque en changeant le secret partagé ou la configuration de l’utilisateur, ce qui est plus grossier et touche chaque appareil qui l’utilise.

Aucune des deux options n’est obsolète. La voie IPSec reste celle prise en charge partout où l’extrémité distante ne peut pas exécuter WireGuard.

Les champs IPSec qui produisent un tunnel mort

Quatre valeurs doivent concorder avec votre LAN, et trois d’entre elles échouent d’une manière qui ressemble à un tunnel cassé.

L’adresse réseau est celle qui piège les gens. Un sous-réseau est identifié par sa première adresse, qui se termine normalement par zéro, et y saisir une adresse d’hôte produit une configuration qui paraît tout à fait plausible et ne se connecte jamais. La plage DHCP compte pour une autre raison : les clients du tunnel sont généralement attribués au-dessus d’elle, donc une plage qui consomme tout le sous-réseau ne laisse rien à distribuer.

Les sous-réseaux qui se chevauchent sont l’autre cas classique. Si le LAN distant que vous rejoignez utilise le même préfixe que le LAN sur lequel vous êtes assis, le routage ne peut pas les distinguer, et renuméroter un des deux côtés est la seule vraie solution. Aucune quantité de configuration côté client ne le résout.

Pourquoi WireGuard échoue autrement

WireGuard n’a pas de clé prépartagée à mal saisir, donc ses échecs se regroupent plutôt autour de la définition du peer. Une liste d’IP autorisées qui omet le préfixe du LAN produit un tunnel qui ne transporte rien, parce que le client n’y envoie jamais le trafic destiné au LAN. Une clé publique périmée d’un côté ou de l’autre produit une poignée de main qui ne se termine jamais. Un point de terminaison manquant ou un port erroné produisent un silence plutôt qu’une erreur.

Comparez les deux côtés champ par champ au lieu de réimporter le fichier en espérant.

Le seul échec commun est la collision de sous-réseaux. WireGuard construira volontiers un tunnel vers un réseau qui chevauche le vôtre, puis la table de routage décide lequel des deux préfixes identiques l’emporte.

Prouvez-le depuis l’extérieur, puis gardez un chemin de retour

Testez depuis une connexion mobile, jamais depuis l’intérieur du LAN, car de l’intérieur vous testez un chemin qui n’implique pas du tout le tunnel. Notez quel port chaque option utilise avant de l’activer, et redirigez ce port vers la box.

Conservez le fichier généré quelque part où vous accédez sans le tunnel, et notez au passage le nom externe de la box.

Une configuration qui n’a jamais été testée depuis l’extérieur est un plan, pas un chemin d’accès distant qui fonctionne. Testez un hôte du LAN par adresse plutôt que par nom, pour qu’un échec DNS ne soit pas pris pour un échec de routage.