loursdeswab a écrit 17 commentaires

iPerf pour tester le débit ?! (pardon)

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.

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.

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

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

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

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.

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.

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

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

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.

Le routeur et le CentOS sont une seule machine

LAN <-> Centos <-> Inet

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

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.

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.

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.

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.

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