NAS injoignable via le VPN : adresse, chemin de retour ou service ?

Les tunnels montent, les clients obtiennent une adresse, et le NAS ne répond absolument rien. Ce seul symptôme recouvre trois pannes sans rapport, et l'ordre dans lequel vous les testez décide de la durée de la réparation. L'adressage vient d'abord, car un sous-réseau qui se chevauche peut envoyer votre requête vers un appareil inconnu. Le chemin de retour vient ensuite, car une requête qui arrive sans réponse ressemble exactement à un service fermé. Le service et l'autorisation viennent en dernier, et seulement une fois les deux premiers prouvés.

Trois pannes qui se lisent toutes comme injoignable

Le choix d'adresse, le routage de retour et l'autorisation de service produisent le même message visible : rien ne se passe. Ils ont des preuves, des responsables et des corrections différents, donc les séparer constitue toute la tâche. Un ping qui échoue prouve peu à lui seul, et un refus TCP réussi est en fait une bonne nouvelle.

Lisez le tableau comme un ordre de tests plutôt que comme une liste de causes. Chaque ligne contraint la suivante, car un refus prouve déjà que l'adressage et le chemin de retour fonctionnent. Passer vingt minutes dans les règles de pare-feu avant de vérifier quelle interface la route a choisie est la façon la plus courante de perdre un après-midi. Travaillez de haut en bas et arrêtez-vous à la première ligne qui correspond.

Condition un : cette adresse est-elle le bon appareil ?

Notez le sous-réseau du NAS et la plage que le VPN attribue aux clients, puis comparez les deux avec le réseau sur lequel se trouve votre ordinateur portable en ce moment. Dans ce parcours, le NAS est à 10.40.7.25 et le pool du VPN est 10.40.9.0/24, deux plages privées distinctes dans un même plan de site ; un foyer qui utilise 192.168.0.0/24 ou 10.0.0.0/24 a bien plus de chances d'entrer en collision avec l'une d'elles.

Lorsque le réseau local et le réseau du NAS se chevauchent, le client envoie ce trafic vers sa propre passerelle et peut atteindre un appareil sans rapport qui possède par hasard la même adresse. Vérifiez le chemin avant de saisir des identifiants dans quoi que ce soit qui répond.

ip -4 route get 10.40.7.25
traceroute -n -m 5 10.40.7.25

La première commande indique l'interface et la passerelle que le noyau utiliserait, et la seconde montre les premiers sauts qui répondent réellement. Si les deux ne concordent pas, croyez la recherche, car c'est le chemin que prendra le paquet. Une liste de sauts qui s'arrête un saut avant le NAS est aussi une constatation et non un échec. Une recherche qui se résout vers l'adaptateur physique au lieu du tunnel termine l'enquête à ce stade.

Condition deux : la réponse revient-elle ?

Le client a besoin d'une route vers le NAS, et le réseau du NAS a besoin d'un chemin de retour vers le pool du VPN. Le transfert par passerelle, les règles de pare-feu et la traduction volontaire affectent chacun cette paire. les notes de transfert de strongSwan décrivent les choix de route de retour et de traduction pour un sous-réseau privé derrière une passerelle.

Lorsque la requête arrive et que la réponse sort par une autre passerelle, aucun changement de DNS ne répare l'asymétrie. Une capture des deux côtés le tranche en une seule tentative, et elle montre aussi si la traduction a réécrit la source à laquelle le NAS a répondu. L'administrateur est responsable de cette frontière : n'autorisez que les services nécessaires et la plage de clients du VPN, et notez si le routage ou la traduction a été choisi.

Condition trois : le service est-il présent et autorisé ?

Une page d'administration et un service de partage de fichiers sont des points de terminaison différents sur la même machine, et l'un peut accepter des connexions pendant que l'autre est bloqué par le pare-feu de l'hôte, la configuration du service ou une autorisation de partage. Un appareil qui répond par un refus a déjà prouvé les deux premières conditions, ce qui réduit beaucoup la troisième.

Testez avec le compte qui a réellement besoin des fichiers, et non avec le compte administrateur utilisé pendant l'installation, car les droits d'administration ne peuvent pas réparer une route manquante et une route ne peut pas accorder une autorisation de partage. Les noms ont aussi leur place ici : un nom de NAS découvert à la maison dépend souvent du multicast local, qu'un tunnel routé ne transporte pas, alors essayez le nom d'hôte privé documenté par le fabricant ou l'adresse elle-même pour séparer le nommage de l'accès.

Testez depuis l'extérieur du réseau du NAS, puis élargissez lentement

Un test effectué sur le même LAN masque chaque partie incomplète du chemin distant, et c'est pourquoi la première tentative distante réussie mérite une note dans le journal des changements. Lancez les contrôles depuis un client qui n'atteint le NAS que par le tunnel, et conservez le texte d'erreur d'origine de chaque tentative.

nc -vz 10.40.7.25 445
smbclient -L 10.40.7.25 -U guest

Une fois le chemin fonctionnel, transférez un fichier inoffensif et confirmez le comportement de lecture ou d'écriture dont vous avez réellement besoin. Si les transferts volumineux bloquent alors que les petits réussissent, le problème restant est la gestion de la taille des paquets ou la stabilité de la connexion, et non l'adressage.

Ne publiez pas de ports de partage de fichiers ou d'administration sur internet pour contourner une panne inexpliquée. Réparez le chemin privé, gardez le logiciel du NAS pris en charge, et testez la restauration de tout ce que vous sauvegardez à travers lui avant de compter sur cette sauvegarde.