Serveur OpenMediaVault | Problème accès FTP

Support Debian
#1

Bonjour,
je suis étudiant, et pendant un mois je travaille actuellement en CDD dans une entreprise, j’ai eu pour projet de mettre en place un Serveur de virtualisation (Proxmox) qui me permet d’héberger un Serveur GLPI avec le plugin FusionInventory pour faire un inventaire du parc, ainsi qu’un serveur OpenMediavault pour mettre en place un partage style SAMBA dans le bâtiment ou je me trouve, avec un accès FTP pour y sauvegarder certains services externes.
Pour le moment aucun problème, l’installation de mon Serveur de virtualisation fonctionne à merveille, avec ma machine virtuelle qui fait tourner GLPI avec le plugin FusionInventory, et une autre machine virtuelle qui fait tourner OpenMediaVault, le hic arrive à ce moment-là, mon accès FTP fonctionne en local (sur le même réseau IP que le serveur), mais lorsque je suis dans un service externe (avec l’IP publique) il m’est impossible de mec connecter à ce serveur j’obtiens ce message :

Puis je suis déconnecté par temps de connexion trop élevé (j’utilise du SFTP, avec le port 990).
Je ne sais pas quoi faire, j’y ai bien créé des utilisateurs, avec des dossiers partagés, des droits, etc…

Merci d’avance pour vos retours.

#2

Y a-t-il du NAT (redirection de ports…) au milieu ?
Le protocole FTP a besoin d’une prise en charge spécifique pour traverser ce genre de dispositif.

#3

J’ai bien ouvert les ports 990 en intérieur et extérieur sur ma box en TCP redirigeant vers l’adresse IP de mon serveur FTP.
Je pense d’ailleurs que je n’aurai pas pu aller aussi loin dans la connexion (avec l’adresse IP Publique, sur un réseau distant) sans ce port ouvert.
Mais cela bloque à un moment, alors que lorsque j’utilise l’adresse IP locale quand je suis sur le même réseau, aucun soucis.

#4

Le port 990, c’est pour du FTPS (FTP sécurisé avec chiffrement SSL implicite) ?
Donc l’assistance automatique du NAT, qui ne fonctionne qu’avec le FTP en clair, est inopérante.

En mode passif standard (PASV), le serveur envoie son adresse IP et un port passif au client pour que ce dernier établisse une connexion de données à cette adresse et ce port. Mais l’adresse IP privée envoyée par le serveur est injoignable par un client extérieur. Quand la connexion de commande est chiffrée, le dispositif NAT ne peut pas modifier l’adresse à la vole. Pour la même raison il ne peut pas non plus rediriger automatiquement le port passif spécifié.

Le problème de la redirection des ports passifs peut être contourné en redirigeant toute la plage de ports passifs définis sur le serveur vers l’adresse IP privée du serveur, comme le port 990.

Le problème de l’adresse IP passive injoignable peut être contourné si le client FTP l’ignore (ce qui semble être le cas ici) ou en configurant le serveur pour qu’il envoie l’adresse IP publique visible du client au lieu de son adresse IP privée, ou en utilisant le mode FTP passif étendu (EPSV) qui ne transmet pas l’adresse passive, mais il faut que le client le supporte.

Si tu envisages d’utiliser le mode FTP actif à la place du mode passif, tu risques de rencontrer les mêmes problèmes mais côté client s’il est derrière un NAT ou un pare-feu à état. A mon avis il vaut mieux regrouper et traiter les problèmes potentiels côté serveur.

#5

J’ai ouvert une plage d’adresses de ports passifs et ça fonctionne !

#6

Comme prévu, tant qu’on utilise un logiciel client FTP qui corrige l’adresse passive reçue ou utilise le mode passif étendu.