Hallo Leutz,
bei einem Kunden hatte ich letztes Jahr massiv Probleme mit der Fehlermeldung “Error 64”, welcher sporadisch beim Aufruf auf bestimmte Webseiten auftauchte. Aufgrund der Komplexitaet des Netzwerkes sind wir bei der Fehlersuche nicht wirklich voran gekommen.
De Fehlermeldung Error 64 ist leider auch mehrdeutig:
http://blogs.technet.com/isablog/archive/2009/01/30/users-receive-an-error-64-when-browse-a-web-site-published-through-isa-sever-2006.aspx
http://blogs.technet.com/yuridiogenes/archive/2008/11/23/error-64-the-specified-network-name-is-no-longer-available-while-browsing-internet-through-isa-server-2006.aspx
http://blogs.technet.com/yuridiogenes/archive/2008/10/09/error-64-from-the-field-to-the-classroom.aspx
Heute Morgen hat sich der Kunde wieder gemeldet und eine Loesung fuer die Problematik gefunden, welche ich Euch nicht vorenthalten moechte:
Auszug aus der e-mail des Kunden
Thema: Error64
Aussage: Wir hatten/haben auf manchen Webseiten massiv den Error64 vom Isa bekommen und ich hab mich da mal reingehängt, was rauszufinden.
Kunden-Konstellation:
Client->ISA2006->Firewall (NAT von LAN auf public IP)->bluecoat-Proxy(T-systems)->Internet
Da der ISA dem Client den Error64 schickte, hab ich mich mal VOR den ISA geklemmt. Und siehe da, der Blueacoat schickt dem ISA einen TCP FIN ACK, mit der Auswirkung, dass der Client einen Error64 vom ISA bekommt.
Hab mich dann mal mit den Bluecoat-Spezies hingesetzt und wir haben ein paar “Features” ausprobiert. Und siehe da, beim deaktivieren von “reflected-IP” funktionierte die Webseite fehlerfrei!
Reflected-IP funktioniert so, das der Proxy ja eigentlich mit der public IP vom ISP im Internet hängt. Laut Gesetz darf das aber nicht, wenn da mehrere Kunden darüber laufen. Also wird vorher (bei uns auf der Firewall) von LAN auf Public IP genattet und diese/unsere public IP vom Proxy als Source IP genutzt. Das bewirkt das die Anfragen von uns mit der Public IP von uns und nicht mit der von T-Systems ins Netz gehen. Und der Prozess auf dem Proxy nennt sich “Reflected IP”. Deaktiviert man diesen (für eine bestimmte Webseite, wo es massiv auftaucht), funktioniert es!!!
Wo genau es nun am Proxy liegt und ob er sich RFC konform verhällt bleibt abzuwarten. Könnte auch mit Content-Legth-Headern zu tun haben, beim Zwischenspeichern vom Proxy, wo der in dem Fall einen FIN ACK rausjagt, aber das bleibt noch abzuwarten.
NACHTRAG vom 07.07.2010: Mein Kunde hat das Problem geloest:
“Nachdem unser “ISP” auf dem Bluecoat als globales setting den Befehl http.client.persistence(preserve)
eingetragen hat, war der Spuk mit dem error64 endlich vorbei!!! ”
Gruss Marc
