Vous mettez le SSID invité sur le VPN et appelez le segment réservé au VPN. Puis le tunnel tombe pendant deux minutes et les appareils reviennent discrètement sur le WAN ordinaire. Rien dans le nom du SSID ne l'a empêché. Un segment réservé au VPN se définit par ce qui se passe lorsque le tunnel est indisponible, pas par l'étiquette du réseau.

L'étiquette est une promesse ; la politique de repli est l'application.

Mythe : le SSID est la frontière

Un SSID sans politique de transfert propre n'est qu'un nom. La frontière est une interface, un VLAN ou un sous-réseau distinct, avec sa propre étendue DHCP et ses propres règles. Un VLAN vous donne une frontière de transfert qu'un nom Wi-Fi ne peut pas donner.

L'isolation des clients fait aussi partie de la conception. Deux appareils du segment peuvent avoir besoin de communiquer entre eux, ou non, et ce choix doit être explicite plutôt qu'hérité d'un profil invité.

Notez l'interface et la plage d'adresses du segment avant d'écrire une seule règle. Cette ligne évite l'essentiel de la confusion ultérieure.

Mythe : la route du tunnel couvre tous les protocoles

Appliquez la politique du firmware à ce segment pour que son trafic vers Internet utilise le tunnel. Configurez le transfert et la traduction distants que le tunnel exige. Ne gardez que l'accès aux ressources locales dont le segment a réellement besoin.

Vérifiez les deux familles d'adresses. Si IPv6 n'est pas transporté par le tunnel, la politique doit le gérer, sinon un appareil compatible IPv6 trouvera une route directe que vous n'aviez pas prévue.

Un coupe-circuit limité à IPv4 avec IPv6 activé est une façon courante de fuiter. Testez avec un client compatible IPv6, pas seulement avec l'ordinateur portable que vous avez sous la main.

Mythe : le DNS et le point de terminaison du tunnel suivent le tunnel

Le DNS du routeur peut être généré localement et suivre sa propre table de routage, et non la politique du segment. Décidez quel chemin ce résolveur doit emprunter et ce qu'il fait quand le tunnel échoue. La connexion propre du point de terminaison du VPN est une autre exception : elle a besoin de la route extérieure documentée vers le pair. Acheminez cette connexion dans le tunnel et elle ne pourra pas monter.

Gardez l'administration de récupération séparée de l'accès Internet du segment. Si un pair défaillant vous enferme aussi hors du routeur, vous avez transformé une panne de tunnel en visite sur site. Gardez cet accès sur un réseau de gestion, pas sur le segment réservé au VPN.

Ce qui le rend réellement réservé au VPN

Bloquez le transfert ordinaire vers le WAN pour le segment chaque fois que le tunnel est indisponible. C'est cette règle, pas le SSID, qui rend l'étiquette vraie. Testez-la avec un trafic inoffensif depuis un appareil du segment.

Faites trois vérifications : le fonctionnement normal par le tunnel, le test de panne autorisé avec le tunnel indisponible, et la récupération à son retour. Confirmez qu'un autre segment du foyer conserve sa route prévue tout du long. Documentez toute exception directe, sinon l'étiquette cache des chemins dont vous ne vous souvenez plus.

Un court relevé du segment, du tunnel choisi et des exceptions vous donne des vérifications précises après qu'une mise à jour du firmware a changé l'ordre des règles ou le comportement du résolveur. La recette de client WireGuard pour pfSense est une référence utile pour le côté tunnel, pas un substitut à la politique du segment.

Articles similaires