Forum général.général parefeu routeur qui bloque Linux, pas FreeBSD, Windows, Mac

Posté par  .
Étiquettes :
0
4
août
2007
bonjour,

j'avais évoqué à cette adresse un problème de connexion à un serveur freeoes :
http://linuxfr.org/forums/10/21911.html

seulement depuis on s'est rendu compte que le problème n'était pas lié au serveur linux, mais apparemment au routeur qui contient un parefeu, car des serveurs (genre irc etc) installés sur une machine windows derrière le même routeur, ne sont pas accessibles via linux.

Je rappelle bièvement les faits : des serveurs linux ou windows installés derrière ce routeur sont accessibles sans problème depuis des ordinateurs distants sous windows, freebsd, solaris, mac osx... et certaines machines linux. Mais depuis d'autres machines, uniquement linux, cela ne passe pas. Par exemple depuis chez moi je peux accéder au serveur depuis la même machine sous windows, et pas sous linux. Mais une machine virtuelle sous solaris (nexenta) tournant sous le même linux peut se connecter sans problème ! Visiblement, c'est le pare-feu du serveur qui bloque certaines requêtes depuis linux, en fait on a l'impression que la connexion sous linux manque de "patate", et n'arrive pas à déclencher une réponse de la connexion à l'autre bout. Qu'est-ce que l'on pourrait faire pour modifier cela ?

Que cela soit sous debian ou opensuse, mon installation était par défaut, donc je ne vois pas ce que linux aurait de moins que ce que permet pourtant freebsd ou mac os x...

  • # option window scaling de TCP ?

    Posté par  . Évalué à 6.

    Si le ping fonctionne, mais pas les applications TCP, essaie de désactiver sur les linux le window scaling (qui permet d'obtenir des produits débit*RTT plus importants) car le routeur du milieu s'il est trop bête peut ne pas l'apprécier. (normalement le routeur ne doit pas toucher au niveau tcp et rester au niveau IP, mais sait-on jamais)

    echo 0 > /proc/sys/net/ipv4/tcp_window_scaling

    • [^] # Re: option window scaling de TCP ?

      Posté par  . Évalué à 2.

      tcp_window_scaling
      Activer le dimensionnement de la fenêtre TCP (RFC 1323). Ceci est actif par défaut. Cette fonctionnalité permet d'utiliser une grande fenêtre (> 64 Ko) sur une connexion TCP si le correspondant le supporte.


      visiblement le correspondant ne le supportait pas...

      Merci beaucoup, c'était bien cela !!
      Maintenant cela fonctionne parfaitement.

      Félicitation pour tes connaissances, et merci encore.

      Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

      • [^] # Re: option window scaling de TCP ?

        Posté par  . Évalué à 2.

        Pour la précision, même si le correspondant ne gère pas le window scaling, cela ne doit pas poser problème, car c'est une option.

        Détails sur http://kerneltrap.org/node/6723

        • [^] # Re: option window scaling de TCP ?

          Posté par  . Évalué à 2.

          merci de la précision, par contre justement cela semble continuer à poser problème, je ne vois pas en quoi cela a été résolu dans le noyau, par exemple si je vais sur http://www.everymac.com/ en ayant remis echo 1 > /proc/sys/net/ipv4/tcp_window_scaling , je ne peux pas y accéder non plus.
          Apparemment je n'ai jamais vraiment eu ce problème sur d'autres sites, donc il doit y avoir très peu de sites qui ne fonctionnent pas, mais d'un autre côté avec l'option ou sans l'option, chez moi la connexion va aussi vite et je ne vois pas de différence. Malgré tout c'est gênant de savoir que certains sites ne fonctionnent pas à cause de cela, et c'est assez hallucinant de lire ici :

          http://lwn.net/Articles/92727/

          The networking maintainers (and David Miller in particular) believe that the patch simply papers over a problem, and that adding hacks to the Linux network stack to accommodate broken routers is a mistake.


          déjà la pression de peut-être 10% d'utilisateurs linux ayant le problème sur les 4 % de machines linux dans le monde, cela me semble négligeable comme impact. Deuxièmement combien sauront identifier correctement le problème ?

          Sur la page de kerneltrap, quelqu'un avoue :

          I'm a kernel hacker. Most users of 2.6.17 will not be.
          The default should be something that works "by default".


          Et il a pensé durant un mois complet que le site everymac.com ne fonctionnait plus !

          Apparemment, la quantité de mémoire de la machine joue aussi. Si je me souviens bien, les machines linux avec le window scale d'activé qui arrivaient à aller sur ces site n'avaient pas plus de 500 Mo de ram. Sur mon pc de bureau, avec 1 Go, cela ne passe plus, ni sur un ibook avec debian et 640 mo de ram.

          Je crois également que vista vient d'incorporer cette option :
          http://en.wikipedia.org/wiki/TCP_window_scale_option

          je vais tester avec une machine au travail pour voir ce qu'il en est de la compatibilité avec les sites qui ne fonctionnent pas.

          À mon avis, comme qqu'un l'a suggéré sur kerneltrap, la bonne attitude serait d'avoir cette option d'activée malgré tout, et si un site ne répond pas correctement au bout d'un certain moment (1 min par exemple), désactiver l'option, mettre un message en console à ce sujet, et retenter la négociation.

          Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

          • [^] # Re: option window scaling de TCP ?

            Posté par  . Évalué à 3.

            Malgré tout c'est gênant de savoir que certains sites ne fonctionnent pas à cause de cela, et c'est assez hallucinant de lire ici :
            http://lwn.net/Articles/92727/


            Je ne vois pas en quoi c'est hallucinant. TCP sur internet ne va pas rester à la préhistoire par défaut parce que certains routeurs foutent la merde.

            Le window scaling est indispensable pour utiliser à plein un gros tuyau avec un RTT élevé (satellite, lien transatlantique, etc.).

            Donc faut penser également à ceux qui n'arrivent pas à tirer le meilleur d'une connexion : il est moins simple de diagnostiquer un faible débit en TCP (vu que c'est aussi lié à la bande passante dispo) que "pas de TCP, mais ping ok".

            - Et la RFC a plus de 15 ans, il serait peut-être temps d'en tirer parti
            - Les routeurs ne *doivent* pas toucher au niveau TCP, sinon on voit les désastres que ça donne.

            Apparemment, la quantité de mémoire de la machine joue aussi.


            Aucun lien, fils unique (enfin faudrait avoir très très peu de ram pour ne pas pouvoir utiliser le WS).

            Je crois également que vista vient d'incorporer cette option

            +par défaut


            À mon avis, comme qu'un l'a suggéré sur kerneltrap, la bonne attitude serait d'avoir cette option d'activée malgré tout, et si un site ne répond pas correctement au bout d'un certain moment (1 min par exemple), désactiver l'option, mettre un message en console à ce sujet, et retenter la négociation.


            C'est à dire lancer une deuxième session TCP si la première échoue, etc., ouvrir un popup à la demande du noyau ??
            Mais c'est du délire complet, excuse-moi :-)

            Non la bonne attitude, c'est de mettre un avertissement sur ce comportement dans les notes d'installation des distributions (ce que fait Debian par exemple, cf. http://www.debian.org/releases/stable/i386/release-notes/ch-(...) ), et d'avertir les sites qui se trouvent derrière un routeur qui outrepasse ses attributions en touchant à TCP.

            • [^] # Re: option window scaling de TCP ?

              Posté par  . Évalué à 1.

              moi j'ai juste remarqué que sous FreeBSD cela fonctionnait correctement, tout le temps.
              Au niveau des notifications il doit y avoir moyen de les faire à partir d'un système sur le modèle de celles que l'on peut avoir pour hal par exemple, cela ne doit pas être trop compliqué à gérer.

              Pour la quantité de RAM, apparemment c'est lié quand même :

              Mark Lord dit :

              A machine could be working perfectly, not (noticeably) affected
              by this bug. And then the user adds another stick of RAM to it.

              Poof.. many sites from the internet stop responding.
              Obviously the RAM upgrade broke things.. must be bad RAM, right?

              Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.