Hallo!
Ich habe hier einen Suse7.0-Linux-Server mit ISDN-Dialup (dynamic IP)
und Apache also Proxyserver zum Internet. Die Internetverbindung
funktioniert auch einwandfrei, schnell und die Verbindung wird
automatisch hergestellt, allerdings gibt es einen kleinen
Schönheitsfehler:
Der erste http-Request, der von einem Client gesendet wird, braucht sehr
lange oder wird garnicht beantwortet.
Mit tcpdump kann man auch sehen, was passiert: Die ersten Pakete für die
Nameserveranfrage (cache0X.ns.de.uu.net) gehen noch mit der internen,
nichtöffentlichen IP-Adresse (w-d.ac.uunet.de). Nach einigen Sekunden
gehen dann Pakete mit der richtigen IP (pec-30-119.tnt4.me2.uunet.de)
raus, die dann auch direkt beantwortet werden. Allerdings sogar dann
dauert es noch einige Sekunden/Requests, bis dann die Übertragung
vielleicht mal losgeht.
Requests, die nach dem Aufbau der Verbindung abgeschickt werden, sind
innerhalb von Sekundenbruchteilen beantwortet.
Eigentlich würde ich erwarten, daß der aktive Dynamic-IP-Patch ("cat
/proc/sys/net/ipv4/ip_dynaddr" ergibt "7") die Adressen der wartenden
Pakete automatisch shiften würde, es erfolgt allerdings auch keine
ausgabe in /var/log/messages, wie ich es auch von früheren
Distributionen kenne.
Der Firewall, den ich installiert habe, hat keinen Einfluß auf dieses
Verhalten. Auch wenn man ihn abschaltet ergibt sich das gleiche
Ergebnis.
Hier noch die tcpdump-Ausgabe (Sorry, ist etwas länger):
18:09:23.414156 w-d.ac.uunet.de.2089 > cache04.ns.de.uu.net.domain:
27310+ A? www.zdnet.de. (30)
18:09:24.100047 w-d.ac.uunet.de.2089 > cache04.ns.de.uu.net.domain:
27310+ A? www.zdnet.de. (30)
18:09:26.674860 w-d.ac.uunet.de.2089 > cache04.ns.de.uu.net.domain:
27310+ A? www.zdnet.de. (30)
18:09:26.696471 w-d.ac.uunet.de.2089 > cache04.ns.de.uu.net.domain:
27310+ A? www.zdnet.de. (30)
18:09:26.717209 w-d.ac.uunet.de.2089 > cache04.ns.de.uu.net.domain:
27310+ A? www.zdnet.de. (30)
18:09:26.743200 w-d.ac.uunet.de.2089 > cache04.ns.de.uu.net.domain:
27310+ A? www.zdnet.de. (30)
18:09:26.774249 w-d.ac.uunet.de.2089 > cache04.ns.de.uu.net.domain:
27310+ A? www.zdnet.de. (30)
18:09:26.776665 w-d.ac.uunet.de.2089 > cache04.ns.de.uu.net.domain:
27310+ A? www.zdnet.de. (30)
18:09:26.794472 w-d.ac.uunet.de.2089 > cache04.ns.de.uu.net.domain:
27310+ A? www.zdnet.de. (30)
18:09:26.796797 w-d.ac.uunet.de.2089 > cache04.ns.de.uu.net.domain:
27310+ A? www.zdnet.de. (30)
18:09:26.822067 w-d.ac.uunet.de.2089 > cache04.ns.de.uu.net.domain:
27310+ A? www.zdnet.de. (30)
18:09:26.822258 w-d.ac.uunet.de.lrp > cache04.ns.de.uu.net.domain:
53985+ PTR? 105.144.76.192.in-addr.arpa. (45)
18:09:28.450619 pec-30-119.tnt4.me2.uunet.de.prp >
cache05.ns.de.uu.net.domain: 27310+ A? www.zdnet.de. (30)
18:09:28.470651 pec-30-119.tnt4.me2.uunet.de.descent3 >
cache05.ns.de.uu.net.domain: 53985+ PTR? 105.144.76.192.in-addr.arpa.
(45)
18:09:28.499456 cache05.ns.de.uu.net.domain >
pec-30-119.tnt4.me2.uunet.de.prp: 27310 1/2/2 A www.zdnet.de (129) (DF)
18:09:28.529235 cache05.ns.de.uu.net.domain >
pec-30-119.tnt4.me2.uunet.de.descent3: 53985 1/2/2 PTR
cache04.ns.de.uu.net. (176) (DF)
18:09:33.460599 pec-30-119.tnt4.me2.uunet.de.nbx-cc >
cache04.ns.de.uu.net.domain: 27310+ A? www.zdnet.de. (30)
18:09:33.480567 pec-30-119.tnt4.me2.uunet.de.nbx-au >
cache04.ns.de.uu.net.domain: 53985+ PTR? 105.144.76.192.in-addr.arpa.
(45)
18:09:33.512957 cache04.ns.de.uu.net.domain >
pec-30-119.tnt4.me2.uunet.de.nbx-cc: 27310 1/2/2 A www.zdnet.de (129)
(DF)
18:09:33.539743 cache04.ns.de.uu.net.domain >
pec-30-119.tnt4.me2.uunet.de.nbx-au: 53985 1/2/2 PTR
cache04.ns.de.uu.net. (176) (DF)
18:09:38.470561 pec-30-119.tnt4.me2.uunet.de.nbx-ser >
cache05.ns.de.uu.net.domain: 27310+ A? www.zdnet.de. (30)
18:09:38.490353 pec-30-119.tnt4.me2.uunet.de.nbx-dir >
cache05.ns.de.uu.net.domain: 53985+ PTR? 105.144.76.192.in-addr.arpa.
(45)
18:09:38.517566 cache05.ns.de.uu.net.domain >
pec-30-119.tnt4.me2.uunet.de.nbx-ser: 27310 1/2/2 A www.zdnet.de (129)
(DF)
18:09:38.520471 pec-30-119.tnt4.me2.uunet.de.3788 > www.zdnet.de.http: S
4166437221:4166437221(0) win 32120
Hi, Georg Bertram wrote:
Ich habe hier einen Suse7.0-Linux-Server mit ISDN-Dialup (dynamic IP) und Apache also Proxyserver zum Internet. Die Internetverbindung funktioniert auch einwandfrei, schnell und die Verbindung wird automatisch hergestellt, allerdings gibt es einen kleinen Schönheitsfehler:
Der erste http-Request, der von einem Client gesendet wird, braucht sehr lange oder wird garnicht beantwortet. [...] Eigentlich würde ich erwarten, daß der aktive Dynamic-IP-Patch ("cat /proc/sys/net/ipv4/ip_dynaddr" ergibt "7") die Adressen der wartenden Pakete automatisch shiften würde, es erfolgt allerdings auch keine ausgabe in /var/log/messages, wie ich es auch von früheren Distributionen kenne.
/proc/sys/net/ipv4/ip_dynaddr ist auf 7, okay. Ist das interface als dynamic konfiguriert? Such in der SDB nach "dynamic" oder "dynip", da steht, wie das geht. Adalbert PS: Mußt aber nicht gleich 10 Kb Logfile anhängen, 3 Zeilen reichen - soviel liest doch eh kein Mensch.
Hallo,
Hi,
Georg Bertram wrote:
Ich habe hier einen Suse7.0-Linux-Server mit ISDN-Dialup (dynamic IP) und Apache also Proxyserver zum Internet. Die Internetverbindung funktioniert auch einwandfrei, schnell und die Verbindung wird automatisch hergestellt, allerdings gibt es einen kleinen Schönheitsfehler:
Der erste http-Request, der von einem Client gesendet wird, braucht sehr lange oder wird garnicht beantwortet.
[...]
/proc/sys/net/ipv4/ip_dynaddr ist auf 7, okay.
Ist das interface als dynamic konfiguriert?
Ja. Die Einstellungen sind folgendermassen: IFCONFIG_0="10.0.0.2 dynamic pointopoint 192.168.0.1 up" Ausgabe von ifconfig: ippp0 Link encap:Point-to-Point Protocol inet addr:149.225.121.189 P-t-P:139.4.251.10 Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP DYNAMIC MTU:1500 Metric:1 RX packets:3926 errors:0 dropped:0 overruns:0 frame:0 TX packets:3906 errors:1 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:30 Ausgabe von route -n: Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.0.1 0.0.0.0 255.255.255.255 UH 0 0 0 ippp0 10.0.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo 0.0.0.0 192.168.0.1 0.0.0.0 UG 0 0 0 ippp0 Bis dann mal, Georg.
Hallo Georg, Georg Bertram wrote:
Der Firewall, den ich installiert habe, hat keinen Einfluß auf dieses Verhalten. Auch wenn man ihn abschaltet ergibt sich das gleiche Ergebnis. Bist du sicher, daß die Firewall "richtig aus" ist? Das selbe Problem hatte ich auch - trotz dyn. IP-Patch - mal und es stellte sich heraus, daß eine ipchain-Regel das erste (sehr "schnelle") Paket herausfilterte bevor die Regeln an die dyn. IP angepasst wurden...
Salut, Jörg -- ------------------------------------------------------------------------- Name > Joerg Schmitz-Linneweber ** jsl@sth.ruhr-uni-bochum.de < email & > Lehrst. f. Signaltheorie ** +49 234 32-26157 < Phone Address > D-44780 Bochum (Germany) ** +49 234 32-14261 < FAX -------------------------------------------------------------------------
Hallo Jörg,
Der Firewall, den ich installiert habe, hat keinen Einfluß auf dieses Verhalten. Auch wenn man ihn abschaltet ergibt sich das gleiche Ergebnis. Bist du sicher, daß die Firewall "richtig aus" ist? Das selbe Problem hatte ich auch - trotz dyn. IP-Patch - mal und es stellte sich heraus, daß eine ipchain-Regel das erste (sehr "schnelle") Paket herausfilterte bevor die Regeln an die dyn. IP angepasst wurden...
Du hattest Recht! Es waren garnicht alle chains wirklich abgeschaltet. Nach einem ipchains -F läuft es jetzt deutlich besser! Das Problem liegt wohl daran, daß das Suse-Firewallskript, das durch ip-up nach jedem Verbindungsaufbau ausgeführt wird auf meinem P100/64MB einige Sekunden braucht, bis alle rules gesetzt sind, erst dann kommen die Nameserverantworten auch rein. (wo kann ich eigentlich festlegen, in welchem zeitlichen Abstand und wie oft DNS-Anfragen wiederholt werden? Ohne Verwendung von named) Dabei stelle ich mir hier die Frage: Warum legt Suse jedes Mal alle chains passend zur dynamischen IP neu an? Könnte man nicht auch die rules devicebezogen (ippp0) anlegen und dann einfach nur einmal nach Systemstart in die kerneltabellen eintragen? Ansonsten aber schonmal vielen Dank für den passenden Tip! Bis dann mal, Georg.
Hi, Bitte kein CC, ich lese mit. Danke. Georg Bertram wrote:
Das Problem liegt wohl daran, daß das Suse-Firewallskript, das durch ip-up nach jedem Verbindungsaufbau ausgeführt wird auf meinem P100/64MB einige Sekunden braucht, bis alle rules gesetzt sind, erst dann kommen die Nameserverantworten auch rein. (wo kann ich eigentlich festlegen, in welchem zeitlichen Abstand und wie oft DNS-Anfragen wiederholt werden? Ohne Verwendung von named)
Bei Deinem Client. Bezweifle allerdings, das der das kann. (Könnte das bind überhaupt (mal abgesehen von der Frage, ob es sinnvoll ist)?)
Dabei stelle ich mir hier die Frage: Warum legt Suse jedes Mal alle chains passend zur dynamischen IP neu an? Könnte man nicht auch die rules devicebezogen (ippp0) anlegen und dann einfach nur einmal nach Systemstart in die kerneltabellen eintragen?
Ich nehme an, Du meinst die Tatsache, daß die Regeln mit IP und Device erstellt werden (und bei jeder neuen Einwahl mit der neuen IP) neu angelegt werden. Das hat einen Grund, daß die IP-Adr dabei steht (und nicht nur das Interface) - da sind einige Plausibilitätsprüfungen dabei (Sicherheit). Wenn Du das nicht willst, mußt/kannst Du eigene Regeln schreiben und auf die SuSE-Skripts verzichten. Adalbert
Am Dienstag, 17. Oktober 2000 19:28 schrieb Georg Bertram:
dann kommen die Nameserverantworten auch rein. (wo kann ich eigentlich festlegen, in welchem zeitlichen Abstand und wie oft DNS-Anfragen wiederholt werden? Ohne Verwendung von named)
Am einfachsten wohl, wenn Du ipchains die DNS-Anfragen mitloggen läst (Option -l), dann landen die alle schön im Logfile, mit Datum, Zeit und Absenderadresse. Ob das mit dem SuSE-Script geht, weiß ich nicht.
Dabei stelle ich mir hier die Frage: Warum legt Suse jedes Mal alle chains passend zur dynamischen IP neu an? Könnte man nicht auch die rules devicebezogen (ippp0) anlegen und dann einfach nur einmal nach Systemstart in die kerneltabellen eintragen?
Doch, das geht, hab mein Script nach Einrichtung eines 486ers und der Startzeit dort auch gemacht. Ob's mit dem SuSE-Script geht, weiß ich allerdings nicht, ich mach meine Fehler lieber selber. -- Machs gut | http://www.iiv.de/schwinde/buerger/tremmel/ | http://www.knightsoft.de Manfred | http://www.knightsoft-net.de -> Bundesliga-Tipprunde!
participants (4)
-
Georg Bertram -
Jörg Schmitz-Linneweber -
Manfred Tremmel -
Michelic Adalbert