Debian-Router: Surfen übers Netzwerk manchmal elend langsam

[Der Pumu]

Sodele, ich hab folgende Konfiguration:
WinXP-Rechner -> Debian-Router -> DSL-Modem

auf dem Debianrouter sind zwei Netzwerkkarten, eine ins interne Netzwerk (eth0), eine zum DSL-Modem(eth1).
Mein Problem: Manchmal (nicht immer) dauert das Laden von Webseiten auf dem Windoof-rechner ne kleine Ewigkeit bis hin zur Netscape-Meldung "document contains no data". Die Statusleiste zeigt dann immer "waiting for ...."
Das ist relativ willkürlich, es passiert auch, dass die eine Seite nicht lädt und gleichzeitig die andere ohne Probleme geladen wird. Woran könnte das liegen?
Ein anpingen der entsprechenden Server vom Windoofrechner aus tuts auch nicht, nichtmal vom debianrechner aus. (Und ja, andere Leute kommen zur selben Zeit problemlos dorthin)

Ich weiß momentan echt nicht weiter, ist halt manchmal ziemlich nervig, wäre also schön wenn mir jemand auf die Sprünge helfen könnte.

Grüße
Pumu

[Maikel]

Also wenn du sagst das es manchmal alles prima klappt und manchmal nicht gehe ich ja nicht von einem Konfigurationsproblem im Netzwerk aus.

Könnte es sein das deine DSL Leitung nicht so rund läuft?(kommt bei meiner T-DSL Leitung manchmal vor)
Oder ist der Router viell. so schwach auf der Brust das er überlastet ist?

[nepos]

Sind denn immer die gleichen Seiten betroffen und das jedes mal?
Oder nur sporadisch?

[Der Pumu]

Die gleichen Seiten, manche nur sehr sporadisch, ein oder zwei aber regelmäßig
top sagt mir 99,4% idle cpu und
Mem: 127164k total, 117428k used, 9736k free, 51748k buffers
Swap: 488368k total, 0k used, 488368k free, 24308k cached

[Maikel]

top sagt mir 99,4% idle cpu und

Ich glaube ja mal das das nicht iO ist.Was ist das denn für nen Rechner und was ist auf den Seiten das evtl. rechnerlastig sein könnte?

[nepos]

Die Geschichte mit der MTU hast du aber schon konfiguriert oder?

[Der Pumu]

top sagt mir 99,4% idle cpu und

Ich glaube ja mal das das nicht iO ist.Was ist das denn für nen Rechner und was ist auf den Seiten das evtl. rechnerlastig sein könnte?

Warum sollte das nicht iO sein wenn die CPU nix zu tun hat???
Der Router ist ein Pentium 400, der Windoof ein Athlon 1.333, und AFAIK ist anpingen nicht gerade rechnerlastig (wie ich oben geschrieben hab tuts selbst das nicht wenn die Seite nicht geladen wird)

Die Geschichte mit der MTU hast du aber schon konfiguriert oder?

ähm? wo kann ich nachschauen wies ist und wie sollte das sein?

/edit: in /etc/ppp/peers/dsl-provider steht was von

mtu 1492

[Maikel]

top sagt mir 99,4% idle cpu und

Ich glaube ja mal das das nicht iO ist.Was ist das denn für nen Rechner und was ist auf den Seiten das evtl. rechnerlastig sein könnte?

Sorry mein Fehler
Ich hab da gerade das "idle" falsch gewertet.
OK, ich weiß, das kann man eigentlich nicht falsch sehen

[nepos]

Aus der Manpage zu iptables:

TCPMSS
This target allows to alter the MSS value of TCP SYN packets, to control the maximum size for that connection (usually limiting it to
your outgoing interface's MTU minus 40). Of course, it can only be used in conjunction with -p tcp.
This target is used to overcome criminally braindead ISPs or servers which block ICMP Fragmentation Needed packets. The symptoms of
this problem are that everything works fine from your Linux firewall/router, but machines behind it can never exchange large packets:
1) Web browsers connect, then hang with no data received.
2) Small mail works fine, but large emails hang.
3) ssh works fine, but scp hangs after initial handshaking.
Workaround: activate this option and add a rule to your firewall configuration like:
iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN \
-j TCPMSS --clamp-mss-to-pmtu

--set-mss value
Explicitly set MSS option to specified value.

--clamp-mss-to-pmtu
Automatically clamp MSS value to (path_MTU - 40).

These options are mutually exclusive.

Versuch doch mal, die oben angegebene Regel reinzunehmen:

Code: Alles auswählen

ptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Bei mir zu Hause hat das gereicht.

[Der Pumu]

thx, ich werds mal versuchen... das Phänomen mit den Emails taucht bei mir auch ab und an auf

/edit: gebracht hats nix, einige Seiten laden nach wie vor nur nach gutem Zureden und die Emails lassen auch meisten zweimal bitten ehe sie sich auf den Weg machen...

[leipy]

Ich hatte dasselbe Problem immer dann, wenn ich statt einem Hardware-Router immer die Debian-Kiste als Router genommen hab.

Das Problem lag daran, dass ich Port 53 für DNS im IPTables-Skript nicht freigeschalten hatte.

Grüssle

Stefan

[nepos]

Das sollte man aber sehen - wenn man die gedroppten Pakete auch brav mitloggt.
Ach ja, wenn du die T-Online DNS-Server benutzt, da hatte ich ab und zu auch Probs, weil da einige recht lange fuer die Antworten brauchten.

[Der Pumu]

Das sollte man aber sehen - wenn man die gedroppten Pakete auch brav mitloggt.

Naja, ich bin absolut unwissender Neuling, deshalb hab ich keine Ahnung von Logs von gedroppten Paketen und kann das deshalb auch nicht sehen. Ich wer den 53 mal freischalten...

Ach ja, wenn du die T-Online DNS-Server benutzt, da hatte ich ab und zu auch Probs, weil da einige recht lange fuer die Antworten brauchten.

Da ich nicht T-Online benutze und hoffe, dass Hansenet andere DNS-Server benutzt kanns eigentlich nicht daran liegen...

/edit: ganz blöde frage: den Port für INPUT freischalten oder wie? :/

[nepos]

Raus musst du ja auch

[Der Pumu]

aalso, ich hab jettz folgendes alles drinstehen:

Code: Alles auswählen

## Flush tables and set default policy
$IPTABLES -t filter -F INPUT
$IPTABLES -t filter -F OUTPUT
$IPTABLES -t filter -F FORWARD
$IPTABLES -t filter -P INPUT ACCEPT
$IPTABLES -t filter -P OUTPUT ACCEPT
$IPTABLES -t filter -P FORWARD ACCEPT

## Masquerading
$IPTABLES -t nat -F POSTROUTING
$IPTABLES -t nat -A POSTROUTING -o $EXTDEV -s $INTLAN -j MASQUERADE

## Allow all on localhost
$IPTABLES -t filter -A INPUT -i lo -s 0/0 -d 0/0 -j ACCEPT

## Define ports that should be open
$IPTABLES -t filter -A INPUT -i $EXTDEV -p tcp --dport 21 --syn -j ACCEPT
$IPTABLES -t filter -A INPUT -i $EXTDEV -p tcp --dport 53 --syn -j ACCEPT
$IPTABLES -t filter -A INPUT -i $EXTDEV -p tcp --dport 113 --syn -j ACCEPT
$IPTABLES -t filter -A INPUT -i $EXTDEV -p tcp --dport 7771 --syn -j ACCEPT
$IPTABLES -t filter -A INPUT -i $EXTDEV -p tcp --dport 443 --syn -j ACCEPT
$IPTABLES -t filter -A INPUT -i $EXTDEV -p tcp --dport 80 --syn -j ACCEPT
$IPTABLES -t filter -A INPUT -i $EXTDEV -p tcp --dport 22 --syn -j ACCEPT
$IPTABLES -t filter -A INPUT -i $EXTDEV -p tcp --dport 31337 --syn -j ACCEPT
$IPTABLES -t filter -A INPUT -i $EXTDEV -p tcp --dport 14484 --syn -j ACCEPT
$IPTABLES -t filter -A INPUT -i $EXTDEV -p tcp --dport 8000 --syn -j ACCEPT
$IPTABLES -t filter -A INPUT -i $EXTDEV -p udp --dport 47624 -j ACCEPT
$IPTABLES -t filter -A INPUT -i $EXTDEV -p tcp --dport 7770 -j ACCEPT

## Close all other ports
$IPTABLES -t filter -A INPUT -i $EXTDEV -p tcp -s 0/0 -d 0/0 --dport 1:1024 --syn -j REJECT
$IPTABLES -t filter -A INPUT -i $EXTDEV -p tcp -s 0/0 -d 0/0 --dport 901 --syn -j REJECT
$IPTABLES -t filter -A INPUT -i $EXTDEV -p tcp -s 0/0 -d 0/0 --dport 139 --syn -j REJECT

## Portforwarding
# Edonkey/Overnet:
iptables -t nat -A PREROUTING -i $EXTDEV -p tcp --dport 4662 -j DNAT --to-dest 192.168.178.201
iptables -t nat -A PREROUTING -i $EXTDEV -p udp --dport 4672 -j DNAT --to-dest 192.168.178.201

## clamp mss to pmtu to forward large packets
iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

OUTPUT und FORWARD sind ja generell offen, da kann also eigentlich kein problem sein, oder?

[eagle]

Du solltest mal sicherstellen, dass die eingetragenen DNS Adressen auch richtig sind.

Macht der Rechenr eine Namensauflösung, dann fragt er bei dem ersten nameserver Eintrag in der /etc/resolv.conf nach. Antwortet der DNS nicht nach einer bestimmten Zeit so wird beim zweiten Eintrag nachfragt. Dieses Verhalten führt zu einer lahmen Internetverbindung.

eagle

[Der Pumu]

Die DNS-Adressen stimmen. Ich bezweifle auch dass es was mit den DNS-servern zu tun hat, denn die Statusmeldungen von netscape sind relativ ausführlich und das resolv geht fix über die Bühne, einige Dnge danach auch, und dann kommt das "waiting for..."

und wie schon oben gesagt, ist in den fällen auch vom router aus mit einem simplen ping nix zu machen:
PING d2.world-of-dungeons.de (81.169.172.184) 56(84) bytes of data.
und er wartet ne Ewigkeit...

[Der Pumu]

hat keiner n Tip woran es noch liegen könnte?