La Fibre
Télécom => Réseau => 
TCP/IP / Fonctionnement des réseaux => Discussion démarrée par: vivien le 22 juin 2017 à 09:25:12
-
Tutoriel pour ne plus être déconnecté en SSH derrière un Carrier-grade NAT
Plusieurs clients se partagent une même IP sur CG-NAT (NAT sur le réseau, effectué sur les connexions mobile ou par certains FAI pour économiser les IPv4 allouées) : une connexion inactive occupe des ressources en terme de ports.
=> Les CG-NAT libérent les ports des connexions inactives aprés un temps qui varie de 5 secondes à plusieurs minutes.
Votre IP privée ne change pas, il est impossible de reprendre la connexion, ce qui casse la connexion SSH.
Pour éviter que le CG-NAT libère les ressources utilisées, il faut forcer un échange régulier de paquet pour laisser la connexion ouverte. De nombreuses applications font ça par défaut, mais pas OpenSSH.
Il est recommandé de mettre ce type de lignes à la fin d'un /etc/ssh/sshd_config sur un serveur :
# Forcer un échange toutes les 4sec pour éviter la déconnexion (NAT) ou changement IP publique (CG-NAT)
ClientAliveInterval 4
ClientAliveCountMax 22
Si vous ne pouvez pas modifier la conf d'OpenSSH coté serveur, vous pouvez le faire coté client, cela marche aussi.
Éditez /etc/ssh/ssh_config (ou si vous souhaitez que la modification ne concerne que vous, créer ~/.ssh/config)
# Forcer un échange toutes les 14sec pour éviter la déconnexion (NAT) ou changement IP publique (CG-NAT)
ServerAliveInterval 4
ServerAliveCountMax 22
Sous Windows, avec le client Putty, c'est dans session properties, Connection et Sending of null packets to keep session active, mettre Seconds between keepalives à 4 (0 pour désactiver)
Pourquoi 4 secondes ?
Car certains CG-NAT ont une limite à 5 secondes et qu'en mettant 5 secondes on se fait quand même déconnecter de temps en temps. Ce problème n'arrive plus avec une configuration à 4 secondes.
-
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 :
(https://lafibre.info/images/wireshark/201706_ssh_cgnat_clientaliveinterval_14sec.png)
Voici la capture Wireshark complète, avec ClientAliveInterval 14:
201706_ssh_cgnat_clientaliveinterval_14sec.pcapng.gz (https://lafibre.info/images/wireshark/201706_ssh_cgnat_clientaliveinterval_14sec.pcapng.gz)
Voici la capture Wireshark complète, avec ClientAliveInterval 4:
201706_ssh_cgnat_clientaliveinterval_4sec.pcapng.gz (https://lafibre.info/images/wireshark/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.
-
A mentionner dans ce genre de contexte, Mosh (https://mosh.org/ (https://mosh.org/)), qui permet d'avoir un shell distant qui supporte plutôt bien les connexions foireuses, ainsi que les changements d'IP du client.
-
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.
-
Je fais trois fois par semaine du SFTP (SSH File Transfert Protocol) sur mon PC connecté à mon Smartphone en partage de connexion, sur une connexion 4G Bouygues Telecom et je n'ai aucun problème (normal vu que SSH fonctionne bien).
Ton FTPS, c'est du FTP avec connexion TLS, c'est ça ? Seul la connexion est chiffrée, contrairement au SFTP qui chiffre l'intégralité des échanges.
-
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
-
Ton FTPS, c'est du FTP avec connexion TLS, c'est ça ? Seul la connexion est chiffrée
Oui, c'est cela. Mais cela suffit pour ne pas passer avec BT mobile.
En SFTP, si je trouve un logiciel server pour Windows 7 (filezilla server fait du FTPS, mais pas de SFTP), je sais qu'il faudra mettre un anti-deco de 4 secondes grace à ce sujet. Mais en FTPS, je doute que cela soit contournable...
-
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 :
(https://lafibre.info/images/tuto/201507_FTP_mode_actif.png)
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 :
(https://lafibre.info/images/tuto/201507_FTP_mode_passif.png)
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 (https://fr.wikipedia.org/wiki/File_Transfer_Protocol)
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).
-
Oui, c'est cela. Mais cela suffit pour ne pas passer avec BT mobile.
En SFTP, si je trouve un logiciel server pour Windows 7 (filezilla server fait du FTPS, mais pas de SFTP), je sais qu'il faudra mettre un anti-deco de 4 secondes grace à ce sujet. Mais en FTPS, je doute que cela soit contournable...
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
-
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.^^
-
arf autant pour moi ^^
j'avais pas les yeux assez ouverts ;D
-
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.
-
Oui, il est possible que le pb vienne de la déconnexion après 5 secondes d'inactivité.
C'est très agressif d'exiger des échanges toutes les 4 secondes.
Avant de préconiser un ClientAliveInterval 4 j'ai réalisé des tests et il y a coupure systématique avec un ClientAliveInterval 6 et c'est aléatoire avec un ClientAliveInterval 5.
Il y a eu un changement il y a quelques semaines coté Bouygues Telecom car depuis plusieurs années, j'étais avec un ClientAliveInterval 14 qui donnait entièrement satisfaction.
-
Il y a eu un changement il y a quelques semaines coté Bouygues Telecom car depuis plusieurs années, j'étais avec un ClientAliveInterval 14 qui donnait entièrement satisfaction.
Car il y a beaucoup plus de connexions nattées à suivre, donc pour offloader les équipements un peu, on réduit le timeout ?
-
Je disais cela pour de l'éventuel SFTP.
Dans mon cas, en FTPS, il n'y a carrèment pas d'échange de certificat TLS... et c'est moins de 5 secondes pour l'obtenir avec un réseau fixe.
Donc le non support du FTPS par le réseau mobile de BT me parait plus pertinent.
Mais maintenant, il faut que je trouve un serveur SFTP pour Windows 7, gratuit, et avec gui. autant dire très difficile à trouver.
Et côté client, un qui permette de configurer un intervalle de keepalive, au cas où que ce ne soit pas possible côté serveur.
Le FTP simple a de beaux jours devant lui.
Et pas envie de payer un certificat TLS pour auto-héberger du HTTPS (et vu ce que je partage, c'est risqué pour mon contrat avec mon hébergeur internet).
-
Car il y a beaucoup plus de connexions nattées à suivre, donc pour offloader les équipements un peu, on réduit le timeout ?
Dit comme cela, c'est le serpent qui se mords la queue.
Cela va finir, un jour, par la fin du SSH &co si c'est trop de gestion côté réseau BT mobile...
-
L'IPv6 va supprimer l'utilisation du CG-NAT...
-
Les hotspots 4G ne sont pas compatibles IPv6... ::)
-
euh? par hotspot tu veux dire quel type d'équipements?
si je ne dis pas bêtises la plupart des nouveaux téléphones portables sont compatibles ipv6 non?
pour le certificat regarde du coté de let's encrypt ça doit se faire
-
euh? par hotspot tu veux dire quel type d'équipements?
si je ne dis pas bêtises la plupart des nouveaux téléphones portables sont compatibles ipv6 non?
Hotspost 4G = https://www.bouyguestelecom.fr/hotspot-tablette par exemple.
Et non, chez Huawei, leur hotsposts ne sont PAS compatibles IPv6. lol
Pour Alcatel-Lucent ou encore Netgear, je ne sais pas, pas recherché l'info. Mais Huawei est le moins cher chez les opérateurs, même en 4G+, donc largement majoritaire chez les clients avec ce type d'équipement...
Pour leurs smartphones (et oui, ils en ont), je ne sais pas, mais je ne suis pas fan de passer par un smartphone pour donner de l'internet mobile à un ordi. C'est vraiment prévu que pour du dépannage.