Hallo, Liste!
Ich habe seit einige Tage ein komisches Problem...
Also, zu Hause habe ich ein kleines Netz mit 2 Rechner. Mein Rechner hat ein DSL-Modem (und ein Device ppp0) und ist für NAT konfiguriert. Der andere nutzt meinen Rechner um das Internet zu surfen.
Hier sind die Regel von iptables auf meinem Rechner:
/sbin/iptables -t nat -A POSTROUTING -d ! 192.168.10.0/24 -j MASQUERADE /sbin/iptables -A FORWARD -s 192.168.10.0/24 -j ACCEPT /sbin/iptables -A FORWARD -d 192.168.10.0/24 -j ACCEPT
Wenn ich die Seite der Ostsächsische Sparkasse (https://banking.ostsaechsische-sparkasse-dresden.de/) von meinem Rechner aufrufe, alle geht problemlos und schnell. Von dem anderen Rechner geht unglaublich langsam.
Das gleiche Problem habe ich im Büro, mit der gleichen Konfiguration.
Wie gesagt, das Problem habe ich nur seit einige Tage und die Konfiguration ist knapp 3 Jahre alt.
Mit ngrep habe ich gesehen, daß die Pakete auf der Port 443 viel kleiner sind, wenn die Seite von dem Rechner hinter dem Gateway aufgerufen ist.
Das komische an der ganzen Sache ist, daß andere Seiten in HTTPs problemlos und schnell aufgerufen werden können, also es sieht so aus, daß das Problem nur bei der Sparkasse ist.
Hat jemand eine Ahnung, was das Problem ist? Und vielleicht auch, wie ich das Problem lösen kann? :)
Vielen Dank im Voraus Luca Bertoncello (lucabert@lucabert.de)
Hi Luca,
On Wed, Jun 04, 2008 at 19:25:01 +0200, Luca Bertoncello wrote:
Hier sind die Regel von iptables auf meinem Rechner:
/sbin/iptables -t nat -A POSTROUTING -d ! 192.168.10.0/24 -j MASQUERADE
Daraus wuerde ich eher diese Regel machen: /sbin/iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE
Wenn moeglich, iptables-Regeln (zusaetzlich) am Interface festmachen. IP-Adressen lassen sich faken, Interfaces nicht.
Wenn ich die Seite der Ostsaechsische Sparkasse (https://banking.ostsaechsische-sparkasse-dresden.de/) von meinem Rechner aufrufe, alle geht problemlos und schnell. Von dem anderen Rechner geht unglaublich langsam.
[...]
Mit ngrep habe ich gesehen, dass die Pakete auf der Port 443 viel kleiner sind, wenn die Seite von dem Rechner hinter dem Gateway aufgerufen ist.
Hoert sich nach einem MTU-Problem an. Versuch mal, die MTU-Groesse auf dem "langsamen" Rechner zu verringern: ifconfig eth0 mtu 1200
Wenn es damit schneller geht, werden irgendwo auf der Strecke zwischen diesem Rechner und dem Onlinebanking-Rechner ICMP-fragmentation-needed Pakete verworfen. Die Art von ICMP-Paketen ist aber bei path MTU discovery zwingend noetig.
Wie gesagt, das Problem habe ich nur seit einige Tage und die Konfiguration ist knapp 3 Jahre alt.
Dann hat wohl irgendein Experte auf einem Router die Firewall-Konfiguration etwas zu dicht gezogen, nach dem Motto "ICMP ist boese".
Gruss, Chris
Christian Perle chris@linuxinfotag.de schrieb:
Hoert sich nach einem MTU-Problem an. Versuch mal, die MTU-Groesse auf dem "langsamen" Rechner zu verringern: ifconfig eth0 mtu 1200
Schon probiert! Keine Änderung...
Dann hat wohl irgendein Experte auf einem Router die Firewall-Konfiguration etwas zu dicht gezogen, nach dem Motto "ICMP ist boese".
Es kann sein... Also, das Problem ist bei der Sparkasse?
Grüße Luca Bertoncello (lucabert@lucabert.de)
On Thursday 05 June 2008 10:39, Luca Bertoncello wrote:
Christian Perle chris@linuxinfotag.de schrieb:
Dann hat wohl irgendein Experte auf einem Router die Firewall-Konfiguration etwas zu dicht gezogen, nach dem Motto "ICMP ist boese".
Es kann sein... Also, das Problem ist bei der Sparkasse?
Nein. Bei mir geht diese Seite problemlos. Was sagt Deine eigene Firewall zum Thema ICMP?
Konrad
Konrad Rosenbaum konrad@silmor.de schrieb:
Nein. Bei mir geht diese Seite problemlos. Was sagt Deine eigene Firewall
zum
Thema ICMP?
Nutzst du auch NAT? Oder hast du ein ppp0 auf deinem PC?
Mein FW sagt einfach:
/sbin/iptables -A INPUT -i ppp0 -p icmp --icmp-type echo-request -m limit --limit 6/m --limit-burst 5 -j ACCEPT
Aber das sollte gar nix machen in dem Fall...
Grüße Luca Bertoncello (lucabert@lucabert.de)
Luca Bertoncello lucabert@lucabert.de (Do 05 Jun 2008 13:13:00 CEST):
Konrad Rosenbaum konrad@silmor.de schrieb:
Nein. Bei mir geht diese Seite problemlos. Was sagt Deine eigene Firewall
zum
Thema ICMP?
Nutzst du auch NAT? Oder hast du ein ppp0 auf deinem PC?
Mein FW sagt einfach:
/sbin/iptables -A INPUT -i ppp0 -p icmp --icmp-type echo-request -m limit --limit 6/m --limit-burst 5 -j ACCEPT
Vielleicht schickst du uns mal alle Firwall-Regeln? Danke.
Heiko Schlittermann hs@schlittermann.de schrieb:
Vielleicht schickst du uns mal alle Firwall-Regeln?
Kein Problem! Hier meine Firewall auf Arbeit. Die FW zu Hause ist sehr ähnlich. Und auch hier auf Arbeit habe ich das gleiche Problem...
------------------------------------ /sbin/iptables --new-chain DROPIPS /sbin/iptables --new-chain DYNIPS
/sbin/iptables -A INPUT -j DROPIPS /sbin/iptables -A INPUT -j DYNIPS
/sbin/iptables -A INPUT -i ppp0 -p icmp --icmp-type echo-request -m limit --limit 6/m --limit-burst 5 -j ACCEPT /sbin/iptables -A INPUT -i ppp0 -p icmp --icmp-type timestamp-request -j DROP /sbin/iptables -A INPUT -i ppp0 -p icmp --icmp-type timestamp-reply -j DROP /sbin/iptables -A INPUT -i ppp0 -p tcp --tcp-flags SYN,FIN SYN,FIN -j DROP /sbin/iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT /sbin/iptables -A INPUT -i ppp0 -j DROP
/sbin/iptables -t nat -A POSTROUTING -d ! 192.168.2.0/24 -j MASQUERADE /sbin/iptables -A FORWARD -s 192.168.2.0/24 -j ACCEPT /sbin/iptables -A FORWARD -d 192.168.2.0/24 -j ACCEPT ------------------------------------
Grüße Luca Bertoncello (lucabert@lucabert.de)
Luca Bertoncello lucabert@lucabert.de (Mi 04 Jun 2008 19:25:01 CEST):
Hallo, Liste!
Ich habe seit einige Tage ein komisches Problem...
Also, zu Hause habe ich ein kleines Netz mit 2 Rechner. Mein Rechner hat ein DSL-Modem (und ein Device ppp0) und ist für NAT konfiguriert. Der andere nutzt meinen Rechner um das Internet zu surfen.
Hier sind die Regel von iptables auf meinem Rechner:
/sbin/iptables -t nat -A POSTROUTING -d ! 192.168.10.0/24 -j MASQUERADE /sbin/iptables -A FORWARD -s 192.168.10.0/24 -j ACCEPT /sbin/iptables -A FORWARD -d 192.168.10.0/24 -j ACCEPT
würde ich etwa so bauen:
iptables -t nat -A POSTROUTING -j MASQUERADE -o <extern>
iptables -t filter -A FORWARD -j ACCEPT -m state --state ESTABLISHED,RELATED iptables -t filter -A FORWARD -j ACCEPT -i <intern>
Das sollte aber mit Deinem Problem nichts zu tun haben.
Mit ngrep habe ich gesehen, daß die Pakete auf der Port 443 viel kleiner sind, wenn die Seite von dem Rechner hinter dem Gateway aufgerufen ist.
Kannst Du ein tcpdump auf der Außenseite des Gateways machen? Und nicht nur für Port 443 sondern etwa so
tcpdump -w /tmp/log -i <extern> host <sparkasse>
Und das dann mal genau ansehen?
Das komische an der ganzen Sache ist, daß andere Seiten in HTTPs problemlos und schnell aufgerufen werden können, also es sieht so aus, daß das Problem nur bei der Sparkasse ist.
Hat jemand eine Ahnung, was das Problem ist? Und vielleicht auch, wie ich das Problem lösen kann? :)
Möglicherweise, wie hier auch schon vermutet, hat es was mit Path MTU Discovery zu tun. Oder 1000 andere Dinge.
Hat der interne Rechner, bei dem das so langsam geht, eine eingeschaltete Firewall?
Heiko Schlittermann hs@schlittermann.de schrieb:
Kannst Du ein tcpdump auf der AuÃenseite des Gateways machen? Und nicht nur für Port 443 sondern etwa so
tcpdump -w /tmp/log -i <extern> host <sparkasse>Und das dann mal genau ansehen?
Ich habe eingentlich das gleiche mit ngrep gemacht... Aber, außer daß die Pakete viel kleiner sind, sehe ich gar nix...
Möglicherweise, wie hier auch schon vermutet, hat es was mit Path MTU Discovery zu tun. Oder 1000 andere Dinge.
MTU habe ich schon geändert, hat keine Verbesserung gebracht.
Hat der interne Rechner, bei dem das so langsam geht, eine eingeschaltete Firewall?
Nein, keine Firewall.
Grüße Luca Bertoncello (lucabert@lucabert.de)
Luca Bertoncello lucabert@lucabert.de (Do 05 Jun 2008 13:15:04 CEST):
Heiko Schlittermann hs@schlittermann.de schrieb:
Kannst Du ein tcpdump auf der AuÃenseite des Gateways machen? Und nicht nur für Port 443 sondern etwa so
tcpdump -w /tmp/log -i <extern> host <sparkasse>Und das dann mal genau ansehen?
Ich habe eingentlich das gleiche mit ngrep gemacht... Aber, außer daß die Pakete viel kleiner sind, sehe ich gar nix...
Bist Du Dir sicher, mit ngrep wirklich die Paketgrösse zu sehen? Kannst Du einen (komprimierten) Dump (erzeugt mit tcpdump s.o.) so einer Session mal schicken?
Wir sollten uns die Frage stellen, *warum* diese Pakete viel kleiner sind. Und vielleicht reichen kleinere Pakete ja auch schon für die beschriebene Verlangsamung - wenn ausreichend hohe Latenz da ist.
Möglicherweise, wie hier auch schon vermutet, hat es was mit Path MTU Discovery zu tun. Oder 1000 andere Dinge.
MTU habe ich schon geändert, hat keine Verbesserung gebracht.
Path MTU discovery hat nur sekundär mit Deiner MTU was zu tun. Aber wenn diese klein genug ist, sollte es aber daran nicht liegen.
Heiko Schlittermann hs@schlittermann.de schrieb:
Bist Du Dir sicher, mit ngrep wirklich die Paketgrösse zu sehen? Kannst Du einen (komprimierten) Dump (erzeugt mit tcpdump s.o.) so einer Session mal schicken?
Naja, für die gleiche Anfrage, sehe ich ein Paket von mehrere Zeile wenn ich die Anfrage auf dem Rechner mit dem Modem machen und von wenige Zeichen wenn die Anfrage von dem anderen Rechner kommt...
Wir sollten uns die Frage stellen, *warum* diese Pakete viel kleiner sind. Und vielleicht reichen kleinere Pakete ja auch schon für die beschriebene Verlangsamung - wenn ausreichend hohe Latenz da ist.
Genau! Ich kann leider die Frage "warum sind die Pakete viel kleiner" leider nicht beantworten...
Grüße Luca Bertoncello (lucabert@lucabert.de)
Luca Bertoncello schrieb:
Heiko Schlittermann hs@schlittermann.de schrieb:
Wir sollten uns die Frage stellen, *warum* diese Pakete viel kleiner sind. Und vielleicht reichen kleinere Pakete ja auch schon für die beschriebene Verlangsamung - wenn ausreichend hohe Latenz da ist.
Genau! Ich kann leider die Frage "warum sind die Pakete viel kleiner" leider nicht beantworten...
Ich kenne das Problem eher andersherum, daß es vom Router geht, aber aus dem LAN nicht. Die Verkleinerung der MTU im pppoed (/etc/ppp/peers/dsl-provider: mtu <packetsize>) war der erste Schritt, das sollte bei dir schon ausreichen. Eine eth-MTU ist allgemein 1500, bei pppoe war die Grenze glaub ich bei 1394 oder noch niedriger. Das läßt sich mit einem Ping mit entsprechend großem Paketen austesten:
ping -s 1400 $ZIEL kann über pppoe nicht mehr gehen, dann langsam die Paketgrößen reduzieren bis es geht. So kannst du zuerst mit einem gut funktionierenden Ziel die Grenze der eigenen DSL-Leitung austesten und dann das Nadelöhr auf dem Weg zur Problemseite finden, zumindest die Größe davon.
Wo sich das Nadelöhr befindet findest du evtl. mit
traceroute [-I] $ZIEL <paketsize>
heraus. Allerdings nur, wenn alle Hosts auf dem Weg antworten. Da die Sparkassenseite aber nicht auf ein Ping reagiert, ist das auf dem Wege schlecht auszuloten.
Daß die Clientpakete schon kleiner sind, liegt wohl an der MTU-Einstellung des Clients.
Falls das nicht reicht kann noch ein
iptables -A FORWARD -p TCP --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
weiterhelfen. Die Sparkassenseite war übrigens schon immer eine Problemseite bei Paketgrößen und daher auch gut als Testseite zu "mißbrauchen". ;-)
Gruß Rico
Hi,
ich hab noch paar ¢ zum Thema...
Rico Koerner schrieb:
Luca Bertoncello schrieb:
Heiko Schlittermann hs@schlittermann.de schrieb:
[...]
Eine eth-MTU ist allgemein 1500, bei pppoe war die Grenze glaub ich bei 1394 oder noch niedriger.
1500 Bytes ist die Standard-MTU, die auf Ethernet devices voreingestellt ist.
1492 ist die MTU ueber eine PPPOE Verbindung. Da ist 8 Bytes PPPOE Header abgezogen. Wenn es damit noch Problem gibt, dann kann man das auch auf 1452 stellen. [...]
Wo sich das Nadelöhr befindet findest du evtl. mit
traceroute [-I] $ZIEL <paketsize>
Tracepath zeigt IMHO auch die path-MTU an.
heraus. Allerdings nur, wenn alle Hosts auf dem Weg antworten. Da die Sparkassenseite aber nicht auf ein Ping reagiert, ist das auf dem Wege schlecht auszuloten.
[...]
iptables -A FORWARD -p TCP --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
Das sollte auf jeden fall helfen. Wenns nicht tut dann ist da sicher noch ein anderes Problem.
weiterhelfen. Die Sparkassenseite war übrigens schon immer eine Problemseite bei Paketgrößen und daher auch gut als Testseite zu "mißbrauchen". ;-)
Gruß Rico
MfG -Dimitri Puzin
Lug-dd maillist - Lug-dd@mailman.schlittermann.de https://ssl.schlittermann.de/mailman/listinfo/lug-dd
lug-dd@mailman.schlittermann.de
-
Christian Perle -
Dimitri Puzin -
Heiko Schlittermann -
Konrad Rosenbaum -
Luca Bertoncello -
Rico Koerner