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
Ç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 Olivier (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 loursdeswab . É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 NeoX . É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 loursdeswab . É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:
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 NeoX . É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 loursdeswab . É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 NeoX . Évalué à 2.
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 loursdeswab . É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 NeoX . É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 :
[^] # Re: masquerade, mais pas du bon coté ?
Posté par loursdeswab . É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 _jean . É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 loursdeswab . É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 loursdeswab . Évalué à 1.
Je viens d'essayer. Ça n'a rien changé aux perfs (toujours au sol)...
Conf IPTables appliquée:
# ip fixe ?
Posté par nono14 (site web personnel) . Évalué à 2.
Les ip sont fixes ?
Système - Réseau - Sécurité Open Source - Ouvert à de nouvelles opportunités
[^] # Re: ip fixe ?
Posté par loursdeswab . É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 nono14 (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 - Ouvert à de nouvelles opportunités
[^] # Re: ip fixe ?
Posté par NeoX . É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 loursdeswab . Évalué à 0.
Le routeur et le CentOS sont une seule machine
LAN <-> Centos <-> Inet
[^] # Re: ip fixe ?
Posté par NeoX . É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 loursdeswab . É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 NeoX . É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 loursdeswab . É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 NeoX . É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.
[^] # Re: ip fixe ?
Posté par nono14 (site web personnel) . Évalué à 2.
net/ipv4/tcp_window_scaling=0 ?
Système - Réseau - Sécurité Open Source - Ouvert à de nouvelles opportunités
[^] # Re: ip fixe ?
Posté par loursdeswab . É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 loursdeswab . É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 NeoX . É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 loursdeswab . É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 loursdeswab . É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 NeoX . É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 loursdeswab . Évalué à 0.
Résultat des courses:
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.
[^] # Re: ip fixe ?
Posté par nono14 (site web personnel) . Évalué à 2.
tu as testé iperf ?
Système - Réseau - Sécurité Open Source - Ouvert à de nouvelles opportunités
[^] # Re: ip fixe ?
Posté par loursdeswab . Évalué à 0.
iPerf pour tester le débit ?! (pardon)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.