Hallo, ich habe ein etwas undurchsichtiges Problem mit meinem Linux-Rechner, der als Proxy (Squid) für 2 Windows-Clients dient: Unter 8.0 lief alles zur Zufriedenheit ohne Störungen wochenlang. Jetzt habe ich vor 5 Tagen 8.1 als Neuinstallation aufgespielt, die alten *.conf-Dateien zurückgeschrieben und gedacht, daß es wieder so problemlos laufen würde. Das war aber wohl sehr blauäugig gedacht: 1) irgendein Programm wählt sich dauernd ins Internet ein und ich kann nicht rausbekommen, welches, da unter /var/log/messages außer 'pppd [30322] starting link' und den üblichen Meldungen beim Verbindungsaufbau nichts relevantes auftaucht. 2) kann ich die Linuxmaschine nur eingeschränkt als Proxy für die Windows 98-Clients verwenden. HTTP und HTTPS funktioniert, DaOC und ICQ kommen auch ins Netz. Aber beide eMail-Programme (Virtual Access und Eudora) bekommen keine Verbindung, genausowenig Ultima Online. Auch hier kann ich nicht erkennen, warum sie abgeblockt werden - oder ich habe ein relevantes Log-File übersehen. Der eingerichtete Nameserver ist ok, ich kann per Ping Hostnamen innerhalb der eigenen Netzes sowie im Internet auflösen, daran kann es also nicht liegen. und die acl-Regeln sollten so eigentlich auch in Ordnung sein - es sei denn, daß die mit 8.1 mitgelieferte Squid-Version deutlich anders zu konfigurieren ist. Hier der acl-Teil aus der squid.conf: ------------- schnipp ------------------ acl all src 0.0.0.0/0.0.0.0 acl manager proto cache_object acl localhost src 127.0.0.1/255.255.255.255 acl Helloworld src 192.168.55.1-192.168.55.100 # .eml-Dateien ausfiltern (Nimda-Wurm-Dateien ausfiltern) acl worm urlpath_regex -i \.eml$ acl SSL_ports port 443 563 acl Safe_ports port 80 # http acl Safe_ports port 21 # ftp acl Safe_ports port 443 563 # https, snews acl Safe_ports port 70 # gopher acl Safe_ports port 110 # POP3, test, eingefuegt (23.11.2002) acl Safe_ports port 210 # wais acl Safe_ports port 1025-65535 # unregistered ports acl Safe_ports port 280 # http-mgmt acl Safe_ports port 488 # gss-http acl Safe_ports port 591 # filemaker acl Safe_ports port 777 # multiling http acl Safe_ports port 901 # swat (konfigurierung von samba) acl CONNECT method CONNECT # Only allow cachemgr access from localhost http_access allow manager localhost http_access deny manager # Deny requests to unknown ports http_access deny !Safe_ports # Deny CONNECT to other than SSL ports http_access deny CONNECT !SSL_ports # And finally deny all other access to this proxy http_access allow localhost http_access deny worm http_access allow Helloworld Safe_ports icp_access allow Helloworld http_access deny all ---------- schnapp ------------------ Falls einer der Gurus noch einen Tip parat hätte, wo und wie ich da noch an was drehen könnte, wäre ich dankbar :-) MfG R. Montag
Hy, Am 02/11/23@17:59 schrieb R.Montag:
ich habe ein etwas undurchsichtiges Problem mit meinem Linux-Rechner, der als Proxy (Squid) für 2 Windows-Clients dient:
Unter 8.0 lief alles zur Zufriedenheit ohne Störungen wochenlang. Jetzt habe ich vor 5 Tagen 8.1 als Neuinstallation aufgespielt, die alten *.conf-Dateien zurückgeschrieben und gedacht, daß es wieder so problemlos laufen würde.
Kenne weder 8.0 noch 8.1 :(
Das war aber wohl sehr blauäugig gedacht:
1) irgendein Programm wählt sich dauernd ins Internet ein und ich kann nicht rausbekommen, welches, da unter /var/log/messages außer 'pppd [30322] starting link' und den üblichen Meldungen beim Verbindungsaufbau nichts relevantes auftaucht.
Vielleicht helfen lsof -i und netstat -tulpen bei der Suche. Ansonsten schau Dir die Standardverdaechtigen an: http://www.toetsch.at/de/tips/linux/99/33.htm
2) kann ich die Linuxmaschine nur eingeschränkt als Proxy für die Windows 98-Clients verwenden. HTTP und HTTPS funktioniert,
Also funktioniert squid.
DaOC und ICQ kommen auch ins Netz.
DaOC kenne ich nicht, von icq weiss ich nur das es ueber udp laeuft. Aber beides wird IMHO nicht von squid bedient, so dass ich tippen wuerde...
Aber beide eMail-Programme (Virtual Access und Eudora) bekommen keine Verbindung, genausowenig Ultima Online.
... das vielleicht etwas mit dem Zugang nicht stimmt, wenn Du DSL nutzen wuerdest, wuerde ich vielleicht auf eine zu grosse mtu tippen, aber Du hast ja auch nicht gesagt wie Du ins Netz gehst :( Falls alles nichts hilft wuerde ich versuchen einen Paketfelter zu basteln, der alles blockt und logt. Da sollte man mehr sehen koennen. Ich kenne leider nichts von der iptables syntax, aber das sollte nicht alzu schwierig sein. Ich glaube zwar nicht, dass routing Dein Problem ist, aber wenn Du derartiges vermutest solltest Du IMHO route -n hier posten. -- bye maik
Hallo Maik!
Vielleicht helfen lsof -i und netstat -tulpen bei der Suche. Ansonsten schau Dir die Standardverdaechtigen an:
Ok, werde ich dann mal damit weitermachen :-)
Also funktioniert squid.
Korrekt
DaOC kenne ich nicht, von icq weiss ich nur das es ueber udp laeuft. Aber beides wird IMHO nicht von squid bedient, so dass ich tippen wuerde...
Aber beide eMail-Programme (Virtual Access und Eudora) bekommen keine Verbindung, genausowenig Ultima Online.
... das vielleicht etwas mit dem Zugang nicht stimmt, wenn Du DSL nutzen wuerdest, wuerde ich vielleicht auf eine zu grosse mtu tippen, aber Du hast ja auch nicht gesagt wie Du ins Netz gehst :(
Ist DSL - richtig vermutet ;-) - aber die MTU ist schon abgescheckt. Daran liegt es nicht.
Falls alles nichts hilft wuerde ich versuchen einen Paketfelter zu basteln, der alles blockt und logt. Da sollte man mehr sehen koennen. Ich kenne leider nichts von der iptables syntax, aber das sollte nicht alzu schwierig sein.
So ein Paketfilter hatte ich mir schon gebastelt - da ich aber ansonsten von Scripts keine Ahnung habe <schäm>, weiß ich nicht genau, wie ich das Teil 'zum laufen' bringe :-((
Ich glaube zwar nicht, dass routing Dein Problem ist, aber wenn Du derartiges vermutest solltest Du IMHO route -n hier posten.
Ich weiß es nicht, ob es am routing liegt - stochere da inzwischen wie ein Blinder im Nebel - aber Deinem Vorschlag entsprechend hier das Ergebnis von 'route -n': --------------- schnipp--------------- Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.55.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 0.0.0.0 192.168.55.70 0.0.0.0 UG 0 0 0 eth0 --------------- schnapp -------------- Dieses Ergebnis finde ich 'very strange', denn die Einträge in routes sehen so aus: --------------- routes anfang ------------------------- 192.168.55.70 127.0.0.1 255.255.255.0 eth0 192.168.55.70 192.168.55.70 255.255.255.0 eth0 default 192.168.55.70 --------------- routes ende --------------------------- Dann sind mir jetzt folgende Fehlermeldungen aufgefallen, die bei 'rcnetwortk restart' ausgegeben wurden, leider kann ich damit nur erkennen, daß was faul zu sein scheint und nicht wieso: ------------- errormeldungen rcnetwork restart anfang ----------- Shutting down network interfaces: dsl0 done eth0 ifdown-route: Error while excuting: ifdown-route: Command 'ip route del to 192.168.55.70/24 via 192.168.55.70 dev eth0' returned: ifdown-route: RTNETLINK answers: Invalid argument ifdown-route: Configuration line: 192.168.55.70 192.168.55.70 255.255.255.0 eth0 ifdown-route: Error while excuting: ifdown-route: Command 'ip route del to 192.168.55.70/24 via 127.0.0.1 dev eth0' returned: ifdown-route: RTNETLINK answers: Invalid argument ifdown-route: Configuration line: 192.168.55.70 127.0.0.1 255.255.255.0 eth0 done Setting up network interfaces: lo done eth0 IP/Netmask: 192.168.55.70 / 255.255.255.0 ifup-route: Error while excuting: ifup-route: Command 'ip route replace to 192.168.55.70/24 via 127.0.0.1 dev eth0' returned: ifup-route: RTNETLINK answers: Invalid argument ifup-route: Configuration line: 192.168.55.70 127.0.0.1 255.255.255.0 eth0 ifup-route: Error while excuting: ifup-route: Command 'ip route replace to 192.168.55.70/24 via 192.168.55.70 dev eth0' returned: ifup-route: RTNETLINK answers: Invalid argument ifup-route: Configuration line: 192.168.55.70 192.168.55.70 255.255.255.0 eth0 done dsl0 done ------------- errormeldungen rcnetwork restart ende ----------- Sorry für den blöden Umbruch der Meldungen, aber leider hält sich Linux da nicht an die Mailinglisten-Konvention ;-)) Noch irgendeine Idee, wo ich nachhaken kann? MfG R. Montag
Hy, Am 02/11/24@11:15 schrieb R.Montag:
--------------- schnipp---------------
Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.55.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 0.0.0.0 192.168.55.70 0.0.0.0 UG 0 0 0 eth0
--------------- schnapp --------------
*Hm*, sehr merkwuerdig. Ich nehme mal an, dass 192.168.55.0/24 Dein LAN ist. Dann Duerft eigentlich gar nix gehen, denn die default route sollte auf Dein eth(dsl) zeigen. Ich haette so was erwartet: 192.168.55.0 0.0.0.0 255.255.255.0 eth0 [LAN] 192.168.1.1 0.0.0.0 255.255.255.255 eth1 [DSL] 0.0.0.0 192.168.1.1 0.0.0.0 eth1 [default] Jedenfalls sowlange Du offline bist. Sobald Du eingewaehlt bist sollte die 192.168.1.1 (nur ein Beispiel[1]) durch die zugewiesene dynIP ueberschrieben werden.
Dieses Ergebnis finde ich 'very strange', denn die Einträge in routes sehen so aus:
Me2.
--------------- routes anfang -------------------------
192.168.55.70 127.0.0.1 255.255.255.0 eth0 192.168.55.70 192.168.55.70 255.255.255.0 eth0 default 192.168.55.70
--------------- routes ende ---------------------------
Hoppala ;). Ich kenne zwar keine routes Datei, heisst bei mir /etc/route.conf (7.1). Aber wenn die Syntax in dieser routes Datei auch nur annhaehernd der der route.conf aehnlelt ist das dort oben Bloedsinn: Die Eintraege in der route.conf haben folgenden Aufbau: Netz Gateway Subnetmask Device Falls das auf die routes auch zutrifft heisst z.B. Dein erster Eintrag: Das Netz 192.168.55.70 verwendet das Gateway 127.0.0.1 die Subnetmask ist 255.255.255.0 zu erreichen ist das Netz ueber eth0. Das ist Bloedsinn. Wenn es Dein LAN-Server ist und 192.168.55/24 Dein Class C LAN, dann wird das nicht ueber ein Gateway erreicht schon gar nicht ueber das Gateway (127.0.0.1 = localhost). Die Subnetmask 255.255.255.0 passt nicht zur Netzwerkadress 192.168.55.70. Wie auch immer korrekt waere zum Beispiel folgendes: LAN: 192.168.55.0 0.0.0.0 255.255.255.0 eth0 Dein LAN ist ein Class C (Netmask 255.255.255.0) und braucht kein Gateway. Deine Windowsclients brauchen dann auch IP's aus dem Bereich 192.168.55.1-192.168.55.254. DSL: 192.168.1.1 0.0.0.0 255.255.255.255 eth1 Dummy Adresse 192.168.1.1 (ein host = 255.255.255.255). Wird bei der Einwahl ueberschrieben. DEFAULT: default 192.168.1.1 0.0.0.0 eth1 Alle nicht von vorherigen routen abgedeckten Packet bitte an eth1 schicken. Bei der Einwahl wird die dummy Adresse ueberschrieben und die Pakete finden Ihren Weg in die Untiefen des Netz. [Fehlermeldungen] Das sind IMHO Folgen der falschen routing Eintraege. [1] Ich kenne dsl nicht wirklich, aber IIRC benutzt zumindest telekom dsl einen privaten IP Bereich fuer interne Zwecke, nur 192.168.1/24 war es AFAIK nicht. -- bye maik
Hallo Mike!
Wie auch immer korrekt waere zum Beispiel folgendes:
Habe Deinen Vorschlägen entsprechend die Datei 'routes' geändert. Jetzt kommen die Fehlermeldungen bei 'rcnetwork restart' nicht mehr <freu> - dafür geht aber *nur* noch HTTP und IQC. DaOC (ein Online-Spiel) ist jetzt auch abgeklemmt. Irgendwas muß ich übersehen, was sich bei der Versionsänderung 8.0 auf 8.1 und den daraus resultierenden neuen Versionen von Squid, Netzwerk und Konsorten innerhalb der Konfigurationen (und sei es auch nur eine conf-Datei) geändert hat :-(( Langsam überlege ich, ob es Sinn machen würde, alles platt zu machen und noch einmal von Null anzufangen.... MfG R. Montag
Hy, Am 02/11/24@14:14 schrieb R.Montag:
Hallo Mike!
Wie auch immer korrekt waere zum Beispiel folgendes:
Habe Deinen Vorschlägen entsprechend die Datei 'routes' geändert. Jetzt kommen die Fehlermeldungen bei 'rcnetwork restart' nicht mehr <freu> - dafür geht aber *nur* noch HTTP und IQC. DaOC (ein Online-Spiel) ist jetzt auch abgeklemmt.
Irgendwas muß ich übersehen, was sich bei der Versionsänderung 8.0 auf 8.1 und den daraus resultierenden neuen Versionen von Squid, Netzwerk und Konsorten innerhalb der Konfigurationen (und sei es auch nur eine conf-Datei) geändert hat :-((
Das squid icq kann, glaube ich erstmal nicht. Das muss einen anderen Weg finden. Laeuft ein Paketfilter (iptables -vL)? Eigentlich duerfte auch icq nicht ohne masquerading auskommen aber vielleicht pruefst Du das auch nochmal.
Langsam überlege ich, ob es Sinn machen würde, alles platt zu machen und noch einmal von Null anzufangen....
Das glaube ich nicht. Such nach der Syntax fuer ein einfaches loggen aller Pakete mit iptables. Das muesste sich finden lassen. Ansonsten schau mit tcpdump, was da wirklich an Paketen laeuft, wenn Du Dein online Spiel startest. Sorry, aber bei der letzten Bemerkung konnte ich mir das Wuehlen im sig Archiv nicht verkneifen ;). --
... bin ratlos sehe einer kompletten Neuinstallation gefasst entgegen. Das ist nicht WINTENDO wo das hilft. [Christoph Noelle & Leopold Toetsch auf suse-isdn]
Hallo Maik
Das squid icq kann, glaube ich erstmal nicht. Das muss einen anderen Weg finden. Laeuft ein Paketfilter (iptables -vL)?
Nein, habe ich erst einmal abgeklemmt, um zumindest dies als Fehlerquelle auszuschalten....
Langsam überlege ich, ob es Sinn machen würde, alles platt zu machen und noch einmal von Null anzufangen....
Das glaube ich nicht. Such nach der Syntax fuer ein einfaches loggen aller Pakete mit iptables. Das muesste sich finden lassen.
Ok, dann werde ich vorerst mal weiter auf fehlersuche gehen ;-)
Ansonsten schau mit tcpdump, was da wirklich an Paketen laeuft, wenn Du Dein online Spiel startest.
Hier der Anfang vom tcpdump-Protokoll eines Einwahlversuches durch einen Mailclient (Virtual Access) auf dem Windows-Rechner (die ganzen 12 KB bis zum Abbruch will ich allen ersparen), vielleicht kannst Du da mehr draus ersehen als ich: -------------------- tcpdump ausschnitt anfang ---------------------- 15:54:27.797861 arp who-has kruemel.hallowelt.de tell Junior.hallowelt.de 15:54:27.798005 arp reply kruemel.hallowelt.de is-at 0:20:af:f9:20:bf 15:54:27.798229 Junior.hallowelt.de.aas > kruemel.hallowelt.de.domain: 1+ A? mail.helloworld.de. (36) 15:54:27.801032 kruemel.hallowelt.de.domain > Junior.hallowelt.de.aas: 1 2/2/2 CNAME helloworld.de., (147) (DF) 15:54:27.801730 Junior.hallowelt.de.issd > helloworld.de.pop3: S 84184396:84184396(0) win 32767 <mss 1460,nop,nop,sackOK> (DF) 15:54:27.801798 PPPoE [ses 0x13f9] Junior.hallowelt.de.issd > helloworld.de.pop3: S 84184396:84184396(0) win 32767 <mss 1460,nop,nop,sackOK> (DF) 15:54:30.797119 Junior.hallowelt.de.issd > helloworld.de.pop3: S 84184396:84184396(0) win 32767 <mss 1460,nop,nop,sackOK> (DF) 15:54:30.797208 PPPoE [ses 0x13f9] Junior.hallowelt.de.issd > helloworld.de.pop3: S 84184396:84184396(0) win 32767 <mss 1460,nop,nop,sackOK> (DF) 15:54:32.798706 arp who-has Junior.hallowelt.de tell kruemel.hallowelt.de 15:54:32.798974 arp reply Junior.hallowelt.de is-at 0:1:3:34:96:9c 15:54:33.508732 PPPoE [ses 0x13f9] Echo-Req(6), Magic-Num=83e45ae3 15:54:33.562879 PPPoE [ses 0x13f9] Echo-Rep(6), Magic-Num=08a7889a 15:54:36.795826 Junior.hallowelt.de.issd > helloworld.de.pop3: S 84184396:84184396(0) win 32767 <mss 1460,nop,nop,sackOK> (DF) 15:54:36.795914 PPPoE [ses 0x13f9] Junior.hallowelt.de.issd > helloworld.de.pop3: S 84184396:84184396(0) win 32767 <mss 1460,nop,nop,sackOK> (DF) 15:54:40.114481 PPPoE [ses 0x13f9] pD953B8BA.dip.t-dialin.net.pdnet > p5081FD0D.dip.t-dialin.net.4662: S 4229884977:4229884977(0) win 32767 <mss 1452,nop,wscale 0,nop,nop,sackOK> (DF) 15:54:40.114621 PPPoE [ses 0x13f9] p5081FD0D.dip.t-dialin.net.4662 > pD953B8BA.dip.t-dialin.net.pdnet: R 0:0(0) ack 4229884978 win 0 (DF) 15:54:40.803487 PPPoE [ses 0x13f9] pD953B8BA.dip.t-dialin.net.pdnet > p5081FD0D.dip.t-dialin.net.4662: S 4229884977:4229884977(0) win 32767 <mss 1452,nop,wscale 0,nop,nop,sackOK> (DF) 15:54:40.803612 PPPoE [ses 0x13f9] p5081FD0D.dip.t-dialin.net.4662 > pD953B8BA.dip.t-dialin.net.pdnet: R 0:0(0) ack 1 win 0 (DF) 15:54:41.426134 PPPoE [ses 0x13f9] pD953B8BA.dip.t-dialin.net.pdnet > p5081FD0D.dip.t-dialin.net.4662: S 4229884977:4229884977(0) win 32767 <mss 1452,nop,wscale 0,nop,nop,sackOK> (DF) 15:54:41.426249 PPPoE [ses 0x13f9] p5081FD0D.dip.t-dialin.net.4662 > pD953B8BA.dip.t-dialin.net.pdnet: R 0:0(0) ack 1 win 0 (DF) 15:54:48.633477 Junior.hallowelt.de.netbios-dgm > 192.168.100.255.netbios-dgm: NBT UDP PACKET(138) 15:54:48.793144 Junior.hallowelt.de.issd > helloworld.de.pop3: S 84184396:84184396(0) win 32767 <mss 1460,nop,nop,sackOK> (DF) 15:54:48.793221 PPPoE [ses 0x13f9] Junior.hallowelt.de.issd > helloworld.de.pop3: S 84184396:84184396(0) win 32767 <mss 1460,nop,nop,sackOK> (DF) 15:55:03.518971 PPPoE [ses 0x13f9] Echo-Req(7), Magic-Num=83e45ae3 15:55:03.576188 PPPoE [ses 0x13f9] Echo-Rep(7), Magic-Num=08a7889a 15:55:33.528958 PPPoE [ses 0x13f9] Echo-Req(8), Magic-Num=83e45ae3 15:55:33.583310 PPPoE [ses 0x13f9] Echo-Rep(8), Magic-Num=08a7889a 15:56:03.538915 PPPoE [ses 0x13f9] Echo-Req(9), Magic-Num=83e45ae3 15:56:03.592908 PPPoE [ses 0x13f9] Echo-Rep(9), Magic-Num=08a7889a 15:56:17.238965 PPPoE [ses 0x13f9] 213.213.203.48.lmsocialserver > p5081FD0D.dip.t-dialin.net.4662: S 739198373:739198373(0) win 16384 <mss 1460,nop,nop,sackOK> (DF) 15:56:17.239197 PPPoE [ses 0x13f9] p5081FD0D.dip.t-dialin.net.4662 > 213.213.203.48.lmsocialserver: R 0:0(0) ack 739198374 win 0 (DF) 15:56:17.247882 PPPoE [ses 0x13f9] p5081FD0D.dip.t-dialin.net.domain > dns03.btx.dtag.de.domain: 10542+ PTR? 48.203.213.213.in-addr.arpa. (45) (DF) 15:56:17.325404 PPPoE [ses 0x13f9] dns03.btx.dtag.de.domain > p5081FD0D.dip.t-dialin.net.domain: 10542 NXDomain 0/1/0 (100) (DF) --------------------- tcpdump ausschnitt ende -------------------------
Sorry, aber bei der letzten Bemerkung konnte ich mir das Wuehlen im sig Archiv nicht verkneifen ;).
--
... bin ratlos sehe einer kompletten Neuinstallation gefasst entgegen. Das ist nicht WINTENDO wo das hilft. [...] --
Diese Aussage ist zwar prinzipiell richtig - aber auch Linux hat noch den einen oder anderen klitzekleinen Fehler oder macht klitzekleine Probleme <bg> MfG R. Montag
* Sonntag, 24. November 2002 um 16:16 (+0100) schrieb R.Montag:
-------------------- tcpdump ausschnitt anfang ---------------------- [ ... ] 15:54:27.798229 Junior.hallowelt.de.aas > kruemel.hallowelt.de.domain: 1+ A? mail.helloworld.de. (36) 15:54:27.801032 kruemel.hallowelt.de.domain > Junior.hallowelt.de.aas: 1 2/2/2 CNAME helloworld.de., (147) (DF) 15:54:27.801730 Junior.hallowelt.de.issd > helloworld.de.pop3: S 84184396:84184396(0) win 32767 <mss 1460,nop,nop,sackOK> (DF) 15:54:27.801798 PPPoE [ses 0x13f9] Junior.hallowelt.de.issd > helloworld.de.pop3: S 84184396:84184396(0) win 32767 <mss 1460,nop,nop,sackOK> (DF)
IMHO hast du doch noch das altbekannte "MTU-Problem". Gruß Andreas -- Andreas Könecke "Andreas Koenecke <akoenecke@akoenecke.de>" PGP-ID/Fingerprint: BD7C2E59/3E 11 E5 29 0C A8 2F 49 40 6C 2D 5F 12 9D E1 E3 PGP-Key on request or on public keyservers --
Hallo R. * Sonntag, 24. November 2002 um 19:35 (+0100) schrieb R.Montag:
Bin zwar der Meinung gewesen, daß die MTU auf 1492 eingestellt ist (wird so zumindest im Logfile angezeigt), aber kann mich natürlich auch irren.
Eine MTU von 1492 Bytes auf dem pppX-Device ist nur "die halbe Miete". Wenn der Rechner auch Clients masqueraded, muss er auch noch "MSS-Clamping" machen. (Oder als Notlösung kann auch die MTU auf *allen Clients* auf 1492 Bytes verringert werden.)
Woran erkennst Du das aus dem Protokoll <lernenwill> ?
15:54:27.801798 PPPoE [ses 0x13f9] Junior.hallowelt.de.issd > helloworld.de.pop3: S 84184396:84184396(0) win 32767 <mss 1460,nop,nop,sackOK> (DF)
Es kann sein, dass ich die Ausgabe von tcpdump misinterpretiere, aber obige Zeile läßt mich vermuten, dass kein MSS-Clamping gemacht wird. Gruß Andreas -- Andreas Könecke "Andreas Koenecke <akoenecke@akoenecke.de>" PGP-ID/Fingerprint: BD7C2E59/3E 11 E5 29 0C A8 2F 49 40 6C 2D 5F 12 9D E1 E3 PGP-Key on request or on public keyservers --
Hallo Andreas!
Wenn der Rechner auch Clients masqueraded, muss er auch noch "MSS-Clamping" machen.
Ups - das ist jetzt ein für mich ganz neues Thema...
Es kann sein, dass ich die Ausgabe von tcpdump misinterpretiere, aber obige Zeile läßt mich vermuten, dass kein MSS-Clamping gemacht wird.
Könnte durchaus sein, darum habe ich mich bisher nicht gekümmert (wie schon gesagt, hatte ich die Konfigurationen eines funktionierenden SuSE 8.0 übernommen) und ehrlich gesagt, wüßte ich auch nicht, wie ich das bewerkstelligen sollte, da Squid diese Möglichkeit anscheinend nicht bietet.... MfG R. Montag
* Sonntag, 24. November 2002 um 23:00 (+0100) schrieb R.Montag:
[ MSS-Clamping ]
Könnte durchaus sein, darum habe ich mich bisher nicht gekümmert (wie schon gesagt, hatte ich die Konfigurationen eines funktionierenden SuSE 8.0 übernommen) und ehrlich gesagt, wüßte ich auch nicht, wie ich das bewerkstelligen sollte, da Squid diese Möglichkeit anscheinend nicht bietet....
Wenn auf deinen Clients HTTP und FTP (per Browser) funktioniert, dann funktioniert auch 'squid' und du musst dich um dessen Konfiguration nicht weiter kümmern. Alle anderen Dienste müssen mit 'iptables' ge"NAT"et werden (Masquerading) und das PMTUD-"Problem" mit MSS-Clamping umgangen werden. Du musst also in deinem 'iptables'-Skript (u.a.) folgende Zeilen haben: # Masquerading Teil I echo "1" > /proc/sys/net/ipv4/ip_forward iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE # MSS-Clamping iptables -A FORWARD -p tcp -o ppp0 --tcp-flags SYN,RST SYN -j TCPMSS\ --clamp-mss-to-pmtu # *eine* Zeile # Masquerading Teil II iptables -A FORWARD -o ppp0 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT iptables -A FORWARD -i ppp0 -m state --state RELATED,ESTABLISHED -j ACCEPT (Vorsicht, obige Zeilen enthalten keine Paketfilterung (außer 'connection tracking').) Gruß Andreas -- Andreas Könecke "Andreas Koenecke <akoenecke@akoenecke.de>" PGP-ID/Fingerprint: BD7C2E59/3E 11 E5 29 0C A8 2F 49 40 6C 2D 5F 12 9D E1 E3 PGP-Key on request or on public keyservers --
Hallo Andreas!
IMHO hast du doch noch das altbekannte "MTU-Problem".
Habe gerade noch einmal nachgesehen - in beiden von der SuSE-Supportdatenbank genannten Dateien sind MTU und MRU auf 1492 eingestellt. Deswegen dazu noch 2 Fragen: 1)wie kann ich auf dem Linux-Rechner testen, welche MTU tatsächlich läuft und 2) oder macht es eher Sinn, die MTU auf den Windows-Clients auf 1492 einzustellen (mit allen damit verbundenen Nachteilen)? MfG R. Montag
R.Montag wrote:
Habe gerade noch einmal nachgesehen - in beiden von der SuSE-Supportdatenbank genannten Dateien sind MTU und MRU auf 1492 eingestellt.
Deswegen dazu noch 2 Fragen:
1)wie kann ich auf dem Linux-Rechner testen, welche MTU tatsächlich läuft und
ifconfig ist hier Dein Freund. Dort wird Dir die MTU angezeigt. Um zu testen, ob die MTU auch vernünftig ist, kannst Du mit ping einfach Testpakete von verschiedener Größe schicken. Wenn das Testpaket nicht durchkommt, ist die MTU zu groß. Eine MTU von 1492 ist bei DSL normalerweise in Ordnung, aber probiere es einfach aus. ping -c 2 -M do -s 1492 www.xyz.de -c 2 -- Anzahl der Pakete, die geschickt werden sollen (hier 2) -M do -- nicht fragmentieren (sonst gehen die Pakete immer durch und wir wollen ja die größtmögliche Größe wissen -s 1492 -- Paketgröße (hier ist rantasten erforderlich)
2) oder macht es eher Sinn, die MTU auf den Windows-Clients auf 1492 einzustellen (mit allen damit verbundenen Nachteilen)?
Welche Nachteile? Normalerweise braucht man auf den Clients die MTU nicht einstellen. Bei Ethernet ist eine MTU von 1500 in Ordnung. Der Router setzt dann die Datenpakete richtig um, wenn dort eine andere MTU angegeben ist. Gruß, Martin Grabbel
allo Martin!
ifconfig ist hier Dein Freund. Dort wird Dir die MTU angezeigt.
Stimmt auffallend :-))
Um zu testen, ob die MTU auch vernünftig ist, kannst Du mit ping einfach Testpakete von verschiedener Größe schicken. Wenn das Testpaket nicht durchkommt, ist die MTU zu groß. Eine MTU von 1492 ist bei DSL normalerweise in Ordnung, aber probiere es einfach aus.
ping -c 2 -M do -s 1492 www.xyz.de
Danke, war ein guter Tip - ein Wert von 1464 war dann richtig, ohne zu große Pakete zu bekommen.
2) oder macht es eher Sinn, die MTU auf den Windows-Clients auf 1492 einzustellen (mit allen damit verbundenen Nachteilen)?
Welche Nachteile?
Das dann ein gewisser Overhead für Netzverkehr die Übertragung etwas verlangsamt....
Normalerweise braucht man auf den Clients die MTU nicht einstellen.
Davon bin ich auch ausgegangen
Bei Ethernet ist eine MTU von 1500 in Ordnung. Der Router setzt dann die Datenpakete richtig um, wenn dort eine andere MTU angegeben ist.
Und hier habe ich jetzt ein neues Problem: ich schaffe es nicht, dauerhaft einen Wert von 1464 zu bekommen. Ich habe unter /etc/ppp/options und /etc/ppp/pppoe (nach SuSE-Vorgabe) jeweils diesen Wert eingetragen, aber nach einem 'rcnetwork restart' oder einem Neustart des Rechners wird wieder eine MTU von 1492 verwendet :-( Es scheint, daß dieser Wert noch irgendwo 'eingearbeitet' ist, ich fürchte sogar hardcodiert im Kernel :-( MfG R. Montag
* Sonntag, 24. November 2002 um 23:00 (+0100) schrieb R.Montag:
ping -c 2 -M do -s 1492 www.xyz.de
Danke, war ein guter Tip - ein Wert von 1464 war dann richtig, ohne zu große Pakete zu bekommen.
Das ist auch so in Ordnung.
Und hier habe ich jetzt ein neues Problem: ich schaffe es nicht, dauerhaft einen Wert von 1464 zu bekommen. Ich habe unter /etc/ppp/options und /etc/ppp/pppoe (nach SuSE-Vorgabe) jeweils diesen Wert eingetragen, aber nach einem 'rcnetwork restart' oder einem Neustart des Rechners wird wieder eine MTU von 1492 verwendet :-(
Zum Glück! Spiele jetzt bloss nicht an der MTU des Routers herum, sonst wird das Chaos (unter Umständen) komplett. Eine MTU von 1492 Bytes ist für PPPoE absolut richtig. (Das zeigt auch dein gemessener Wert von 1464 Bytes beim ping: 1464 Bytes Daten + 8 Bytes ICMP-Header + 20 Bytes IP-Header = 1492 Bytes = MTU)
Es scheint, daß dieser Wert noch irgendwo 'eingearbeitet' ist, ich fürchte sogar hardcodiert im Kernel :-(
Nein, der wird beim Verbindungsaufbau ausgehandelt. Gruß Andreas -- Andreas Könecke "Andreas Koenecke <akoenecke@akoenecke.de>" PGP-ID/Fingerprint: BD7C2E59/3E 11 E5 29 0C A8 2F 49 40 6C 2D 5F 12 9D E1 E3 PGP-Key on request or on public keyservers --
On Sunday 24 November 2002 23:58, Andreas Koenecke wrote:
* Sonntag, 24. November 2002 um 23:00 (+0100) schrieb R.Montag:
ping -c 2 -M do -s 1492 www.xyz.de
Danke, war ein guter Tip - ein Wert von 1464 war dann richtig, ohne zu große Pakete zu bekommen.
Das ist auch so in Ordnung.
Und hier habe ich jetzt ein neues Problem: ich schaffe es nicht, dauerhaft einen Wert von 1464 zu bekommen. Ich habe unter /etc/ppp/options und /etc/ppp/pppoe (nach SuSE-Vorgabe) jeweils diesen Wert eingetragen, aber nach einem 'rcnetwork restart' oder einem Neustart des Rechners wird wieder eine MTU von 1492 verwendet :-(
Zum Glück! Spiele jetzt bloss nicht an der MTU des Routers herum, sonst wird das Chaos (unter Umständen) komplett. Eine MTU von 1492 Bytes ist für PPPoE absolut richtig. (Das zeigt auch dein gemessener Wert von 1464 Bytes beim ping: 1464 Bytes Daten + 8 Bytes ICMP-Header + 20 Bytes IP-Header = 1492 Bytes = MTU)
Apropos: Ich hab das dann gleich mal bei mir ausprobiert und bekomme auf meinem Router für Werte zwischen 1464 und 1492 folgende Meldung: Benutzer@Rechner:~ > ping -c 2 -s 1470 www.t-online.de PING www.t-online.de (62.153.159.124): 1470 data bytes 1472 bytes from 62.153.159.124: icmp_seq=0 ttl=123 time=159.149 ms wrong data byte #1464 should be 0xb8 but was 0x0 3d e1 f2 66 0 a 82 77 8 9 a b c d e f 10 11 12 13 14 15 16 17 18 19 1a 1 b 1c 1d 1e 1f 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f 40 41 42 43 44 45 46 47 48 49 4a 4b 4c 4d 4e 4f 50 51 52 53 54 55 56 57 58 59 5a 5b 5c 5d 5e 5f 60 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70 71 72 73 74 75 76 77 78 79 7a 7b 7c 7d 7e 7f 80 81 82 83 84 85 86 87 88 89 8a 8b 8c 8d 8e 8f 90 91 92 93 94 95 96 97 98 99 9a 9b 9c 9d 9e 9f a0 a1 a2 a3 a4 a5 a6 a7 a8 a9 aa ab ac ad ae af b0 b1 b2 b3 b4 b5 b6 b7 b8 b9 ba bb bc bd be bf c0 c1 c2 c3 c4 c5 c6 c7 c8 c9 ca cb cc cd ce cf d0 d1 d2 d3 d4 d5 d6 d7 d8 d9 da db dc dd de df ---cut--- geht noch weiter, aber ich schneid das hier mal ab. Funktioniert da was mit dem zerstückeln der Pakete nicht? Oder ist das sogar normal? Gruss Michael -- Der süsse Pinguin ist mir lieber als die kleinen weichen, die einem nur kaputte Fenster verkaufen
* Montag, 25. November 2002 um 11:04 (+0100) schrieb Michael Heide:
Apropos: Ich hab das dann gleich mal bei mir ausprobiert und bekomme auf meinem Router für Werte zwischen 1464 und 1492 folgende Meldung:
Benutzer@Rechner:~ > ping -c 2 -s 1470 www.t-online.de PING www.t-online.de (62.153.159.124): 1470 data bytes 1472 bytes from 62.153.159.124: icmp_seq=0 ttl=123 time=159.149 ms wrong data byte #1464 should be 0xb8 but was 0x0 3d e1 f2 66 0 a 82 77 8 9 a b c d e f 10 11 12 13 14 15 16 17 18 19 1a 1 [ ... ]
Funktioniert da was mit dem zerstückeln der Pakete nicht? Oder ist das sogar normal?
"Relativ normal" für DTAG/T-Online-Verhältnisse :-( Ich habe selber mal ein bisschen "rumgespielt": Je nachdem, welchen Server man gerade unter www.t-online.de erreicht, bekommt man entweder auf 1464 Bytes abgeschnittene ICMP-Pakete zurück (wwwX.sul.t-online.de) oder gar keine (wwwX.sda.t-online.de) als Antwort auf fragmentierte ICMP-Pakete. IMHO ungewöhnlich ist aber die Ausgabe "deines" pings. Bei "meinem" sieht das so aus: akoenecke@kocom:~> ping -c 1 -s 1465 62.153.159.124 PING 62.153.159.124 (62.153.159.124) from 80.134.34.212 : 1465(1493) bytes of data. 1472 bytes from 62.153.159.124: icmp_seq=1 ttl=123 (truncated) Es ist aber auch gut möglich, dass die ganze Problematik auch abhängig von den dazwischenliegenden Routern ist... (Ach wäre die DTAG doch bei BTX geblieben...) Probiere die "großen" pings doch mal mit anderen Hosts, z.B. www.heise.de. Gruß Andreas -- Andreas Könecke "Andreas Koenecke <akoenecke@akoenecke.de>" PGP-ID/Fingerprint: BD7C2E59/3E 11 E5 29 0C A8 2F 49 40 6C 2D 5F 12 9D E1 E3 PGP-Key on request or on public keyservers --
Hy, Am 02/11/24@16:16 schrieb R.Montag:
-------------------- tcpdump ausschnitt anfang ----------------------
15:54:27.797861 arp who-has kruemel.hallowelt.de tell Junior.hallowelt.de 15:54:27.798005 arp reply kruemel.hallowelt.de is-at 0:20:af:f9:20:bf 15:54:27.798229 Junior.hallowelt.de.aas > kruemel.hallowelt.de.domain: 1+ A? mail.helloworld.de. (36) 15:54:27.801032 kruemel.hallowelt.de.domain > Junior.hallowelt.de.aas: 1 2/2/2 CNAME helloworld.de., (147) (DF) 15:54:27.801730 Junior.hallowelt.de.issd > helloworld.de.pop3: S 84184396:84184396(0) win 32767 <mss 1460,nop,nop,sackOK> (DF)
Ich verstehe nicht warum diese Anfrage an helloworl.de:pop3 geht. IMHO muesste die an mail.helloworld.de:pop3 gehen. Du koenntest mal folgendes probieren, besorg Dir die IP des mailservers, den Du abfragen moechtest und trag diese in der Client config ein, nur um DNS Probleme, falls es welche gibt, auszuschliessen. Mit dem mtu und dsl spezifischen Kram kenne ich mich nicht aus, also solltest Du auch Andreas Hinweis verfolgen. -- bye maik
Hallo Maik!
Ich verstehe nicht warum diese Anfrage an helloworl.de:pop3 geht. IMHO muesste die an mail.helloworld.de:pop3 gehen.
Ja, hast Recht und ist auch so in der Konfiguration des Mail-Programmes eingetragen.
Du koenntest mal folgendes probieren, besorg Dir die IP des mailservers, den Du abfragen moechtest und trag diese in der Client config ein, nur um DNS Probleme, falls es welche gibt, auszuschliessen.
Gute Idee - kann ich aber leider erst morgen in Erfahrung bringen....
Mit dem mtu und dsl spezifischen Kram kenne ich mich nicht aus, also solltest Du auch Andreas Hinweis verfolgen.
Tu ich schon fleißig :-) Genauso, wie ich im Netz und bei SuSe zusätzliche Informationen zu bekommen versuche.... MfG R. Montag
participants (5)
-
Andreas Koenecke -
Maik Holtkamp -
Martin Grabbel -
Michael Heide -
R.Montag