Hallo,
danke für die Antwort. Mittlerweile kann ich das Problem weiter
eingrenzen. Es wird nicht am Router liegen, da ich es von Zuhause und
in der Schule probiert habe und bei beiden das gleiche Ergebnis
erscheint. Es wird wohl auch nicht an squid liegen, da es ja von den
Linuxclients aus klappt.
Unter Windwos funktioniert es vom IE aus, aber nicht von Firefox
(weder 3.X.X Version noch 4.X.X Version). Also irgendeine Firefox
Einstellung?
Besten Gruß, Martin
HIer sind die Ausgaben von tcpdump
Hier der tcpdump für eine http-Seite
19:02:28.188465 IP nsx2.web.de.domain > tjener.intern.34544: 36862*-
1/0/0 (69)
19:02:28.460631 IP tjener.intern.33304 > nsx2.web.de.domain: 28057
PTR? 209.204.72.217.in-addr.arpa. (45)
19:02:28.485347 IP nsx2.web.de.domain > tjener.intern.33304: 28057*-
1/0/0 (84)
19:02:30.588727 IP tjener.intern.2881 > nsx2.web.de.domain: 6087
PTR? 230.204.72.217.in-addr.arpa. (45)
19:02:30.612846 IP nsx2.web.de.domain > tjener.intern.2881: 6087*-
1/0/0 (75)
dann für eine https-Seite von einem Windows-Client
tjener:/var/log/squid# tcpdump |grep "web"
19:03:08.821192 IP tjener.intern.36362 > login.web.de.https: S
4077479491:4077479491(0) win 5840 <mss 1460,sackOK,timestamp
134647224 0,nop,wscale 6>
19:03:08.847064 IP login.web.de.https > tjener.intern.36362: S
2367697086:2367697086(0) ack 4077479492 win 5792 <mss
1452,sackOK,timestamp 371743744 134647224,nop,wscale 0>
19:03:08.847089 IP tjener.intern.36362 > login.web.de.https: . ack 1
win 92 <nop,nop,timestamp 134647231 371743744>
19:03:23.882587 IP login.web.de.https > tjener.intern.36362: F
1:1(0) ack 1 win 5792 <nop,nop,timestamp 371745248 134647231>
19:03:23.882733 IP tjener.intern.36362 > login.web.de.https: F
1:1(0) ack 2 win 92 <nop,nop,timestamp 134650990 371745248>
19:03:23.907428 IP login.web.de.https > tjener.intern.36362: . ack 2
win 5792 <nop,nop,timestamp 371745250 134650990>
19:03:23.931442 IP tjener.intern.54741 > login.web.de.https: S
13738863:13738863(0) win 5840 <mss 1460,sackOK,timestamp 134651002
0,nop,wscale 6>
19:03:23.956472 IP login.web.de.https > tjener.intern.54741: S
2834555995:2834555995(0) ack 13738864 win 5792 <mss
1452,sackOK,timestamp 372515312 134651002,nop,wscale 0>
19:03:23.956498 IP tjener.intern.54741 > login.web.de.https: . ack 1
win 92 <nop,nop,timestamp 134651008 372515312>
und eine https-Seite von einem Linux-Client
19:04:39.432822 IP login.web.de.https > tjener.intern.35404: . ack 2
win 5792 <nop,nop,timestamp 371636544 134669870>
19:04:39.445612 IP tjener.intern.57801 > login.web.de.https: S
1192743863:1192743863(0) win 5840 <mss 1460,sackOK,timestamp
134669879 0,nop,wscale 6>
19:04:39.470857 IP freemailng0303.web.de.https >
tjener.intern.43693: P 139:703(564) ack 1039 win 8320
<nop,nop,timestamp 310586477 134669876>
19:04:39.470908 IP freemailng0303.web.de.https >
tjener.intern.43693: P 703:740(37) ack 1039 win 8320
<nop,nop,timestamp 310586477 134669876>
19:04:39.470912 IP tjener.intern.43693 >
freemailng0303.web.de.https: . ack 740 win 126 <nop,nop,timestamp
134669886 310586477>
Am 14.04.2011 18:25, schrieb Mike Gabriel:
Hi Martin,
On Do 14 Apr 2011 14:22:30 CEST Martin Schulte wrote:
Hallo,
ich habe ein Problem mit squid, dass ich nicht ganz verstehe. Und
zwar versuche ich von einem Windows-Client aus eine https (ssl)
seite zu erreichen. Dies gelingt aber nicht, er lädt ziemlich lange
und zeigt dann eine leere Seite an. Von einem Linux-Client geht es.
Ich habe im Firefox/Iceweasle jeweils händisch webcache , Port 3128
und auch mal 10.0.2.2 , Port 3128 eingetragen (für http und ssl) und
nicht die automatische Konfiguration genutzt.
Squid ist ja so konfiguriert, dass er Anfragen an https-Seiten
einfach "durchlässt",
die Log-Datei sieht auch gut aus:
https -Seite vom Win-Client
4 static07.intern TCP_MISS/200 39 CONNECT login.web.de:443 -
DIRECT/217.72.199.
http-Seite vom Win-Client
0 static07.intern TCP_MISS/200 16545 GET http://www.web.de/ -
DIRECT/213.165.64
Firewall ist aus.
Keine Ahnung woran das liegen kann.
du könntest mit einem tcpdump auf tjener testen, welche
Verbindungsversuche wirklich unternommen werden beim Aufrufen deiner
https-Seiten...
Wenn du die Firewall(s) wirklich aus hast (DSL-Router?), dann ist das
Problem erstmal mysteriös, aber bestimmt erklärbar.
Ich kenne allerdings auch Fälle, wo Provider ihre Server so
ping-sicher machen, dass Path MTU Negotiation fehl schlägt. Dies
würde dann allerdings alle Dienste im Netz betreffen, nicht nur
https. Der Fehler wäre allerdings so, dass du bei den verschiedensten
Webseiten etc. timeouts bzw. lange Wartezeiten erleben würdest und
das dann ganz unvorhersagbar.
Liebe Grüße,
Mike