Ce matin, avec mon Galaxy s7 équipé de Android 7.0 et un abonnement Bouygues Telecom, j'ai une limitaiotn à 5 secondes. Je ne sais pas si c'est lié au téléphone qui réalise une double NAT et que je viens d'upgrader sous Android 7.0 ou si c'est lié à une modification du NAT sur le réseau Bouygues Telecom.


Voici une capture réalisé coté client et le paramètre ClientAliveInterval 14:

La connexion se termine à la 5ème seconde. Je laisse ensuite le terminal 9 secondes sans rien faire. A la 14ème seconde, on voit un échange TCP qui est rejeté par le NAT, qui a donc déjà libéré les ressources : il répond RESET.

C'est la même choses pour les deux paquets émis à la 19ème seconde :


Voici la capture Wireshark complète, avec ClientAliveInterval 14:
201706_ssh_cgnat_clientaliveinterval_14sec.pcapng.gz

Voici la capture Wireshark complète, avec ClientAliveInterval 4:
201706_ssh_cgnat_clientaliveinterval_4sec.pcapng.gz
Je ne fais rien, mais la communication est forcé de rester ouverte par des échanges toutes les 4 secondes

Note : Il est possible de lire les fichiers .pcapng.gz directement avec Wireshark.

Salut,

Aujourd'hui, avec un ami, on a découvert un autre problème bloquant du réseau mobile bouygues telecom.

Le FTPS ne passe pas, le FTP over TLS, même en mode explicite (même ports que le FTP simple).

Serveur FTP(S) chez moi, ligne Orange fixe.
Mon ami a une ligne bouygues telecom mobile via hostpot 4G, et une ligne fixe chez Free.

FTP simple, Ok quelque soit sa ligne.
FTPS, d'abord avec BT 4G: même pas une demande de certificat TLS, échec de connexion par time out.
FTPS par Free fixe: tout fonctionne. Je lui fais accepter le certificat TLS de façon permanente pour réessayer avec BT 4G. Il se déconnecte du FTP avant de continuer les tests.
Il retourne sur BT 4G: même pas d'authentification au compte FTP, comme si le certificat TLS ne passe pas, échec de connexion par time out.

Si c'était du SFTP, je dirai même problème que le SSH, mais le problème est peut être un peu différent sur FTPS. HTTPS ok.

de manière générale FTPS est assez mal supporté par les équipements réseaux.
je ne compte plus les fois ou j'ai du désactiver les systèmes type ALG sur juniper (genre de firewall intelligent qui est sensé ouvrir les ports nécessaire et éviter des attaques)
il est possible que Bytel ai mis en place une "protection" sur le protocole FTP qui ne gère pas du tout FTPS...

après il faudrait une capture tcpdump/wireshark pour vérifier ce qui pas ou pas sur le serveurs et le client

Je ne connais pas bien FTPS, mais FTP est déjà extrêmement complexe pour passer derrière un NAT, vu que le NAT dois modifier les IP annoncée dans les paquets de données.

Il y a un gros bout de code spécifique FTP dans les NAT.

En 4G, avec un CG-Nat, on est en plus limité par une toute petite plage de port utilisable par client.

Le serveur a besoin de connaître l'IP publique car en mode passif, l'IP de connexion est transmise par le serveur au client sur le port 21 et cette IP peut être différente de celle sur le port 21, par exemple pour répartir la charge sur plusieurs serveurs.


FTP peut s'utiliser de deux façons différentes :

Mode Actif :


En mode actif, c'est le client FTP qui détermine le port de connexion à utiliser pour permettre le transfert des données. Ainsi, pour que l'échange des données puisse se faire, le serveur FTP initialisera la connexion de son port de données (port 20) vers le port spécifié par le client. Le client devra alors configurer son pare-feu pour autoriser les nouvelles connexions entrantes afin que l'échange des données se fasse. De plus, il peut s'avérer problématique pour les utilisateurs essayant d'accéder à des serveurs FTP lorsque ces utilisateurs sont derrière une passerelle NAT. Étant donnée la façon dont fonctionne le NAT, le serveur FTP lance la connexion de données en se connectant à l'adresse externe de la passerelle NAT sur le port choisi. Certaines passerelles NAT n'ayant pas de correspondance pour le paquet reçu dans la table d'état, le paquet sera ignoré et ne sera pas délivré au client.


Mode passif :


En mode passif, le serveur FTP détermine lui-même le port de connexion à utiliser pour permettre le transfert des données (data connexion) et le communique au client. En cas de présence d'un pare-feu devant le serveur, celui-ci devra être configuré pour autoriser la connexion de données. L'avantage de ce mode est que le serveur FTP n'initialise aucune connexion. Ce mode fonctionne sans problème avec des clients derrière une passerelle NAT. Dans les nouvelles implèmentations, le client initialise et communique directement par le port 21 du serveur ; cela permet de simplifier les configurations des pare-feu serveur.

Source : Wikipedia

FTP est un protocole ancien qu'il faut essayer de remplacer.
Si tu ne proposes que des fichier à télécharger, http est préférable (Apache ou WampServer par exemple).

SFTP est supporté par filezilla (sur mac c'est sur et sur windows je pense aussi)
passe par le gestionnaire de sites pour configurer une nouvelle connexion

J'ai bien spécifié filezilla server.
Je sais pour le client, mais cela ne sert à rien si le serveur n'a pas le SFTP.^^

Ceci dit, je ne sais pas si on peut suivre le tuto avec Filezilla client.
Le seul paramètre pour ne pas se faire déco est: "Envoyer des commandes FTP anti-déconnexion".
Rien pour paramétrer un intervalle, ou un nombre maxi avant retour. Et je ne sais pas ce qui est en dur dans le code.