Squid, erste (missed) Seite dauert ewig
Moin Liste! Der Betreff sagt es schon: Ein Dial-on-Demand-Router (ISDN) mit transparentem Squid braucht für die Übermittlung der ersten Webseite nach einer Einwahl immer eine Ewigkeit (2 bis 3 Minuten). Dadruch geben die meisten Clients schon vorher mit einem Timeout auf. Basis ist SuSE 7.2 mit SuSE-Firewall2 (Kernel 2.4.4), DYN-IP in rc.config ist natürlich aktiviert (ist ja default). Alle Beiträge zum Thema in Geocrawler deuten nur auf diesen DYN_IP-Patch hin, der aber hier als Ursache (oder besser Lösung) ausscheidet. Hat jemand eine Idee, woran das liegen könnte? Danke, Alfred
Hallo Alfred,
From: Alfred Poschmann [mailto:aposch@gmx.net] Moin Liste!
Der Betreff sagt es schon: Ein Dial-on-Demand-Router (ISDN) mit transparentem Squid braucht für die Übermittlung der ersten Webseite nach einer Einwahl immer eine Ewigkeit (2 bis 3 Minuten). Dadruch geben die meisten Clients schon vorher mit einem Timeout auf.
Basis ist SuSE 7.2 mit SuSE-Firewall2 (Kernel 2.4.4), DYN-IP in rc.config ist natürlich aktiviert (ist ja default). Alle Beiträge Bist du sicher, dass das läuft? Was gibt cat /proc/sys/net/ipv4/ip_dynaddr aus? Wenn du bei geschlossener Leitung einen Ping auf eine IP-Adresse draußen startest, kommt dann das Paket mit icmp_seq=0 an? Kann es vielleicht an deinem DNS-Server liegen? Benutzst du einen eigenen DNS-Server auf der Maschine oder den DNS-Server deines Providers?
zum Thema in Geocrawler deuten nur auf diesen DYN_IP-Patch hin, der aber hier als Ursache (oder besser Lösung) ausscheidet.
Hat jemand eine Idee, woran das liegen könnte?
Danke, Alfred
Gruß, Andreas
Am Mittwoch, 3. Oktober 2001 17:12 schrieb Andreas Achtzehn:
Bist du sicher, dass das läuft? Was gibt cat /proc/sys/net/ipv4/ip_dynaddr aus? Wenn du bei geschlossener Leitung einen Ping auf eine
Da kommt 7 zurück, scheint dann wohl zu laufen.
IP-Adresse draußen startest, kommt dann das Paket mit icmp_seq=0 an? Kann es vielleicht an deinem DNS-Server liegen? Benutzst du einen eigenen DNS-Server auf der Maschine oder den DNS-Server deines Providers?
ping bol.de (weil kurze domain :) fängt erst bei Paket 20 an (manchmal auch schon bei Paket 8 oder so); wenn die Kiste online ist, startet es natürlich bei Paket 0. Ja, und lokal läuft bind8, wenn ich mich recht entsinne, in der Standard-Konfiguration (will sagen, habe nichts Besonderes an der Grundkonfiguration gedreht). Dieter scheint ja etwas ähnliches zu argwöhnen: Am Mittwoch, 3. Oktober 2001 20:15 schrieb Dieter Kluenter:
Ein weiterer Grund koennte mangelhafte Namensauflösung sein. Pruefe die Nameserver Konfiguration.
Wie prüft man so etwas? Von der bloßen Nutzung her funzt alles. /var/log/messages erzählt zumindest nichts von Problemen.
Es koennten auch unklare Filterregeln für den Paketfilter sein, pruefe mal deine Filterregeln unter realen Adress- und Portbedingungen. Letztendlich koennte die Urache auch im Routing liegen. Pruefge dein Routing.
Ich fürchte, beide Punkte checke ich nicht. Paketfilter ist die SuSEfirewall2, konfiguriert ohne große Tricksereien (außer vielleicht dem transparenten Squid). Wie kann ich die Regeln "unter realen Bedingungen" prüfen? Und Routing ist ein gänzlich weißer Fleck auf der Landkarte - für mich zumindest. Alle vernetzten Clients können alle Dienste nutzen, scheint also alles okay zu sein. Da sieht man schon, dass ich mich beim Routing voll auf die SuSE-Standard-Konfig stütze :) Ich fürchte, meine Groschen stecken noch fest. Alfred
Hallo, aposch@gmx.net (Alfred Poschmann) writes:
Am Mittwoch, 3. Oktober 2001 17:12 schrieb Andreas Achtzehn:
Ja, und lokal läuft bind8, wenn ich mich recht entsinne, in der Standard-Konfiguration (will sagen, habe nichts Besonderes an der Grundkonfiguration gedreht).
Dieter scheint ja etwas ähnliches zu argwöhnen: Am Mittwoch, 3. Oktober 2001 20:15 schrieb Dieter Kluenter:
Ein weiterer Grund koennte mangelhafte Namensauflösung sein. Pruefe die Nameserver Konfiguration.
Wie prüft man so etwas? Von der bloßen Nutzung her funzt alles. /var/log/messages erzählt zumindest nichts von Problemen.
Ich befuerchte, du hast keinen Nameserver fuer deine private Domainverwaltung, sondern nur einen cache only Nameserver. Die simple Pruefung ist 'nslookup hostname' Wenn da nichts kommt, stimmt etwas nicht.
Es koennten auch unklare Filterregeln für den Paketfilter sein, pruefe mal deine Filterregeln unter realen Adress- und Portbedingungen. [...] Ich fürchte, beide Punkte checke ich nicht. Paketfilter ist die SuSEfirewall2, konfiguriert ohne große Tricksereien (außer vielleicht dem transparenten Squid). Wie kann ich die Regeln "unter realen Bedingungen" prüfen?
Eigentlich streube ich mich gegen den Begriff 'Firewall' in diesem Zusammenhang, es sind eigentlich nur Regeln fuer den Paketfilter des Kernels, der Filter des Kernels 2.4 ist iptables. Ich habe heute Abend das iptables-HOWTO nicht verfuegbar, ich weiss aber dass es bei ipchains der Schalter -C ist. Daher jetzt ein Beispiel fuer eine Filterregelung mit ipchains ipchains -C input -p tcp -y -i ippp0 -s 0/0 80 -d 192.168.1.1./16 1024: Damit wird geprueft, ob von aussen eine Verbindung zu einem lokalen Host auf Port 80 hergestellt werden darf. Aehnliches ist auch mit iptabels moeglich.
Und Routing ist ein gänzlich weißer Fleck auf der Landkarte - für mich zumindest. Alle vernetzten Clients können alle Dienste nutzen, scheint also alles okay zu sein. Da sieht man schon, dass ich mich beim Routing voll auf die SuSE-Standard-Konfig stütze :)
Dann wird es aber Zeit, sich damit zu beschaeftigen ;-) -Dieter -- chmod +x /usr/bin/laden
Am Mittwoch, 3. Oktober 2001 23:00 schrieb Dieter Kluenter: [...]
Ich befuerchte, du hast keinen Nameserver fuer deine private Domainverwaltung, sondern nur einen cache only Nameserver.
Die simple Pruefung ist 'nslookup hostname' Wenn da nichts kommt, stimmt etwas nicht.
Ja, schon, ich denke doch, das ist richtig so. Der Router wählt sich doch für das lokale Netz (maximal 5 PC/Mac) ein, brauche ich da eine private Domainverwaltung? ein nslookup auf einen lokalen Rechner-Namen liefert erst die IP des Nameservers (das ist localhost), dann die Fehlermeldung "*** localhost can't find wimal: Non-existent host/domain", obwohl wimal in /etc/hosts eingetragen ist. Schon gomisch. Externe Rechner klappen.
Ich fürchte, beide Punkte checke ich nicht. Paketfilter ist die SuSEfirewall2, konfiguriert ohne große Tricksereien (außer vielleicht dem transparenten Squid). Wie kann ich die Regeln "unter realen Bedingungen" prüfen?
Eigentlich streube ich mich gegen den Begriff 'Firewall' in diesem Zusammenhang, es sind eigentlich nur Regeln fuer den Paketfilter des Kernels, der Filter des Kernels 2.4 ist iptables.
Okay, der Paketfilter heißt SuSEfirewall2, ist aber keiner.
Ich habe heute Abend das iptables-HOWTO nicht verfuegbar, ich weiss aber dass es bei ipchains der Schalter -C ist. Daher jetzt ein Beispiel fuer eine Filterregelung mit ipchains
ipchains -C input -p tcp -y -i ippp0 -s 0/0 80 -d 192.168.1.1./16 1024:
Damit wird geprueft, ob von aussen eine Verbindung zu einem lokalen Host auf Port 80 hergestellt werden darf.
Aehnliches ist auch mit iptabels moeglich.
Was kann ich damit feststellen? Rein theoretisch (nicht getestet) sollte Port 80 von außen aber dicht sein. Ich habe keinen Webserver, auf den von außen zugegriffen werden soll.
Und Routing ist ein gänzlich weißer Fleck auf der Landkarte - für mich zumindest. Alle vernetzten Clients können alle Dienste nutzen, scheint also alles okay zu sein. Da sieht man schon, dass ich mich beim Routing voll auf die SuSE-Standard-Konfig stütze :)
Dann wird es aber Zeit, sich damit zu beschaeftigen ;-)
Leih mir Zeit, Dieter! :) Ahja, leider weiß ich nicht weiter, was mein ursprüngliches Problem angeht ("erste Seite erst nach Minuten"). Gibt es irgendwo passenden Lesestoff, der mich weiterführen könnte? Alfred
aposch@gmx.net (Alfred Poschmann) writes:
Am Mittwoch, 3. Oktober 2001 23:00 schrieb Dieter Kluenter: [...]
Ich befuerchte, du hast keinen Nameserver fuer deine private Domainverwaltung, sondern nur einen cache only Nameserver.
Die simple Pruefung ist 'nslookup hostname' Wenn da nichts kommt, stimmt etwas nicht.
Ja, schon, ich denke doch, das ist richtig so. Der Router wählt sich doch für das lokale Netz (maximal 5 PC/Mac) ein, brauche ich da eine private Domainverwaltung?
Nein, nicht unbedingt, eine gut gepflegte /etc/hosts sollte genuegen.
ein nslookup auf einen lokalen Rechner-Namen liefert erst die IP des Nameservers (das ist localhost), dann die Fehlermeldung "*** localhost can't find wimal: Non-existent host/domain", obwohl wimal in /etc/hosts eingetragen ist. Schon gomisch. Externe Rechner klappen.
OK. dass ist so in Ordnung, wenn keine lokale Domainverwaltung besteht. Ein ping auf einen lokalen host geht aber ohne Zeitverzoegerung ? [...]
Eigentlich streube ich mich gegen den Begriff 'Firewall' in diesem Zusammenhang, es sind eigentlich nur Regeln fuer den Paketfilter des Kernels, der Filter des Kernels 2.4 ist iptables.
Okay, der Paketfilter heißt SuSEfirewall2, ist aber keiner.
Nein, der Paketfilter heisst iptables und das Installationsscript heisst SuSEfirewall2 :-)
ipchains -C input -p tcp -y -i ippp0 -s 0/0 80 -d 192.168.1.1./16 1024:
Aehnliches ist auch mit iptabels moeglich.
Was kann ich damit feststellen? Rein theoretisch (nicht getestet) sollte Port 80 von außen aber dicht sein. Ich habe keinen Webserver, auf den von außen zugegriffen werden soll.
Mit dem Schalter -C kann dan geprueft werden, ob der Paketfilter entsprechende Datenpakete an von den definierten Adressen an den definierten Ports durchlaesst oder verwirft oder einer sonstigen Behandlung unterzieht.Das Ergebnis wird dann angezeigt. Meine Zeilen sollten nur ein Beispiel sein, wie so etwas gemacht wird. [...]
Ahja, leider weiß ich nicht weiter, was mein ursprüngliches Problem angeht ("erste Seite erst nach Minuten"). Gibt es irgendwo passenden Lesestoff, der mich weiterführen könnte?
Dein Urspruegnliches Problem haengt vermutlich mit den aufgezeigten Fragen zusammen. Ich tippe aber mal auf Namensaufloesung. Da fällt mir ein, dass ja neuere SuSE-Versionen im ip-up script versuchen, den Nameserver des Providers ausfindig zu machen und diesen dann in /etc/resolv.conf eintragen, koennte hier die Ursache liegen ? Ich wuerde mal versuchen, usepeerdns in /etc/ppp/options abzuschalten und deinen cache only DNS zu verwenden. -Dieter -- chmod +x /usm/bin/laden
From: Alfred Poschmann [mailto:aposch@gmx.net]
Am Mittwoch, 3. Oktober 2001 17:12 schrieb Andreas Achtzehn:
Bist du sicher, dass das läuft? Was gibt cat /proc/sys/net/ipv4/ip_dynaddr aus? Wenn du bei geschlossener Leitung einen Ping auf eine
Da kommt 7 zurück, scheint dann wohl zu laufen. Bei mir 1 zurück, versuch daher mal ein
echo 1 > /proc/sys/net/ipv4/ip_dynaddr
IP-Adresse draußen startest, kommt dann das Paket mit icmp_seq=0 an? Kann es vielleicht an deinem DNS-Server liegen? Benutzst du einen eigenen DNS-Server auf der Maschine oder den DNS-Server deines Providers?
ping bol.de (weil kurze domain :) fängt erst bei Paket 20 an (manchmal auch schon bei Paket 8 oder so); wenn die Kiste online ist, startet es natürlich bei Paket 0.
Da liegt das Problem. Deine ersten Pakete gehen verloren, dass sind im Normalfall die Pakete, um eine Verbindung zwischen dir und dem Webserver herzustellen.
Ja, und lokal läuft bind8, wenn ich mich recht entsinne, in der Standard-Konfiguration (will sagen, habe nichts Besonderes an der Grundkonfiguration gedreht).
Ich schicke dir mal per private Mail eine bind8 Konfiguration, die, wenn man sie nach /etc/named.conf kopiert, eigentlich laufen sollte.
Dieter scheint ja etwas ähnliches zu argwöhnen: Am Mittwoch, 3. Oktober 2001 20:15 schrieb Dieter Kluenter:
Ein weiterer Grund koennte mangelhafte Namensauflösung sein. Pruefe die Nameserver Konfiguration.
Wie prüft man so etwas? Von der bloßen Nutzung her funzt alles. /var/log/messages erzählt zumindest nichts von Problemen.
Es koennten auch unklare Filterregeln für den Paketfilter sein, pruefe mal deine Filterregeln unter realen Adress- und Portbedingungen. Letztendlich koennte die Urache auch im Routing liegen. Pruefge dein Routing.
Ich fürchte, beide Punkte checke ich nicht. Paketfilter ist die SuSEfirewall2, konfiguriert ohne große Tricksereien (außer vielleicht dem transparenten Squid). Wie kann ich die Regeln "unter realen Bedingungen" prüfen? Und Routing ist ein gänzlich weißer Fleck auf der Landkarte - für mich zumindest. Alle vernetzten Clients können alle Dienste nutzen, scheint also alles okay zu sein. Da sieht man schon, dass ich mich beim Routing voll auf die SuSE-Standard-Konfig stütze :)
Ich fürchte, meine Groschen stecken noch fest.
Alfred
Gruß, Andreas
Hallo, suse-linux@achtzehn.2y.net ("Andreas Achtzehn") writes:
From: Alfred Poschmann [mailto:aposch@gmx.net]=20 =20 =20 Am Mittwoch, 3. Oktober 2001 17:12 schrieb Andreas Achtzehn: =20
Bist du sicher, dass das l=E4uft? Was gibt cat /proc/sys/net/ipv4/ip_dynaddr aus? Wenn du bei geschlossener Leitung einen Ping auf eine =20 Da kommt 7 zur=FCck, scheint dann wohl zu laufen.=20 Bei mir 1 zur=FCck, versuch daher mal ein
echo 1 > /proc/sys/net/ipv4/ip_dynaddr
Nein ! Das ist von Version zu Version unterschiedlich, die '7' ist OK. [...] -Dieter -- chmod +x /usm/bin/laden
aposch@gmx.net (Alfred Poschmann) writes:
Moin Liste!
Der Betreff sagt es schon: Ein Dial-on-Demand-Router (ISDN) mit transparentem Squid braucht für die Übermittlung der ersten Webseite nach einer Einwahl immer eine Ewigkeit (2 bis 3 Minuten). Dadruch geben die meisten Clients schon vorher mit einem Timeout auf.
Basis ist SuSE 7.2 mit SuSE-Firewall2 (Kernel 2.4.4), DYN-IP in rc.config ist natürlich aktiviert (ist ja default). Alle Beiträge zum Thema in Geocrawler deuten nur auf diesen DYN_IP-Patch hin, der aber hier als Ursache (oder besser Lösung) ausscheidet.
Pruefe erst einmal mit 'cat /proc/sys/net/ipv4/ip_dynaddr' ob die dynamische Addressaufloesung aktiviert wurde, es muss ein Wert > 0 ausgegeben werden, je nach Version vermutlich '7'. sonst ein echo "7" > /proc/sys/net/ipv4/ip_dynaddr Ein weiterer Grund koennte mangelhafte Namensauflösung sein. Pruefe die Nameserver Konfiguration. Es koennten auch unklare Filterregeln für den Paketfilter sein, pruefe mal deine Filterregeln unter realen Adress- und Portbedingungen. Letztendlich koennte die Urache auch im Routing liegen. Pruefge dein Routing. -Dieter -- chmod +x /usr/bin/laden
participants (3)
-
Alfred Poschmann -
Andreas Achtzehn -
Dieter Kluenter