TCP/IP / Fonctionnement des réseaux => Discussion démarrée par: corrector le 03 juin 2011 à 15:58:01 TCP/IP / Fonctionnement des réseaux => Discussion démarrée par: corrector le 03 juin 2011 à 15:58:01Quelles 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.
Commande : TYPE IFileZilla a envoyé l'adresse du PC 192.168.1.11 et le serveur a réussi à se connecter à cette adresse.
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.
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).
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.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 :
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).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.
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 (http://lxr.linux.no/#linux+v2.6.39/net/netfilter/nf_conntrack_helper.c#L184).
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 (http://lxr.linux.no/#linux+v2.6.39/net/netfilter/nf_conntrack_proto_tcp.c#L73).
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".La fonction nf_nat_mangle_tcp_packet (http://lxr.linux.no/#linux+v2.6.39/include/net/netfilter/nf_nat_helper.h#L18) est utilisée pour remplacer une partie d'un paquet.
Le plus souvent u = x et y = v (préservation des ports par défaut sous linux), mais si le n-upletCela a aussi lieu dans nf_nat_ftp (http://lxr.linux.no/#linux+v2.6.39/net/ipv4/netfilter/nf_nat_ftp.c#L103).(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.L'ajustement des numéros de séquence a lieu dans nf_nat_seq_adjust (http://lxr.linux.no/#linux+v2.6.39/net/ipv4/netfilter/nf_nat_helper.c#L381); les numéros d'une éventuelle option SACK sont ajustés aussi.
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.Est-ce encore nécessaire?
Se connecter en SSH sur un serveur et laisser la nuit. Vérifier qu'on est toujours connecté en SSH le lendemain matin.Un Netgear CBVG834G tient 5 petites minutes à ce régime, même sans P2P. Aucune pitié pour les connexions idle. Il faut mettre un keepalive à 295 secondes pour qu'une session SSH tienne sur la durée. Par contre dans ces conditions, le P2P ne semble pas gêner.
Certaines box effacent les n-uplets d'une connexion TCP encore active quand on fait du P2P.Pour chipoter, c'est une table pas un buffer.
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.Pas très scientifique... quelqu'un a essayé de mesurer le nombre de connexions simultanées maximum?
Fonctionnement des Accélérateurs:Quels matériels supportent cette optimisation?
Lorsque l'utilisateur lance un téléchargement TCP/UDP, les premiers paquets qui sont responsables de l'établissement de la connexion passent par le CPU(chemin classique :NAT/FIREWALL/policies...), une fois le lien est établie tous les prochains paquets passeront par les accélérateurs (chemin rapide). Les accélérateurs n'analyse que l'entête TCP/IP du paquet et pas son contenue.
A noter que le même phénomène est utilisé sur le port 21 pour le FTP.Donc on pourrait savoir avec un test black-box sur quels ports les protocoles spécifiques sont gérés?
Note : Les box équipées de Watchdog reboot lors d'un transfert HTTP à 20 Mb/s ou plus, le CPU étant utilisé à 100%, le watchdog est là pour rétablir la situation via un rebootUn watchdog, c'est pas pour détecter que le système est gelé?
Un watchdog, c'est pas pour détecter que le système est gelé?C'est ça, si le système ne répond plus il reboot la box. En téléchargeant au débit max, le CPU est à 100% et ne répond plus au watchdog qui reboot la box. J'ai fait une démo à Sagem, avec une box citéFibre (https://lafibre.info/site/citefibre/index.htm) en téléchargeant simplement un gros fichier sur 01net.
Chaque fournisseur est obligé d'avoir des systèmes pour accélérer le traitement car un vrai routeur qui traite 100 Mb/s, cela coûte beaucoup plus cher qu'une box.Avant on utilisait un vieux PC 486 en guise de routeur.
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".Après quelques expérimentations sur la gestion du FTP client derrière une Freebox v5 en mode routeur, il s'avère que :
Après quelques expérimentations sur la gestion du FTP client derrière une Freebox v5 en mode routeur, il s'avère que :Étrangement ;) la lecture du code source de linux coïncide avec les observations expérimentales.
la Freebox laisse passer tel quel tout segment TCP du client vers le serveur FTP,C'est dans la fonction help dans nf_conntrack_ftp.c (http://lxr.linux.no/#linux+v2.6.39/net/netfilter/nf_conntrack_ftp.c#L369) :
sauf si les données TCP commencent une suite de lettres qui est un préfixe de "PORT" ou de "EPTR" (insensible à la casse)
à l'exception de la toute première commande FTP, qui elle passe toujours directement.
369 /* Until there's been traffic both ways, don't look in packets. */
370 if (ctinfo != IP_CT_ESTABLISHED &&
371 ctinfo != IP_CT_ESTABLISHED + IP_CT_IS_REPLY) {
372 pr_debug("ftp: Conntrackinfo = %u\n", ctinfo);
373 return NF_ACCEPT;
374 }Concernant les segment TCP envoyé par le PC derrière la Freebox contenant juste "p", "po", "por", "port", "e", "ep", "epr", "eprt" : ces segments ne sont pas transmis par la Freebox. En fait la Freebox attend d'avoir une commande PORT ou EPRT complète avant de la transmettre.Les séquences reconnues sont définies par le tableau search (http://lxr.linux.no/#linux+v2.6.39/net/netfilter/nf_conntrack_ftp.c#L68) qui associe à chaque direction (client->serveur, serveur->client) un tableau de "motifs" de la forme : (texte, fonction de décodage)
254/* Return 1 for match, 0 for accept, -1 for partial. */
255 static int find_pattern(const char *data, size_t dlen,
256 const char *pattern, size_t plen,
257 char skip, char term,
258 unsigned int *numoff,
259 unsigned int *numlen,
260 struct nf_conntrack_man *cmd,
261 int (*getnum)(const char *, size_t,
262 struct nf_conntrack_man *, char))
La Freebox perd ces données incomplètes, ce qui provoque une retransmission TCP.C'est toujours dans la fonction help (http://lxr.linux.no/#linux+v2.6.39/net/netfilter/nf_conntrack_ftp.c#L425) :
425 if (found == -1) {
426 /* We don't usually drop packets. After all, this is
427 connection tracking, not packet filtering.
428 However, it is necessary for accurate tracking in
429 this case. */
430 pr_debug("conntrack_ftp: partial %s %u+%u\n",
431 search[dir][i].pattern, ntohl(th->seq), datalen);
432 ret = NF_DROP;
433 goto out;
En entrant une commande PORT ou EPRT mal-formée avec telnet, on peut mettre en vrac l'entrée NAT, qui ne transmet plus rien, jusqu'à ce que le client abandonne (RST du client).Si une commande mal-formée correspondant à un motif a été envoyée par le client, find_pattern va systématiquement renvoyer -1, et le paquet sera systématiquement DROPé.
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".C'est expliqué dans la RFC 3022 - Traditional IP Network Address Translator (Traditional NAT) (http://tools.ietf.org/html/rfc3022) :
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.
4.4. FTP support (http://tools.ietf.org/html/rfc3022#section-4.4)(Mais ça ne parle pas de SACK; si on oublie de gérer les SACK, ça doit être comique.)
One of the most popular applications, "FTP" ([FTP]) would require an
ALG to monitor the control session payload to determine the ensuing
data session parameters. FTP ALG is an integral part of most NAT
implementations.
The FTP ALG would require a special table to correct the TCP sequence
and acknowledge numbers with source port FTP or destination port FTP.
The table entries should have source address, destination address,
source port, destination port, delta for sequence numbers and a
timestamp. New entries are created only when FTP PORT commands or
PASV responses are seen. The sequence number delta may be increased
or decreased for every FTP PORT command or PASV response. Sequence
numbers are incremented on the outbound and acknowledge numbers are
decremented on the inbound by this delta.
Quelles type de protocoles client veux-tu quels supportent?Sauf si le protocole spécifie que le client doit envoyer au serveur une commande "p" ou "e" et attendre la réponse.
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).
Quelles type de protocoles client veux-tu quels supportent?Ceux-là par exemple :
Sauf si le protocole spécifie que le client doit envoyer au serveur une commande "p" ou "e" et attendre la réponse.On vérifie facilement que cela n'est pas le cas en IPv6 avec la Freebox v5 : en se connectant sur le port FTP en IPv6 à un serveur quelconque (p.ex. ftp.free.fr) :
Quels protocoles applicatifs sont gérés par les NAT-box?Sur la Freebox ADSL (http://floss.freebox.fr/freebox_adsl/1.5.12/linux/linux-2.6.20.14-fbx.patch) :
+CONFIG_NF_CONNTRACK_ENABLED=y
+# CONFIG_NF_CONNTRACK_SUPPORT is not set
+CONFIG_IP_NF_CONNTRACK_SUPPORT=y
+CONFIG_IP_NF_CONNTRACK=y
+# CONFIG_IP_NF_CT_PROTO_SCTP is not set
+CONFIG_IP_NF_FTP=m
+CONFIG_IP_NF_IRC=m
+# CONFIG_IP_NF_NETBIOS_NS is not set
+CONFIG_IP_NF_TFTP=m
+# CONFIG_IP_NF_AMANDA is not set
+CONFIG_IP_NF_PPTP=m
+# CONFIG_IP_NF_H323 is not set
+# CONFIG_IP_NF_SIP is not set
+CONFIG_IP_NF_NAT_FTP=m
+CONFIG_IP_NF_NAT_IRC=m
+CONFIG_IP_NF_NAT_TFTP=m
+CONFIG_IP_NF_NAT_PPTP=m
Les modules FTP, IRC, TFTP et PPTP sont en dynamique (pourquoi dynamique?).+# CONFIG_NF_CT_PROTO_DCCP is not set
+CONFIG_NF_CT_PROTO_GRE=m
+# CONFIG_NF_CT_PROTO_SCTP is not set
+# CONFIG_NF_CT_PROTO_UDPLITE is not set
+# CONFIG_NF_CONNTRACK_AMANDA is not set
+CONFIG_NF_CONNTRACK_FTP=y
+CONFIG_NF_CONNTRACK_H323=m
+CONFIG_NF_CONNTRACK_IRC=m
+# CONFIG_NF_CONNTRACK_NETBIOS_NS is not set
+# CONFIG_NF_CONNTRACK_SNMP is not set
+CONFIG_NF_CONNTRACK_PPTP=m
+# CONFIG_NF_CONNTRACK_SANE is not set
+CONFIG_NF_CONNTRACK_SIP=m
+CONFIG_NF_CONNTRACK_TFTP=y
+CONFIG_IP_NF_NAT_FTP=m
+CONFIG_IP_NF_NAT_IRC=m
+CONFIG_IP_NF_NAT_TFTP=m
+CONFIG_IP_NF_NAT_PPTP=m
Les modules conntrack FTP, TFTP sont compilés en statique, et les modules conntrack H323, SIP, IRC, et PPTP sont en dynamique (pourquoi dynamique?).Fonctionnement des Accélérateurs:
Lorsque l'utilisateur lance un téléchargement TCP/UDP, les premiers paquets qui sont responsables de l'établissement de la connexion passent par le CPU(chemin classique :NAT/FIREWALL/policies...), une fois le lien est établie tous les prochains paquets passeront par les accélérateurs (chemin rapide). Les accélérateurs n'analyse que l'entête TCP/IP du paquet et pas son contenue.
La problématique pour les opérateurs comme K-Net qui souhaitent customiser le firmware de leur box est de trouver une box avec un firmware alternatif qui gère l'accélération matériel, sans quoi les débits sont limités.