Comment réparer les routes de tunnel fractionné qui masquent un sous-réseau NAS domestique

Eva Wong

IceWhale author

Eva Wong est la rédactrice technique et bricoleuse résidente chez ZimaSpace. Geek depuis toujours, passionnée par les homelabs et les logiciels open source, elle se spécialise dans la traduction de concepts techniques complexes en guides accessibles et pratiques. Eva croit que l’auto-hébergement doit être amusant, pas intimidant. À travers ses tutoriels, elle donne à la communauté les moyens de démystifier les configurations matérielles, depuis la construction de leur premier NAS jusqu’à la maîtrise des conteneurs Docker.

How to Fix Split-Tunnel Routes That Hide One Home NAS Subnet - Zima Store Online

Restaurez le sous-réseau NAS manquant en ajoutant la route bidirectionnelle la plus spécifique tout en laissant inchangés les chemins de tunnel fractionné fonctionnels.

Dans un VPN domestique, un réseau NAS peut disparaître même si le tunnel est connecté et que d’autres sous-réseaux privés restent accessibles. La cause habituelle n’est pas le service NAS lui-même, mais une route manquante, une route locale plus large qui prévaut, un préfixe de réseau domestique qui se chevauche, une passerelle de tunnel erronée ou un chemin de retour qui ne sait pas comment atteindre le client VPN. La solution la plus sûre est de comparer un sous-réseau fonctionnel avec le sous-réseau caché, de corriger une décision de routage à la fois, et de vérifier à la fois le trafic aller et retour avant d’élargir le tunnel.

Vérifiez qu’un seul sous-réseau NAS est manquant

Connectez le VPN et testez séparément trois destinations : la passerelle VPN, un sous-réseau privé connu fonctionnel, et le sous-réseau NAS qui échoue. Utilisez d’abord des adresses IP directes afin que le DNS, la découverte SMB et les noms d’hôtes ne brouillent pas le résultat du routage.

Le tunnel fractionné envoie uniquement certains préfixes de destination via le VPN, tandis que le reste du trafic suit la route par défaut ordinaire du client. Une explication pratique des routes fractionnées spécifiques aux sous-réseaux montre qu’un client peut considérer le réseau VPN lui-même comme accessible tout en envoyant un sous-réseau privé voisin vers la mauvaise passerelle.

Si la passerelle VPN et un autre sous-réseau distant fonctionnent, le tunnel et l’authentification sont déjà établis. Concentrez le diagnostic sur le préfixe NAS manquant, la préférence de route, la politique de pare-feu et le chemin de retour plutôt que de reconstruire toute la configuration VPN.

Comparez la route choisie pour une adresse fonctionnelle et une adresse défaillante

Inspectez la table de routage du client après la connexion du tunnel et interrogez la route sélectionnée pour une adresse distante fonctionnelle et une adresse NAS. Notez le préfixe de destination, la longueur du préfixe, la métrique, l’interface et le saut suivant utilisés pour chacune.

Une route existante n’est pas automatiquement la route qui prévaut. Les systèmes d’exploitation préfèrent normalement le préfixe le plus long correspondant, donc une route locale 192.168.1.0/24 peut remplacer une route VPN plus large comme 192.168.0.0/16 pour les adresses exactes qui se chevauchent.

Si l’adresse NAS suit la passerelle Wi-Fi ou Ethernet locale, ajoutez ou annoncez une route VPN plus spécifique pour le sous-réseau NAS. Si elle suit déjà le tunnel, poursuivez avec la politique VPN, le transfert distant et le routage de retour plutôt que d’ajouter des routes client en double.

Éliminez le chevauchement entre le réseau client et le réseau NAS

Comparez le sous-réseau privé utilisé par l’emplacement actuel du client distant avec le sous-réseau privé derrière le VPN domestique. Les hôtels, bureaux, points d’accès mobiles et autres domiciles réutilisent fréquemment des plages communes telles que 192.168.0.0/24 ou 192.168.1.0/24.

Une discussion récente sur GlobalProtect décrit comment une route fractionnée large peut entrer en conflit avec le réseau privé local du client. Le client peut croire que l’adresse NAS se trouve sur son Wi-Fi proche et ne jamais envoyer le paquet dans le VPN.

La solution la plus propre à long terme est de renuméroter le VLAN NAS domestique ou le LAN distant vers un préfixe moins courant. Lorsque la renumérotation n’est pas possible, utilisez un sous-réseau VPN traduit, une route spécifique à l’hôte, un proxy d’application ou une conception VPN qui résout délibérément le chevauchement plutôt que de compter sur des adresses privées ambiguës.

Featured

ZimaCube 2 NAS personnel Cloud à domicile

ZimaCube2

Corrigez le préfixe et la passerelle du tunnel fractionné

Examinez la liste côté serveur des routes incluses ou des sous-réseaux autorisés et confirmez qu’elle contient exactement le réseau NAS avec le masque correct. Une erreur typographique telle que /25 au lieu de /24 peut masquer seulement la moitié des adresses prévues.

Un cas Cisco VPN a trouvé des routes fractionnées installées avec la mauvaise passerelle de route même si la plage d’adresses VPN elle-même semblait correcte. C’est pourquoi la route opérationnelle du client importe plus que l’étiquette de route configurée.

Supprimez les routes obsolètes ou en double, reconnectez le VPN et vérifiez qu’une route autoritaire apparaît pour le préfixe NAS. N’ajoutez pas de route par défaut via le tunnel sauf si le tunnel complet est le design prévu ; corriger un sous-réseau ne doit pas rediriger silencieusement tout le trafic internet.

Vérifiez le transfert, le pare-feu et la route de retour

Capturez ou enregistrez le trafic sur la passerelle VPN pendant que le client ping l’adresse NAS. Si le paquet entre dans le tunnel mais ne sort jamais vers le VLAN NAS, inspectez le transfert IP, les règles de pare-feu inter-interface et la route de la passerelle VPN vers ce sous-réseau.

Un guide d’implémentation de tunnel fractionné souligne que l’installation de la route doit être associée à une politique de transfert et de pare-feu correspondante. Une route côté client seule ne peut pas faire en sorte que la passerelle VPN transfère le trafic vers un autre VLAN.

Confirmez ensuite que le routeur du sous-réseau NAS a une route de retour vers la plage client VPN. Si les réponses utilisent la passerelle internet normale à la place, ajoutez la route de retour ou appliquez un NAT source soigneusement ciblé sur la passerelle VPN. Une capture unidirectionnelle réussie sans réponses est un échec du chemin de retour, pas une raison de continuer à modifier la route client.

Retestez le service NAS sans perturber les autres chemins

Après que la connectivité IP fonctionne, testez le service NAS réel par IP puis par nom d’hôte. Confirmez SMB, le tableau de bord web ou le port d’application requis sans supposer qu’un ping réussi prouve le chemin de l’application.

Le guide ZimaSpace sur un chemin VPN-vers-LAN manquant fournit la leçon voisine que la connectivité du tunnel ne garantit pas que tous les types de trafic LAN suivent le même chemin.

Terminez en testant le sous-réseau NAS réparé, un sous-réseau distant précédemment fonctionnel, et l’accès internet ordinaire. Conservez la modification uniquement lorsque les trois se comportent comme prévu, que la route survit à la reconnexion, et que le client n’a pas besoin d’une commande manuelle après chaque changement réseau.