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

0 Membres et 1 Invité sur ce sujet

corrector

  • Invité
NAT-box : FTP
« Réponse #12 le: 05 juin 2011 à 08:14:03 »
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 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-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.
Cela a aussi lieu dans nf_nat_ftp.

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; les numéros d'une éventuelle option SACK sont ajustés aussi.

corrector

  • Invité
NAT-box : MSN
« Réponse #13 le: 06 juin 2011 à 06:17:29 »
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?

Comment tester le support MSN d'une box?

vivien

  • Administrateur
  • *
  • Messages: 36 015
    • Twitter LaFibre.info
NAT-box : quels protocoles applicatifs?
« Réponse #14 le: 06 juin 2011 à 09:39:07 »
Voici la réponse du chef de projet de CPE FTTH Sagem le 31 juillet 2006 :

Explication des performances non satisfaisantes vues sur un téléchargement HTTP.

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.

Cas d'un transfert de texte par MSN MESSENGER:
Lorsque un client utilise MSN MESSENGER pour chatter se dernier se connecte sur le port 1863/TCP à un serveur de chez Microsoft. dans ce cas le Nat est traversé proprement et le message retour est bien identifié par le Firewall du F@st3374.

Cas d'un transfert de vidéo par MSN MESSENGER :
Les problèmes arrivent lorsque le client demande une connexion vocale/video. Dans ce cas, MSN MESSENGER va demander au serveur de choisir un autre port pour faire passer le flux vidéo. Et le problème c'est que ce port est choisie au hasard entre le port TCP/9000 et TCP/65535. Pour que le flux
vidéo provenant du serveur soit identifier par le firewall du F@st3374 et qu'il soit forwardé correctement, tous les paquets msn( TCP et destPort/srcPort = 1863) passeront par une fonction de traitement supplèmentaire qui permet d'analyser les contenues des paquets en plus de leurs entêtes TCP/IP.
Dans ce cas le flux vidéo passera par les accélérateurs(chemin rapide) mais tous les paquets msn(TCP-port =1863) passeront par le CPU(chemin classique).

Cas du port 80:
Si pour une raison ou pour une autre le MSN MESSENGER n'arrive pas à se connecter au serveur Microsoft sur le port 1863 alors il retombe sur le port 80 en faisant du HTTP tunneling. Affin de supporter ce cas bien particulier le F@st3374 fait passer touts les paquets HTTP(port 80) par le même chemin par lequel passe les paquets msn (port 1863).

Solution immédiate :
Ne supporter que le chat en mode texte dans le cas où le client MSN MESSENGER fait du backup sur le port 80. Et si dans ce cas particulier l'utilisateur veut faire du Chat en mode vidéo il doit installer UPNP sur son poste qui va s'en charger  de communiquer avec le Firewall du F@st3374 pour ouvrir les bons ports.

Je reste à votre disposition pour tout éclaircissement supplèmentaire.

Cordialement.


A noter que le même phénomène est utilisé sur le port 21 pour le FTP.

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 reboot

Mekthoub

  • Expert Numericable
  • Client SFR sur réseau Numericable
  • *
  • Messages: 636
NAT-box : quels protocoles applicatifs?
« Réponse #15 le: 06 juin 2011 à 11:15:53 »
Bonjour!

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.

Tant qu'on y est, ce même CBVG834G effectue le suivi du protocole FTP sur le port TCP 21 entrant (pour héberger un serveur FTP chez soi). Tout bien: Il traduit les adresses LAN/WAN à l'intérieur du flux de commandes, et il accepte automatiquement les connexions data passives préalablement négociées (sans que l'on doive en permanence ouvrir une plage de ports à tout les vents). Mais le bazar est légérement buggé: Ça marche seulement si la chaîne de caractères qui représente l'adresse LAN est de la même longueur que celle de l'adresse WAN. Sinon il se prend les pieds dans le tapis entre taille du paquet, numéro de séquence, ou somme de contrôle, ce qui invalide le paquet, qui sera silencieusement détruit ensuite. Le client ne reçoit plus rien jusqu'au timeout. :'(

corrector

  • Invité
NAT-box : quels protocoles applicatifs?
« Réponse #16 le: 06 juin 2011 à 11:17:46 »
C'est quel OS dans le Netgear CBVG834G ?

Mekthoub

  • Expert Numericable
  • Client SFR sur réseau Numericable
  • *
  • Messages: 636
NAT-box : quels protocoles applicatifs?
« Réponse #17 le: 06 juin 2011 à 12:33:04 »
eCos v2

Mieszko

  • Expert.
  • Client Bbox fibre FTTH
  • *
  • Messages: 239
  • Wambrechies 59
NAT-box : quels protocoles applicatifs?
« Réponse #18 le: 06 juin 2011 à 14:27:46 »
ca serait bien qu'un de ces 4 numericable renouvelle ses modem/routeurs.
avec un switch 1gb dedans par exemple, donner un full access a l'interface etc etc ...
d'ailleurs quelqu'un a les user/password pour un acces complet au netgear CBVG834G ? vu qu'ils les changent a chaque mise a jour de firmware.

corrector

  • Invité
NAT-box : quels protocoles applicatifs?
« Réponse #19 le: 09 juin 2011 à 22:56:51 »
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.
Pour chipoter, c'est une table pas un buffer.

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?

corrector

  • Invité
NAT-box : quels protocoles applicatifs?
« Réponse #20 le: 09 juin 2011 à 23:02:35 »
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.
Quels matériels supportent cette optimisation?

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 reboot
Un watchdog, c'est pas pour détecter que le système est gelé?

vivien

  • Administrateur
  • *
  • Messages: 36 015
    • Twitter LaFibre.info
NAT-box : quels protocoles applicatifs?
« Réponse #21 le: 10 juin 2011 à 07:24:47 »
Là on parle de la méthode utilisée par Sagem pour faire du haut-débit.
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.

On aura peut-être des surprises (mauvaises) en IPv6...

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 en téléchargeant simplement un gros fichier sur 01net.

corrector

  • Invité
Routeur puissant mais cher
« Réponse #22 le: 10 juin 2011 à 11:13:56 »
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.

Et c'était encore sur-puissant.

corrector

  • Invité
NAT-box : FTP : test sur Freebox v5
« Réponse #23 le: 11 juin 2011 à 19:40:49 »
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 :

la Freebox laisse passer tel quel tout segment TCP du client vers le serveur FTP,
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.

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.

La Freebox perd ces données incomplètes, ce qui provoque une retransmission TCP.

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).

 

Mobile View