Auteur Sujet: NAT-box : quels protocoles applicatifs?  (Lu 18008 fois)

0 Membres et 1 Invité sur ce sujet

corrector

  • Invité
NAT-box : quels protocoles applicatifs?
« le: 03 juin 2011 à 15:58:01 »
Quels protocoles applicatifs sont gérés par les NAT-box?

Je pense que toutes gèrent FTP en client, mais quoi d'autre?

Quelqu'un a fait des tests?

ruchard5

  • Expert
  • Abonné Free adsl
  • *
  • Messages: 116
    • Le blog du Ruchard
NAT-box : quels protocoles applicatifs?
« Réponse #1 le: 04 juin 2011 à 11:25:50 »
Quelles type de protocoles client veux-tu quels supportent?

De manière générique tcp / udp ne s’inquiète pas du client ni de la charge transporter. Ainsi le port 21, ftp par default peut etre utiliser pour faire transiter du trafic http, smb ou tout autre protocole d'application (que le client consomme, ou initie).

Je joins une copie d’écran d'un test rapide sur mon router NAT/Firewall netgear (depuis la DMZ vers mon serveur interne), qui atteint les 98,5 Mbps. A noter que le debit de 98,5 Mbps ete soutenu jusqu’à ce que j’arrête le stream, puis pour une raison indéterminé il est reste a ~67Mbps avant de remonte a presque 100Mbps.


vivien

  • Administrateur
  • *
  • Messages: 47 076
    • Twitter LaFibre.info
NAT-box : quels protocoles applicatifs?
« Réponse #2 le: 04 juin 2011 à 11:53:17 »
Pour le FTP, en mode passif il est nécessaire que la Box "écoute" les données au dessus de la couche 4 afin d'ouvrir le port demandé pour le transfert de donnée en mode passif.

Sans cette écoute et compréhension du protocole FTP, le port demandé restera fermé...

De même Sagem "écoutait" MSN sur son port et le port de rempli (80) pour ouvrir le port demandé pour une conversation vidéo.

Le problème c'est que cette "écoute" forçait les paquets a passer par le CPU et non par les accélérateurs => Trafic limité à 20 Mb/s sur les ports concernés. Pour le port 80 c'était vraiment dommage.

corrector

  • Invité
NAT-box : FTP
« Réponse #3 le: 04 juin 2011 à 14:55:04 »
Quelles type de protocoles client veux-tu quels supportent?
Tous, y compris ceux qui n'ont pas encore été inventés.

De manière générique tcp / udp ne s’inquiète pas du client ni de la charge transporter. Ainsi le port 21, ftp par default peut etre utiliser pour faire transiter du trafic http, smb ou tout autre protocole d'application (que le client consomme, ou initie).
UDP et TCP non, la Freebox si.

Extrait d'un log de connexion vers un serveur FTP chez Free :
Citer
Commande :   TYPE I
Réponse :   200 Type set to I
Commande :   PORT 192,168,1,11,196,17
Réponse :   200 PORT command successful
Commande :   LIST
Réponse :   150 Opening ASCII mode data connection for file list
Réponse :   226 Transfer complete.
FileZilla a envoyé l'adresse du PC 192.168.1.11 et le serveur a réussi à se connecter à cette adresse.

Alors, bluffé?

corrector

  • Invité
NAT-box : FTP
« Réponse #4 le: 04 juin 2011 à 15:17:00 »
Pour le FTP, en mode passif il est nécessaire que la Box "écoute" les données au dessus de la couche 4 afin d'ouvrir le port demandé pour le transfert de donnée en mode passif.
Non seulement : la box qui écoute c'est la version "soft". C'est ce que ferait une box IPv6 avec pare-feu à états : il suffit d'écouter et d'accepter la nouvelle connexion (création d'un n-uplet).

Si ce n'était que de l'écoute, ce serait simple. C'est beaucoup plus difficile parce qu'il faut corriger l'adresse de socket (IP et port) : il faut changer "PORT 192,168,a,b,x,y" en "PORT mon.adresse.Internet,u,v".

Le plus souvent u = x et y = v (préservation des ports par défaut sous linux), mais si le n-uplet
(IPv4, TCP, mon.adresse.Internet, x*256+y, adresse.du.serveur.FTP, 21)
existe déjà, il faut en choisir u,v tq
(IPv4, TCP, mon.adresse.Internet, u*256+v, adresse.du.serveur.FTP, 21)
n'existe pas dans la table des connexions.

En plus comme c'est de l'ASCII et non du binaire, "PORT mon.adresse.Internet,u,v" peut être plus long que "PORT 192,168,a,b,x,y" et donc il faut corriger les numéros de séquence sur les segments suivants envoyés et donc il faut corriger les numéros ACK sur les segments reçus suivants.

Bien sûr, cela veut dire que les segments doivent être traités dans l'ordre même s'ils arrivent dans le désordre.

Cela correspond grosso modo à faire passer la connexion FTP par toute la pile TCP deux fois dans la box.

Par défaut, linux n'espionne que le port 21 à la recherche de commandes FTP, mais on peut donner une liste de ports dans la ligne de commande.

corrector

  • Invité
NAT-box : tester le FTP
« Réponse #5 le: 04 juin 2011 à 15:53:29 »
Pour tester si votre NAT-box gère le FTP client, c'est très simple; il vous faut :
  • FileZilla Client : client FTP libre (GPL), pratique, rapide, léger, et finement paramétrable
  • choisir un serveur FTP quelconque sur le net v4
Dans FileZilla:
allez dans "Édition > Paramètres...";
allez sur la page "Connexion > FTP";
dans "Mode de transfert" choisissez Actif et décochez "Autorisez un retour (...)";
validez.

Vous pouvez vous connecter en entrant un nom de serveur (et identifiant s'il ne s'agit pas d'un FTP anonyme) dans la barre de connexion rapide. (Pour enregistrer un serveur pour y revenir plus tard, allez plutôt dans "Fichier > Gestionnaire de Sites...")

Si la connexion à un serveur se passe bien et que vous voyez bien le listing du serveur dans le volet de droite, c'est que votre NAT-box gère le FTP.

Si possible, merci de copier ici un extrait du log de connexion (commande PORT et LIST).

Après le test, revenez quand même à la configuration par défaut : mode "Passif (recommandé)".

ruchard5

  • Expert
  • Abonné Free adsl
  • *
  • Messages: 116
    • Le blog du Ruchard
NAT-box : FTP
« Réponse #6 le: 04 juin 2011 à 17:42:52 »
UDP et TCP non, la Freebox si.

Bon, peut être pour la freebox mais elle te permet quand même de passer outre ses limitations.

Moi j'utilise l'option DMZ, ou tout le trafic entrant est router vers une adresse unique (le 192.168.0.253 de mon test précédent). Qui est mon router Netgear.

A partir de cela j'ai tout le contrôle nécessaire pour fournir des service http, web, git, ssh, rdp et autre. Et pas l'ombre d'une limitation freebox ici (puisque l'option DMZ rends le routage au niveau de la freebox on ne peux plus simple).

Bon, ça c'est pour la théorie. Dans la pratique je peux difficilement tester avec mon petit 1Mbps de bandes passante up... que ne donnerais pour un jolie 10Mbps symétrique (je demande pas 20, 50 ou 100 ~ juste 10Meg...).

corrector

  • Invité
NAT-box : problème des protocoles à plusieurs connexions
« Réponse #7 le: 04 juin 2011 à 18:46:17 »
Bon, peut être pour la freebox mais elle te permet quand même de passer outre ses limitations.

Moi j'utilise l'option DMZ, ou tout le trafic entrant est router vers une adresse unique (le 192.168.0.253 de mon test précédent). Qui est mon router Netgear.
J'ai configuré une DMZ sur ma Freebox avec une IP locale que je n'utilise habituellement sur aucun PC (192.168.1.30), comme ça :
  • habituellement, les captures de paquets ne sont pas polluées par les zozos (souvent chez Free) qui viennent continuellement frapper à la porte;
  • je peux tester un serveur sans avoir à redémarrer la Freebox, juste en configurant l'adresse 192.168.1.30 sur le PC serveur.
Mais la DMZ ne résout pas le problème du client FTP en mode passif, ni plus généralement celui d'un logiciel qui envoie l'adresse IP du PC.

A partir de cela j'ai tout le contrôle nécessaire pour fournir des service http, web, git, ssh, rdp et autre. Et pas l'ombre d'une limitation freebox ici (puisque l'option DMZ rends le routage au niveau de la freebox on ne peux plus simple).
http, ssh sont des protocoles "simples" qui n'échangent pas d'adresses de socket (port ou adresse IP), et ne nécessitent donc aucun traitement particulier de la part de la NAT-box. Je ne connais pas très bien Remote Desktop Protocol, ni le protocole GIT, mais je pense que c'est aussi le cas.

Le problème concerne les protocoles qui utilisent plusieurs connexions :
  • une connexion "de contrôle" pour l'identification, échanger des paramètres, notamment la méthode de transport des données et l'adresse à laquelle se connecter pour établir la connexion "de données"
  • une connexion "de données" pour transporter les données elles-mêmes
L'adresse de la connexion "de données" indiquée dans la une connexion "de contrôle" peut être une adresse complète (IP, protocole, port), ou bien seulement certaines informations :
  • l'adresse IP peut être fixée comme étant celle d'un des participants;
  • le protocole peut être fixé (en FTP il est par définition TCP);
  • plus vicieux : le port peut-être fixé comme étant (port utilisé pour la connexion de contrôle - 1) ou + 1
Si l'adresse IP n'est pas transmise et est fixée comme étant celle d'un des participants, alors effectivement la DMZ peut aider.

Si le port est calculé en fonction d'un port utilisé par le client, alors le caractère port-preserving par défaut de la Freebox et la DMZ peuvent aider.

vivien

  • Administrateur
  • *
  • Messages: 47 076
    • Twitter LaFibre.info
NAT-box : quels protocoles applicatifs?
« Réponse #8 le: 04 juin 2011 à 21:18:45 »
Pour http ou ssh il faut quand même modifier l'adresse IP et le port (dans les en-têtes du protocole et non dans la partie donnée comme c'est le cas pour le FTP).

La box doit aussi mémoriser quel port va vers quel ip du réseau local. Après un certain délai, c'est effacé et là si la connexion est toujours ouverte c'est catastrophique car les paquets suivant se voient affecté un nouveau port. Le serveur va faire des reset car il n'attend rien sur ces ports...

corrector

  • Invité
NAT-box : quels protocoles applicatifs?
« Réponse #9 le: 04 juin 2011 à 21:57:05 »
Pour http ou ssh il faut quand même modifier l'adresse IP et le port (dans les en-têtes du protocole et non dans la partie donnée comme c'est le cas pour le FTP).
Bien sûr, il y a la correction habituelle d'adresse de socket. Je veux dire que pour HTTP et SSH aucun protocole n'est enregistré avec nf_conntrack_helper_register.

Le code pour le seul suivi des états TCP dans linux (sans NAT) fait 1500 lignes.

La box doit aussi mémoriser quel port va vers quel ip du réseau local. Après un certain délai, c'est effacé et là si la connexion est toujours ouverte c'est catastrophique car les paquets suivant se voient affecté un nouveau port. Le serveur va faire des reset car il n'attend rien sur ces ports...
Le timeout pour une connexion TCP est de 5 jours sous linux.

Mais je ne comprends pas pourquoi la box effacerait les n-uplets d'une connexion TCP, alors qu'elle pourrait se contenter d'envoyer un segment vide (comme un keepalive) dans chaque direction pour voir si les deux sockets existent toujours. Associé à un timeout plus court que 5 jours, cela permettrait de nettoyer plus vite la table des n-uplets sans risque.

vivien

  • Administrateur
  • *
  • Messages: 47 076
    • Twitter LaFibre.info
NAT-box : quels protocoles applicatifs?
« Réponse #10 le: 04 juin 2011 à 22:18:38 »
Certaines box effacent les n-uplets d'une connexion TCP encore active quand on fait du P2P.

Je suppose donc que certaines box on un buffer trop petit et le P2P qui ouvre beaucoup de connexions en // (qui changent régulièrement) doit saturer le buffer de ces box.

Le P2P, c'est cruel pour de nombreuses NAT-box. Pas besoin de grand chose. Un test simple qui échoue sur de nombreuses box : Un upload a 70 Ko/s de distribution linux (via un client BitTorrent). Se connecter en SSH sur un serveur et laisser la nuit. Vérifier qu'on est toujours connecté en SSH le lendemain matin.

corrector

  • Invité
NAT-box : quels protocoles applicatifs?
« Réponse #11 le: 05 juin 2011 à 00:05:12 »
Si les connexions TCP sont fermées normalement, les n-uplets sont effacés rapidement (1 minute sous linux).

Au démarrage, nf_conntrack_htable_size est initialisé à entre 32 et 16384 selon la RAM; nf_conntrack_max est initialisé à 4 * nf_conntrack_htable_size. (Ces valeurs sont modifiables à tout moment.)

init_conntrack appelle __nf_conntrack_alloc pour créer une nouvelle entrée conntrack; au delà de nf_conntrack_max, init_conntrack appelle early_drop qui efface l'entrée la plus ancienne.