Aller au contenu

Connexion Drive soudain impossible


Messages recommandés

J'ai subodoré un problème avec l'IPv6 car j'ai un problème quasi similaire avec une application musicale, Mopidy.
Mais avec Drive jamais eu de souci.

Pour le coup ça ne devrait pas être lié au port de synchro 6690, car quand on essaie de se connecter à Drive via l'application, on n'emploie pas ce port, on utilise le port de l'interface web, 5000 si pas de port personnalisé. J'imagine qu'avec un proxy inversé tu as défini un port personnalisé pour cette application.

Tu peux quand même vérifier que Drive est bien exposé pour les adresses IPv6 via :

netstat -tunlp | grep PORT_INTERFACE_WEB_DRIVE

Est-ce que le problème se produit autant en accès local qu'à distance ? ou seulement à distance ?

 

Lien vers le commentaire
Partager sur d’autres sites

il y a 59 minutes, .Shad. a dit :

netstat -tunlp | grep PORT_INTERFACE_WEB_DRIVE

le grep ne capture rien

il y a 59 minutes, .Shad. a dit :

Est-ce que le problème se produit autant en accès local qu'à distance ? ou seulement à distance ?

Je l'ai initialement constaté avec le smartphone connecté au WIFi, même LAN sur mon NAS.

Modifié par CoolRaoul
Lien vers le commentaire
Partager sur d’autres sites

il y a une heure, PiwiLAbruti a dit :

Essaye avec tcpdump :

$ sudo tcpdump -nq 'tcp port 6690'

 

Et j'attends combien de temps qu'il se passe quelque chose?

Note: j'ai lancé cette capture avec ma connexion Drive active en IPV4 (pendant laquelle j'ai fait un transfert de fichier) et je n'ai rien vu passer 

Et le port 6690 est bien en écoute autant en IPV4 qu'en IPV6

tcp        0      0 0.0.0.0:6690            0.0.0.0:*               LISTEN      19730/syncd
tcp6       0      0 :::6690                 :::*                    LISTEN      19730/syncd
[root@fserv_~]$ ps -fp 19730
UID        PID  PPID  C STIME TTY          TIME CMD
root     19730     1  0 Jan18 ?        00:27:49 /var/packages/SynologyDrive/target/sbin/syncd

 

Lien vers le commentaire
Partager sur d’autres sites

Cette commande affiche le moindre paquet qui transite par le port 6690. Si ton NAS a plusieurs interfaces réseau, il faut alors la préciser :

$ sudo tcpdump -nqi {ovs_}eth<n> 'tcp port 6690'

Le préfixe ovs_ doit être utilisé si VMM est installé sur le NAS afin de préciser l'interface virtuelle rattachée à l'interface physique.

n est le numéro de l'interface.

Lien vers le commentaire
Partager sur d’autres sites

il y a 22 minutes, PiwiLAbruti a dit :

Cette commande affiche le moindre paquet qui transite par le port 6690. Si ton NAS a plusieurs interfaces réseau, il faut alors la préciser

Une seule interface sur mon NAS.

En outre je maitrise cette commande que j'utilise régulièrement en particulier dans mon boulot.
Pour capturer sur toutes les interfaces j''utilise la syntaxe "-i any" plutôt.

Modifié par CoolRaoul
Lien vers le commentaire
Partager sur d’autres sites




Alors la question "Et j'attends combien de temps qu'il se passe quelque chose?" ne se pose pas
Reste que je trouve étrange de ne rien capturer étant donné que pendant que la capture était en cours j'ai visualisé un fichier du drive via l'appli Synology Drive via mon smartphone. 
Il sert à quoi ce port?
Lien vers le commentaire
Partager sur d’autres sites

il y a 27 minutes, PiwiLAbruti a dit :

Essaye déjà de voir comment ça se comporte avec un client desktop en local

C'est quand même un peu pénible d'avoir à installer le client local sur mon poste pour ce problème sur l'appli mobile et je n'ai pas trop d'espoir que ca donne quoi que ce soit
Mais je vais tester (et apres arrête, j'ai le workaround IPV4 qui me dépanne)

***EDIT***

Test effectué avec le client Windows, ça fonctionne sans probleme en local sans ralentissements

Et j'ai bien du traffic détecté sur le port 6690 (wireshark sur le poste Windows)
Mais je ne vois pas qu'en conclure

Modifié par CoolRaoul
Lien vers le commentaire
Partager sur d’autres sites

Il y a 18 heures, CoolRaoul a dit :

le grep ne capture rien

Ca ce n'est pas normal, voilà ce que j'ai chez moi :

drive_port_dsm.png

drive_port_ssh.png

On voit bien que l'application est disponible pour les deux protocoles.

Pour moi la longueur d'établissement de la connexion vient du fait que ton périphérique essaie de se connecter en IPv6. Mais il n'obtient qu'un timeout, et fait donc un fallback sur de l'IPv4. La question est : comment parvient-il à résoudre si le nom d'hôte utilisé n'amène que vers de l'IPv6 ? Possible qu'il essaie de passer par l'extérieur, si ta zone DNS publique a un enregistrement wildcard.

Est-ce que tu as une zone DNS locale ou bien tu te sers de la zone publique et du loopback pour rester dans la boucle locale ?

Lien vers le commentaire
Partager sur d’autres sites

il y a 53 minutes, .Shad. a dit :

Ca ce n'est pas normal, voilà ce que j'ai chez moi

Bien entendu tu as fait "grep 10002" et pas "grep PORT_INTERFACE_WEB_DRIVE" comme on me l'a demandé

D'ailleurs je l'ai refait un peu plus tard avec "grep 6690" et j'ai posté le résultat ici :
image.png

il y a 53 minutes, .Shad. a dit :

Pour moi la longueur d'établissement de la connexion vient du fait que ton périphérique essaie de se connecter en IPv6. Mais il n'obtient qu'un timeout, et fait donc un fallback sur de l'IPv4.

Ca y ressemble

Je viens de faire un test avec mon smartphone connecté uniquement sur le réseau mobile

Le port 5001 de mon NAS n'est pas accessible en IPV6 mais c'est OK en IPV5
Faut que je vérifie le firewall (et reboote ma box aussi j'imagine)

 

 

 

Modifié par CoolRaoul
Lien vers le commentaire
Partager sur d’autres sites

Tout redémarré, pas mieux. C'est donc bin ça
Quelle est la bonne configuration (Zone DNS + firewall NAS) pour rendre ce dernier accessible en IPV6?

**EDIT***

Ca se confirme, mes tests de connectivité en IPV6 vers mon NAS échouent.
J'imagine que le timout avant fallback sur de IPv4 est plus long pour Drive que pour les autres applications ce qui explique ce que je constate.

Dans ma zone DNS pour l'enregistrement AAA associé à mon NAS j'ai mis adresse qui s'affiche dans panneau de configuration -> interface réseau -> addresse IPv6 (en supprimant le /64)
C'est pas bon alors?

Modifié par CoolRaoul
Lien vers le commentaire
Partager sur d’autres sites

Je m'étais arrêté à Cloud Station qui n'utilisait que le port tcp/6690, mais Synology Drive utilise en plus les ports de DSM (tcp/5000-5001) :

https://kb.synology.com/fr-fr/DSM/tutorial/What_network_ports_are_used_by_Synology_services

Quelle adresse utilise sur l'application Synology Drive ? (une adresse de la forme drive.domain.tld:443 en reverse proxy de DSM ?)

Lien vers le commentaire
Partager sur d’autres sites

il y a 8 minutes, PiwiLAbruti a dit :

Quelle adresse utilise sur l'application Synology Drive ? (une adresse de la forme drive.domain.tld:443 en reverse proxy de DSM ?)

SI la question adresse à moi je ne la comprends pas 🤔

Et sinon j'ai mieux cerné le problème: il me semble que je n'ai *pas du tout* de connectivité IPV6 entre le monde extérieur et mon NAS.
Comment résoudre ça ?

Modifié par CoolRaoul
Lien vers le commentaire
Partager sur d’autres sites

il y a 20 minutes, CoolRaoul a dit :

SI la question adresse à moi je ne la comprends pas 🤔

Et sinon j'ai mieux cerné le problème: il me semble que je n'ai *pas du tout* de connectivité IPV6 entre le monde extérieur et mon NAS.
Comment résoudre ça ?

Attention, il n'est pas nécessaire d'avoir un LAN en IPv6 pour que tout fonctionne correctement...

Lien vers le commentaire
Partager sur d’autres sites

Attention, il n'est pas nécessaire d'avoir un LAN en IPv6 pour que tout fonctionne correctement...
Je sais bien mais je souhaite comprendre ce qui se passe.
Pour le moment j'ai supprimé le record AAA de ma zone et tout est OK (plus de timeouts en particulier)
Ceci dit je me souviens clairement avoir validé la liaison ipv6 depuis l'extérieur à travers ma box dans le passé et je ne comprends pas ce qui a pu changer.
Reste qu'on peut déja conclure que l'écosystème Synology est hors du coup. Je vais continuer à investiguer de mon côté.
Lien vers le commentaire
Partager sur d’autres sites

il y a 14 minutes, PiwiLAbruti a dit :

Comme tu es chez Free, vérifie que le pare-feu IPv6 est bien désactivé sur la box, et que le pare-feu du NAS laisse bien passer les IPv6 nécessaires.

Je ne suis pas sûr que désactiver le parefeu IPv6 de la freebox soit une bonne idée...

Il est activé sur la mienne.

Lien vers le commentaire
Partager sur d’autres sites

il y a une heure, MilesTEG1 a dit :

Je ne suis pas sûr que désactiver le parefeu IPv6 de la freebox soit une bonne idée...

L'ennui est qu'il n'y a pas de pare-feu sur la mienne, juste un switch tout ou rien.

il y a une heure, PiwiLAbruti a dit :

Comme tu es chez Free, vérifie que le pare-feu IPv6 est bien désactivé sur la box, et que le pare-feu du NAS laisse bien passer les IPv6 nécessaire

Ce n'est pas évident de déterminer quelles sont ces "IPV6 necessaires", quel critère appliquer ?

Pour le moment, sur le NAS, pour bien j'ai une règle en tête de liste qui laisse tout passer en V6 en local (en amont de mes autres filtres, uniquement V4) en attendant mieux.

De toutes façons il est désormais clair que le pb n'est pas coté NAS : je viens de vérifier avec mon imprimante connectée, qui supporte IPV6 et ça ne passe pas non plus alors que je me souviens clairement avoir réussi à avoir une connexion IPV6 la dernière fois ou j'avais pris le temps de faire ce genre de manip.

Mon but désormais est essentiellement de comprendre le mécanisme mais il est probable que je bloque tout au niveau de la box ensuite.

Lien vers le commentaire
Partager sur d’autres sites

Il y a 3 heures, CoolRaoul a dit :

Bien entendu tu as fait "grep 10002" et pas "grep PORT_INTERFACE_WEB_DRIVE" comme on me l'a demandé

Ouais ça me semblait logique désolé, c'était à remplacer par le port que tu as affecté. 😛 

Pour l'IPv6, je vois plusieurs points qui peuvent te poser problème.
Est-ce que ton NAS dispose d'une IPv6 routable ? c'est déjà un préalable pour communiquer avec l'extérieur, une IP routable commencera probablement par "2a" de ton côté.
Si c'est le cas, tu peux vérifier que la connectivité est fonctionnelle en faisant un :

ping -6 ipv6.google.com

Maintenant au niveau du pare-feu, si le but est d'accéder à ton NAS via l'extérieur en IPv6, sans utiliser de NAT, il faut autoriser le protocole ICMP, car autant ton NAS ne sera pas pingable de l'extérieur en IPv4 (ça s'arrête généralement à la box qui les refuse par défaut assez souvent), autant en IPv6 c'est problématique l'ICMP fait partie intégrante de l'établissement d'une connexion entre deux périphériques (en IPv6, ce ne sont pas les routeurs intermédiaires qui font le travail de fragmentation des paquets, mais les périphériques aux extrêmités, la MTU minimale est calculée par ces derniers et assure qu'on peut aller du point A au point Z).

Moi j'ai donc une règle en entête qui autorise toutes les requêtes ICMP de toutes les sources (cela comprend IPv6 et IPv4, on ne peut pas les dissocier dans DSM, c'est dommage).

Localement, un périphérique peut communiquer via son IP publique avec un autre périphérique sans passer par l'extérieur, car les IPv6 ont une notion de portée que n'ont pas les IPv4.
Donc il faut aussi autoriser le préfixe de ton pool d'IPv6 alloué par ton FAI, par exemple moi j'ai autorisé 3 réseaux différents, avec un même préfixe en /56 (fourni par le FAI), mon pare-feu crée ensuite des pools /64 depuis ce /56, et j'autorise ceux qui m'intéressent dans le NAS

parefeu_ipv6.png

Personnellement, je n'ai eu aucun problème à accéder à mon NAS en utilisant le blocage GeoIP en IPv6, visiblement ils importent également les adresses IPv6.
Avec tous ces points, tu devrais pouvoir accéder à ton NAS en IPv6 sans problème depuis l'extérieur. Sous réserve de ce que la box permet comme configuration au niveau du pare-feu IPv6 (mais j'ai ouïe dire que la Freebox est relativement configurable par rapport aux box concurrentes).

Lien vers le commentaire
Partager sur d’autres sites

Donc ceci explique pourquoi la connexion en IPv6 au NAS n'est pas possible depuis l'extérieur.

il y a une heure, CoolRaoul a dit :

Ce n'est pas évident de déterminer quelles sont ces "IPV6 necessaires", quel critère appliquer ?

Ça dépend de la façon dont tu utilises ton NAS à l'extérieur. Étant également chez Free et n'utilisant que mon téléphone depuis l'extérieur, je n'ai autorisé que les plages IP de l'opérateur :

  • 37.160/12 pour Free mobile en IPv4,
  • 2a01:e00::/26 pour toutes les adresses IPv6 Free.

Je n'ai pas activé la règle IPv6 pour le moment car je n'ai pas activé IPv6 sur mon abonnement mobile. Il faudra d'ailleurs que j'identifie plus précisément l'espace IPv6 attribué à Free mobile pour restreindre au mieux la surface d'exposition.

On trouve les réseaux attribués ici : https://ftp.ripe.net/pub/stats/ripencc/membership/alloclist.txt (fr.proxad pour Free)

Il y a 2 heures, MilesTEG1 a dit :

Je ne suis pas sûr que désactiver le parefeu IPv6 de la freebox soit une bonne idée...

C'est une mauvaise idée si on n'en maîtrise pas les conséquences. l'abscence d'un pare-feu IPv6 paramétrable est l'un des plus grand reproche fait aux box de Free, surtout qu'un tel pare-feu existe depuis longtemps chez certains concurrents (Orange et SFR notamment).

il y a une heure, CoolRaoul a dit :

L'ennui est qu'il n'y a pas de pare-feu sur la mienne, juste un switch tout ou rien.

Justement c'en est un, mais la seule action possible est d'autoriser ou d'interdire tout le trafic entrant IPv6, c'est qui n'est pas d'une grande utilité quand on héberge des services chez soi.

Je ne vais pas faire un exposé sur IPv6 ici. Ce qu'il faut retenir c'est que par défaut un pare-feu IPv6 est présent sur n'importe quel appareil compatible IPv6 (que ce pare-feu soit paramétrable ou non), et qu'il doit bloquer tout le trafic entrant depuis l'espace publique (2000::/3). C'est précisément là que le niveau de confiance tombe à quelque chose proche de zéro chez les plus sceptiques (dont je fais parti).

Concernant les appareils sur lesquels j'ai des doutes, j'ai simplement désactivé IPv6 dessus.

Après il faut relativiser, les scans de ports tels qu'on les connaît en IPv4 sont inexistants en IPv6 (en tout cas, tcpdump ne m'en a remonté aucun depuis 2 mois sur un NAS exposé).

@.Shad. Ton NAS a déjà bloqué des tentatives de connexions sur IPv6 ?

 

Lien vers le commentaire
Partager sur d’autres sites

@PiwiLAbruti Mon pfSense en amont s'occupe déjà de tout le filtrage IPv6, donc n'arrive au NAS que le trafic que j'autorise (requêtes ICMP et clients seedbox), donc jamais remarqué de blocage.
Cela dit je peux faire le test, je supprime le filtrage de pfSense, je rajoute une règle qui bannit l'espace publique 2000::/3 après mes règles d'autorisation sur mon préfixe personnel, et vérifier sur un temps donné. Je vais essayer de regarder ça cette semaine. Ce sera assez facile à vérifier avec la seedbox.

Lien vers le commentaire
Partager sur d’autres sites

Rejoindre la conversation

Vous pouvez publier maintenant et vous inscrire plus tard. Si vous avez un compte, connectez-vous maintenant pour publier avec votre compte.

Invité
Répondre à ce sujet…

×   Collé en tant que texte enrichi.   Coller en tant que texte brut à la place

  Seulement 75 émoticônes maximum sont autorisées.

×   Votre lien a été automatiquement intégré.   Afficher plutôt comme un lien

×   Votre contenu précédent a été rétabli.   Vider l’éditeur

×   Vous ne pouvez pas directement coller des images. Envoyez-les depuis votre ordinateur ou insérez-les depuis une URL.

×
×
  • Créer...

Information importante

Nous avons placé des cookies sur votre appareil pour aider à améliorer ce site. Vous pouvez choisir d’ajuster vos paramètres de cookie, sinon nous supposerons que vous êtes d’accord pour continuer.