Route statique sur la FRITZ!Box : pointez-la vers l’IP LAN de la passerelle VPN

Votre LAN domestique compte une FRITZ!Box comme routeur par défaut et un petit boîtier Linux qui assure le service VPN à côté. Le boîtier atteint le réseau du bureau, le portable derrière la FRITZ!Box non. Une route statique règle cela en trois champs, et la seule vraie difficulté est de refuser de mettre une adresse de tunnel dans le champ passerelle. La passerelle est le routeur suivant de votre propre LAN, et elle l’a toujours été.

Écrivez les trois champs avant d’ouvrir l’interface

Prenez un LAN 192.168.50.0/24, une FRITZ!Box sur 192.168.50.1, et un boîtier VPN avec une adresse fixe 192.168.50.2 qui dispose déjà d’un chemin protégé fonctionnel vers 10.40.0.0/16. La route dit : pour ce préfixe distant, remettez le paquet à l’appareil situé à l’adresse LAN fixe. Le point de terminaison public du serveur VPN distant et son adresse de tunnel interne sont tous deux sans importance ici, car la FRITZ!Box ne leur envoie jamais rien directement.

Réservez cette adresse LAN en dehors de la plage DHCP, sinon la passerelle configurée appartiendra un jour à un téléphone.

Où la FRITZ!Box conserve la route

FRITZ! ouvre les contrôles de routes IPv4 sous Réseau domestique, puis Réseau, puis Paramètres réseau, le libellé et l’imbrication exacts dépendant du modèle et de la version de FRITZ!OS. Activez la vue étendue si la table de routage est masquée, ajoutez une entrée avec les valeurs ci-dessus, puis appliquez. Le guide de votre modèle précis vaut un coup d’œil, car la même fonction a changé de place plus d’une fois entre les versions. Notez la formulation exacte de l’entrée que vous enregistrez, car une entrée de table indique rarement quel écran l’a produite.

Ce n’est pas la même fonction que lorsque la FRITZ!Box termine elle-même un VPN. Une route désigne un autre appareil ; le VPN intégré est cet appareil.

La passerelle doit router, pas seulement joindre

Un hôte qui atteint le réseau distant n’est pas automatiquement un routeur pour le reste du LAN. Le boîtier VPN a besoin du transfert IP activé, d’une règle de pare-feu autorisant le transfert entre l’interface LAN et le tunnel, et d’une route qui renvoie la réponse vers le LAN au lieu de la faire sortir par son propre chemin par défaut. Activer le transfert et oublier la règle de pare-feu est le demi-correctif le plus courant, et côté client cela ressemble à une panne de routage.

Vérifiez-le côté FRITZ!Box en pingant l’adresse LAN du boîtier VPN, puis depuis un client en traçant vers une adresse distante et en confirmant que le deuxième saut est ce boîtier.

Chemin de retour et plages qui se chevauchent

Le côté distant a besoin d’une route pour 192.168.50.0/24 en retour par le tunnel, sauf si vous traduisez délibérément la source sur le boîtier VPN. Conserver et traduire sont des politiques différentes, avec des journaux différents et des règles d’accès différentes, et la route statique que vous venez d’ajouter ne choisit pas entre elles. Les plages qui se chevauchent sont un problème plus difficile : si votre LAN et le réseau distant partagent un préfixe, une seule route d’hôte ne peut pas les distinguer, et le plan d’adressage doit changer.

Ajouter une route plus spécifique ailleurs sur le LAN, ou un second client VPN sur le portable, l’emportera discrètement sur l’entrée de la FRITZ!Box.

Testez depuis un client normal, puis testez la panne

Lancez le test depuis une machine LAN autorisée ordinaire, pas depuis le boîtier VPN, car le boîtier fonctionnait déjà et ne prouve rien. Atteignez un service distant et vérifiez la réponse, puis confirmez que des destinations internet sans rapport prennent toujours la route par défaut et ne sont pas traînées dans le tunnel. Remplacer la route par défaut pour joindre un sous-réseau est un changement bien plus lourd que l’entrée à trois champs par laquelle vous avez commencé.

Enfin, déconnectez le VPN et regardez ce qui se passe. La route statique reste dans la table alors que sa passerelle a perdu le chemin protégé, donc le trafic échoue sur le boîtier au lieu de retomber sur internet, et toute exigence de bloquer le trafic de repli relève de la politique du boîtier lui-même, pas d’une route enregistrée.