Forum Linux.général Low performance / IP MASQUERADE & IP Forwarding

Posté par  .
Étiquettes : aucune
2
16
fév.
2012

Bonjour,

J'ai un Centos 5.7 qui fait la passerelle entre mon réseau externe (Connecté Internet) et l'interne.

J'ai activé l'IP forwarding : 1 > /proc/sys/net/ipv4/ip_forward
J'ai activé le MASQUERADE : system-config-securitylevel-tui
Config Firewall

Ça marche bien. Mais la liaison Inet est hyper lent pour les machines sur l'interne!

DL sur le routeur: 5+MB/s
DL sur l'interne: 15-ko/s

Le meilleur: dès que je lance un DL ou un TCPDUMP depuis une session interactive sur le routeur, le DL de la machine en interne speed up jusqu'au débit max.

Qu'est-ce qui m'arrive ?!

Merci les gars,

Nicolas.

  • # Problème de résolution de DNS ?

    Posté par  (site web personnel) . Évalué à 2.

    Lorsque tu lances le "tcpdump" depuis la session interaxtive, tu le fais avec quelque chose du style "tcpdump -i eth0" ?

    Essayes plutôt un "tcpdump -n -i eth0" : Cela évitera à tcpdump à associer un nom DNS aux adresses IP qu'il affiche.

    Dans ce cas, si la connexion est de nouveau lente pour les machines en interne, c'est que tu as un problème lié aux DNS

    De plus, je vois dans ta configuration un "other ports domain:tcp". Or, généralement les machines connectées à internet utilise de l'UDP pour faire la résolution nom/adresse IP (ie: ce qui doit s'appeler ici "domain").

    Essayes donc avec un "other ports domain:udp"

  • # DNS oriented issue tested

    Posté par  . Évalué à 1.

    Salut Olivier,

    Merci pour ton retour.

    J'avais effectivement lancé le tcpdump sans résolution DNS : "tcpdump -n -i eth0"

    J'ai tout de même ajouté 53:udp à la liste des allowed incoming ports.

    Le problème est le même... Le DL depuis l'interne commence fort puis ralentit juste après les quelques premiers Mo téléchargés.

    C'est assez perturbant. Je lance TCPDump sur le routeur, mon DL repart au taquet. J'arrête TCPDump, le DL ralentit, etc ... C'est reproductible à loisir.

    C'est la même en http ou https

    jamais vu ça :)

  • # masquerade, mais pas du bon coté ?

    Posté par  . Évalué à 2.

    tu lui dis que l'interface de confiance (interne) est eth1
    et tu fais du masquerade sur cette meme interface ?

    alors qu'il faudrait au contraire masqué au routeur (eth0) qu'il y a plusieurs machines derriere lui.

    • [^] # Re: masquerade, mais pas du bon coté ?

      Posté par  . Évalué à 1.

      Salut NeoX,

      Oui mais non en fait, j'ai pas relevé l'info d'Olivier mais il a inversé (il avait une chance sur deux en fait).

      Donc, plus précisement:

      • Eth0 : Outside (Inet)
      • Eth1 : Inside (LAN)

      Commande executée: tcpdump -i eth0 -n
      Rendu de la commande : les a/r http "Router External IP"/"Distant Website Public IP".

      Le système me refuse d'activer MASQUERADE sur une untrusted interface

      Ici le script IPTABLES généré:
      # Firewall configuration written by system-config-securitylevel
      # Manual customization of this file is not recommended.
      *filter
      :INPUT ACCEPT [0:0]
      :FORWARD ACCEPT [0:0]
      :OUTPUT ACCEPT [0:0]
      :RH-Firewall-1-INPUT - [0:0]
      -A INPUT -j RH-Firewall-1-INPUT
      -A FORWARD -j RH-Firewall-1-INPUT
      -A RH-Firewall-1-INPUT -i lo -j ACCEPT
      -A RH-Firewall-1-I-A RH-Firewall-1-INPUT -i eth1 -j ACCEPT
      -A RH-Firewall-1-INPUT -p icmp --icmp-type any -j ACCEPT
      -A RH-Firewall-1-INPUT -p 50 -j ACCEPT
      -A RH-Firewall-1-INPUT -p 51 -j ACCEPT
      -A RH-Firewall-1-INPUT -p udp --dport 5353 -d 224.0.0.251 -j ACCEPT
      -A RH-Firewall-1-INPUT -p udp -m udp --dport 631 -j ACCEPT
      -A RH-Firewall-1-INPUT -p tcp -m tcp --dport 631 -j ACCEPT
      -A RH-Firewall-1-INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
      -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 53 -j ACCEPT
      -A RH-Firewall-1-INPUT -m state --state NEW -m udp -p udp --dport 53 -j ACCEPT
      -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT
      -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT
      -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 443 -j ACCEPT
      -A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited
      COMMIT
      *mangle
      :PREROUTING ACCEPT [0:0]
      :INPUT ACCEPT [0:0]
      :FORWARD ACCEPT [0:0]
      :OUTPUT ACCEPT [0:0]
      :POSTROUTING ACCEPT [0:0]
      -A PREROUTING -i eth1 -j MARK --set-mark 0x9
      COMMIT
      *nat
      :PREROUTING ACCEPT [0:0]
      :OUTPUT ACCEPT [0:0]
      :POSTROUTING ACCEPT [0:0]
      -A POSTROUTING -m mark --mark 0x9 -j MASQUERADE
      COMMIT

      J'insiste sur le fait que le routing/NAT fonctionne (bien que certainement mal configuré). Mon Inside connecte bien à l'Inet. Juste les perfs qui sont à la ramasse si non interaction sur le routeur.

      Merci,

      Nicolas.

      • [^] # Re: masquerade, mais pas du bon coté ?

        Posté par  . Évalué à 2.

        essaie quand meme en mettant le masquerade sur eth0 (vers le routeur) plutot que sur eth1
        ca ne peut pas faire de mal, et ca resoudra peut-etre le probleme de performance.

        ah, et verifie tes plages reseaux interne/externe
        afin d'etre sur qu'elles ne se chevauchent pas (engendrant alors des erreurs de routage entre les deux interfaces)

        • [^] # Re: masquerade, mais pas du bon coté ?

          Posté par  . Évalué à 1.

          Ok j'ai tenté un truc.

          j'ai décoché Eth1 dans 'Trusted devices' et 'MASQUERADE devices', depuis l'interface 'system-config-securitylevel-tui'.

          Suivant tes recommandations, j'ai ensuite modifié manuellement le fichier /etc/sysconfig/iptables pour celui ci-dessous. Le changement est dans l'ajout de la section '*nat'.

          J'ai le même résultat :(

          Tiens par contre, tcpdump me donne l'@ IP du routeur sur Eth0, mais l'@ IP distante sur Eth1. C'est normal ça ? Je m'attendais à voir l'@ IP du routeur aussi sur Eth1...

          *nat
          :PREROUTING ACCEPT [0:0]
          :POSTROUTING ACCEPT [0:0]
          :OUTPUT ACCEPT [0:0]
          -A POSTROUTING -o eth0 -j MASQUERADE
          COMMIT
          *filter
          :INPUT ACCEPT [0:0]
          :FORWARD ACCEPT [0:0]
          :OUTPUT ACCEPT [0:0]
          :RH-Firewall-1-INPUT - [0:0]
          -A INPUT -j RH-Firewall-1-INPUT
          -A FORWARD -j RH-Firewall-1-INPUT
          -A RH-Firewall-1-INPUT -i lo -j ACCEPT
          -A RH-Firewall-1-INPUT -p icmp --icmp-type any -j ACCEPT
          -A RH-Firewall-1-INPUT -p 50 -j ACCEPT
          -A RH-Firewall-1-INPUT -p 51 -j ACCEPT
          -A RH-Firewall-1-INPUT -p udp --dport 5353 -d 224.0.0.251 -j ACCEPT
          -A RH-Firewall-1-INPUT -p udp -m udp --dport 631 -j ACCEPT
          -A RH-Firewall-1-INPUT -p tcp -m tcp --dport 631 -j ACCEPT
          -A RH-Firewall-1-INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
          -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 53 -j ACCEPT
          -A RH-Firewall-1-INPUT -m state --state NEW -m udp -p udp --dport 53 -j ACCEPT
          -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT
          -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT
          -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 443 -j ACCEPT
          -A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited
          COMMIT

          Merci,

          Nicolas.

          • [^] # Re: masquerade, mais pas du bon coté ?

            Posté par  . Évalué à 2.

            j'ai décoché Eth1 dans 'Trusted devices' et 'MASQUERADE devices', depuis l'interface 'system-config-securitylevel-tui'.

            Suivant tes recommandations, j'ai ensuite modifié manuellement le fichier /etc/sysconfig/iptables pour celui ci-dessous. Le changement est dans l'ajout de la section '*nat'.

            J'ai le même résultat :(

            oui mais non.

            avant de cocher/decocher, il faut comprendre ce que tu fais.

            Trusted DEvice : c'est l'interface dans laquelle tu as confiance (le LAN, donc eth1) et il faut evidemment en choisir une.

            Le masquerade Device : c'est l'interface que tu vas partager avec Trusted Device, ce serait donc eth0 (celle qui est connecté à ton modem/routeur)

            le script iptable lui va etre modifié par cette interface pour correspondre à ce que tu viens de faire.

            • [^] # Re: masquerade, mais pas du bon coté ?

              Posté par  . Évalué à 1.

              Trusted Device active (cf règles) ou désactive (tout passe) IPTABLES sur l'interface considérée. Donc si je le décoches, les règles vont s'appliquer (IPTABLES ON), et donc permettre http et https (cf mes règles, voir premier post).

              Le Masquerade device agit sur le -i et non sur le -o. Tout ce qui rentre par Eth1 sera Naté, quelqu'en soit la sortie. C'est ça qui te perd j'ai l'impression. Regarde bien le script de mon post initial.

              Je ne connais par contre pas encore la différence entre SNAT/DNAT et MASQUERADE.

              De plus, pour un DL depuis une machine en interne vers un site distant, tcpdump sur le routeur me donne l'@ IP du routeur sur Eth0, mais l'@ IP distante sur Eth1. C'est normal ça ? Je m'attendais à voir l'@ IP du routeur aussi sur Eth1...

              Merci,

              Nicolas.

              • [^] # Re: masquerade, mais pas du bon coté ?

                Posté par  . Évalué à 2. Dernière modification le 17 février 2012 à 13:24.

                le NAT/masquerade doit se faire en SORTIE (donc sur eth0 en postrouting)

                et c'est le cas dans le script precedent :

                -A POSTROUTING -o eth0 -j MASQUERADE

                • [^] # Re: masquerade, mais pas du bon coté ?

                  Posté par  . Évalué à 0.

                  Oui, le script précédent a été édité manuellement, pour test, by-passant system-config-securitylevel-tui.

                  Si je reprends une partie de la conf initiale (cf plus bas), généré par system-config-securitylevel-tui, on voit bien que si MASQUERADE est appliquée sur Eth1 (et non Eth0 comme souhaité), c'est parce-qu’il s'applique en POSTROUTING sur des paquets qui sont entrés par Eth1 (alors étiqueté mark 0x9). Sous entendu il nate pas ce qui sort par Eth0 mais ce qui rentre par Eth1 (quelque en soit la sortie). Est-ce que cela a du sens ?

                  *mangle
                  :PREROUTING ACCEPT [0:0]
                  :INPUT ACCEPT [0:0]
                  :FORWARD ACCEPT [0:0]
                  :OUTPUT ACCEPT [0:0]
                  :POSTROUTING ACCEPT [0:0]
                  -A PREROUTING -i eth1 -j MARK --set-mark 0x9
                  COMMIT
                  *nat
                  :PREROUTING ACCEPT [0:0]
                  :OUTPUT ACCEPT [0:0]
                  :POSTROUTING ACCEPT [0:0]
                  -A POSTROUTING -m mark --mark 0x9 -j MASQUERADE
                  COMMIT

  • # Problème de fragmentation mtu

    Posté par  . Évalué à 2.

    Cela ressemble a un problème de fragmentation ip mtu/mss.

    Il faudrait tester ce genre de règles (à adapter):
    iptables -t mangle -A FORWARD -p tcp --syn -j TCPMSS --clamp-mss-to-pmtu
    iptables -t mangle -A FORWARD -p tcp --syn -j TCPMSS --set-mss 1452

    • [^] # Re: Problème de fragmentation mtu

      Posté par  . Évalué à 1.

      Salut Jean,

      Merci pour ton aide. Je vais faire un essai en ajoutant tes règles.

      Quelles adaptions serais-je amener à faire : Baisser la taille du MTU en partant de 1452 jusqu'à ce que je retrouve les performances réseaux attendues ?

      Merci,

      Nicolas.

    • [^] # Re: Problème de fragmentation mtu

      Posté par  . Évalué à 1.

      Je viens d'essayer. Ça n'a rien changé aux perfs (toujours au sol)...

      Conf IPTables appliquée:

      *filter
      :INPUT ACCEPT [0:0]
      :FORWARD ACCEPT [0:0]
      :OUTPUT ACCEPT [0:0]
      :RH-Firewall-1-INPUT - [0:0]
      -A INPUT -j RH-Firewall-1-INPUT
      -A FORWARD -j RH-Firewall-1-INPUT
      -A RH-Firewall-1-INPUT -i lo -j ACCEPT
      -A RH-Firewall-1-INPUT -i eth1 -j ACCEPT
      -A RH-Firewall-1-INPUT -p icmp --icmp-type any -j ACCEPT
      -A RH-Firewall-1-INPUT -p 50 -j ACCEPT
      -A RH-Firewall-1-INPUT -p 51 -j ACCEPT
      -A RH-Firewall-1-INPUT -p udp --dport 5353 -d 224.0.0.251 -j ACCEPT
      -A RH-Firewall-1-INPUT -p udp -m udp --dport 631 -j ACCEPT
      -A RH-Firewall-1-INPUT -p tcp -m tcp --dport 631 -j ACCEPT
      -A RH-Firewall-1-INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
      -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 53 -j ACCEPT
      -A RH-Firewall-1-INPUT -m state --state NEW -m udp -p udp --dport 53 -j ACCEPT
      -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT
      -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT
      -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 443 -j ACCEPT
      -A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited
      COMMIT
      *mangle
      :PREROUTING ACCEPT [0:0]
      :INPUT ACCEPT [0:0]
      :FORWARD ACCEPT [0:0]
      :OUTPUT ACCEPT [0:0]
      :POSTROUTING ACCEPT [0:0]
      -A PREROUTING -i eth1 -j MARK --set-mark 0x9
      -A FORWARD -p tcp --syn -j TCPMSS --clamp-mss-to-pmtu
      -A FORWARD -p tcp --syn -j TCPMSS --set-mss 1452
      COMMIT
      *nat
      :PREROUTING ACCEPT [0:0]
      :OUTPUT ACCEPT [0:0]
      :POSTROUTING ACCEPT [0:0]
      -A POSTROUTING -m mark --mark 0x9 -j MASQUERADE
      COMMIT
      
      
  • # ip fixe ?

    Posté par  (site web personnel) . Évalué à 2.

    Les ip sont fixes ?

    Système - Réseau - Sécurité Open Source

    • [^] # Re: ip fixe ?

      Posté par  . Évalué à 1.

      Bonjour Nono,

      Oui, les IP sont fixes. Le routeur est directement connecté à l'Internet (IP publique). L'adresse interne est de mon choix : un sous-réseau réservé pour l'interne (192.168.x.0/24).

      Merci,

      Nicolas.

      • [^] # Re: ip fixe ?

        Posté par  (site web personnel) . Évalué à 2. Dernière modification le 17 février 2012 à 13:01.

        Il est souhaitable d'utiliser la cible SNAT pour les connexions permanentes.

        C'est du filaire le réseau interne ? ( mtu )

        Je ne vois pas pourquoi les machines internes passeraient par le routeur ?

        Tu logues les paquets refusés ?

        Système - Réseau - Sécurité Open Source

      • [^] # Re: ip fixe ?

        Posté par  . Évalué à 2.

        il manque une plage IP dans tes exemples.

        avec le schema suivant

        Interne [] < - >[192.168.x.0/24] CentOS [???]< - > [???] Routeur [IP-publique] < - > Internet

        il manque les IPs que tu utilises entre le routeur et centos

        • [^] # Re: ip fixe ?

          Posté par  . Évalué à 0.

          Le routeur et le CentOS sont une seule machine

          LAN <-> Centos <-> Inet

          • [^] # Re: ip fixe ?

            Posté par  . Évalué à 2.

            ton modem est sur eth0, est fourni directement l'IP publique à centOS ?

            donc, active eth1 en trusted device et eth0 en masquerade comme indiqué plus haut.

            • [^] # Re: ip fixe ?

              Posté par  . Évalué à 0.

              Si je reprends une partie de la conf initiale (cf plus bas), généré par system-config-securitylevel-tui, on voit bien que si MASQUERADE est appliquée sur Eth1 (et non Eth0 comme souhaité), c'est parce-qu’il s'applique en POSTROUTING sur des paquets qui sont entrés par Eth1 (alors étiqueté mark 0x9). Sous entendu il nate pas ce qui sort par Eth0 mais ce qui rentre par Eth1 (quelque en soit la sortie). Est-ce que cela a du sens ?

              *mangle
              :PREROUTING ACCEPT [0:0]
              :INPUT ACCEPT [0:0]
              :FORWARD ACCEPT [0:0]
              :OUTPUT ACCEPT [0:0]
              :POSTROUTING ACCEPT [0:0]
              -A PREROUTING -i eth1 -j MARK --set-mark 0x9
              COMMIT
              *nat
              :PREROUTING ACCEPT [0:0]
              :OUTPUT ACCEPT [0:0]
              :POSTROUTING ACCEPT [0:0]
              -A POSTROUTING -m mark --mark 0x9 -j MASQUERADE
              COMMIT

              • [^] # Re: ip fixe ?

                Posté par  . Évalué à 2.

                marquer un paquet monopolise de la ressource

                c'est pour ca qu'historiquement (j'ai pas fait d'iptable depuis quelques temps)
                on faisait juste le post-routing en sortie (sur eth0 : dans ton cas)
                en supprimant la ligne prerouting set-mark 0x9 et en ne laissant que
                > -A POSTROUTING -o eth0 -j MASQUERADE

                • [^] # Re: ip fixe ?

                  Posté par  . Évalué à 1.

                  Bien reçu,

                  Mais je ne pense pas avoir de problème de performance, le CentOS est juste ... surdimensionné pour cette tâche :/

                  J'ai essayé (voir post précédent) un MASQUERADE sur -o Eth0 (sans tag) mais j'ai obtenu les mêmes résultats (piètre performance).

                  Le problème pourrait-il venir de la taille de l'encapsulation (MTU). Dans le sens ou mes paquets étiquetés 0x9 seraient-ils différents des classiques ?

                  De plus, pour un DL depuis une machine en interne vers un site distant, tcpdump sur le routeur me donne l'@ IP du routeur sur Eth0, mais l'@ IP distante sur Eth1. C'est normal ça ? Je m'attendais à voir l'@ IP du routeur aussi sur Eth1...

                  Merci,

                  Nicolas.

                  • [^] # Re: ip fixe ?

                    Posté par  . Évalué à 2.

                    pour le MTU, aucune idée

                    je viens de faire un tcpdump sur mon interface reseau sur mon serveur (je suis connecté en ssh)

                    on voit en fait la communication dans les 2 sens.

                    13:58:38.741363 IP A.B.C.D.51023 > B.C.D.E: Flags [P.], seq 289:337, ack 389296, win 65535, options [nop,nop,TS val 317748529 ecr 2280614191], length 48
                    13:58:38.741562 IP B.C.D.E > A.B.C.D.51023: Flags [P.], seq 391840:392224, ack 337, win 198, options [nop,nop,TS val 2280614198 ecr 317748529], length 384

                    • [^] # Re: ip fixe ?

                      Posté par  (site web personnel) . Évalué à 2.

                      net/ipv4/tcp_window_scaling=0 ?

                      Système - Réseau - Sécurité Open Source

                      • [^] # Re: ip fixe ?

                        Posté par  . Évalué à 0. Dernière modification le 17 février 2012 à 14:20.

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

                        Même résultat... :(

                        Je suis quand même étonné du semi-NAT constaté par TCPDump (cf post précedent)

                        Nicolas

                    • [^] # Re: ip fixe ?

                      Posté par  . Évalué à 0.

                      C'est super louche :)

                      je lance un DL depuis une machine sur le LAN. Je lance TCPDump sur le routeur.

                      Sur Eth1, j'ai ça:
                      21:59:53.753424 IP DI.ST.AN.TE.http > 192.168.x.y.64760: . 188341:189801(1460) ack 339 win 3918
                      21:59:53.753759 IP 192.168.x.y.64760 > DI.ST.AN.TE.http: . ack 192721 win 32850

                      Sur Eth0, j'ai ça:
                      22:04:04.636236 IP DI.ST.AN.TE.http > PU.BL.IQ.UE.64764: . 124429889:124431349(1460) ack 339 win 3918
                      22:04:04.636256 IP PU.BL.IQ.UE.64764 > DI.ST.AN.TE.http: . ack 124424049 win 30660

                      avec:
                      - PU.BL.IQ.UE adresse IP publique du routeur CentOS ;
                      - DI.ST.AN.TE adresse IP publique du site web distant ;
                      - 192.168.x.y adresse IP privée de la machine initiant le DL.

                      Merci,

                      Nicolas.

                      • [^] # Re: ip fixe ?

                        Posté par  . Évalué à 2.

                        je dirais que tout va bien.

                        sur eth1 : tu vois bien que le PC 192.168.x.y veut se connecter à DI.ST.AN.TE

                        sur eth0 : tu vois bien que ton routeur (PU.BL.IQ.UE) veut se connecter à DI.ST.AN.TE

                        ca c'est un fonctionnement normal, puisque c'est bien ton routeur qui va aller chercher les fichiers distantes, les ramener, et se souvenir que c'etait pour la machine 192.168.x.y et lui redonner.

                        • [^] # Re: ip fixe ?

                          Posté par  . Évalué à 0.

                          Ok, cool. Donc la masquerade fonctionne correctement... C'est déjà ça.

                          So what's the f**k?! :)

                        • [^] # Re: ip fixe ?

                          Posté par  . Évalué à 0.

                          Pour suivre le post de Jean, j'ai suivi les recommandations de cette page: http://tldp.org/HOWTO/IP-Masquerade-HOWTO/mtu-issues.html

                          J'ai donc ajouté à ma table mangle les deux lignes de fin:
                          *mangle
                          :PREROUTING ACCEPT [0:0]
                          :INPUT ACCEPT [0:0]
                          :FORWARD ACCEPT [0:0]
                          :OUTPUT ACCEPT [0:0]
                          :POSTROUTING ACCEPT [0:0]
                          -A PREROUTING -i eth1 -j MARK --set-mark 0x9
                          -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
                          -A FORWARD -p tcp --syn -j TCPMSS --set-mss 1412

                          Et ben ça change rien.... sniff.

                          Moi je comprends toujours pas pourquoi le DL depuis une machine du LAN fonctionne à pleine vitesse seulement quand je lance un DL ou un TCPDump depuis une console interactive sur mon routeur.

                          • [^] # Re: ip fixe ?

                            Posté par  . Évalué à 2.

                            essaye un wget seul depuis la machine sur le reseau
                            puis le meme wget depuis ta machine routeur

                            j'imagine que les machines du reseau recoivent leurs parametres reseaux par le DHCP de ta passerelle, avec l'IP de la passerelle (ta machine CentOS), avec l'IP des DNS du fournisseur, ou l'IP de la passerelle (ta machine CentOS qui ferait aussi DNS) ?

                            • [^] # Re: ip fixe ?

                              Posté par  . Évalué à 0.

                              Résultat des courses:

                              • wget seulement depuis la station de travail sur le LAN : 12ko/s
                              • wget seulememt depuis le routeur : 5Mo/s
                              • wget sur les deux, en parallèle : 5Mo/s sur les deux

                              Tout le monde est en adressage statique. J'utilise pour le moment le DNS de mon provideur (IP publique), dont l'adresse est configurée en dur dans le routeur et les stations de travail.

                              nslookup fonctionne bien sur les deux (ultra rapide à répondre).

                              Nico.

Suivre le flux des commentaires

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