Hallo liebe Wissende,
ich darf mein Problem mal kurz skizzieren:
Piranja Schnittstellen:
- eth0: externe ip via Kabel ISP
- eth1: 192.168.1.1, hier haengt das interne Netz 192.168.1.0/24
- eth2: 192.168.10.230, hier haengt die DMZ
Maschinen in der DMZ:
- physikalische VMWare vSphere Client v4, 192.168.10.9 (Wirt)
- virtuelle Maschine Linux 'Ubuntu', 192.168.10.10 (Gast)
Maschine im internen Netz:
- physikalische Maschine PC 'Win7', 192.168.1.22
'Ubuntu' serviert eine PHP Webanwendung via Apache2 und ist per Port-Forwarding (tcp:80) und DynDNS-Mapping von Extern (Internet) erreichbar. Die Web-Anwendung funktioniert von aussen vollstaendig und schnell.
Versuche ich nun, die Website auf dem DMZ Ubuntu vom internen host Win7 zu erreichen, treten Verzoegerungen von ca. 5 Sekunden fuer einige Elemente der verschiedenen Websites auf (gemessen mit Firebug). Setze ich fuer eine dieser Websites die Resource (z.b. eine css-Datei oder eine jpg-Datei) in einen Kommentar, so tritt eine identisch lange Verzoegerung fuer eine jeweilig andere Resource jener Website auf. Die Verzeogerungen erstrecken sich auch auf andere Elemente wie z.B. inkludierte php-Dateien. Die identische Website ist von extern ohne Verzoegerung downloadbar.
In jedem Falle ist die Seite nach 5s vollstaendig und fehlerfrei geladen. Generell sind die Seiten auf 'Ubuntu' via internem DNS (siehe Thread http://www.securepoint.de/support/topic.php?id=819) zu erreichen.
Ich habe bereits alle Interceptions wie Virus-Scanning, Firewall-Regeln eliminiert, aber es gibt keine Verbesserung.
Wireshark gibt keinerlei Fehler aus. Sauberes tcp-Handshake, keine Fehler auf Anwendungsebene (http), lediglich das Delay von 5s wird bestaetigt. Es zeigt sich, dass Win7 5s lang auf die Antwort Ubuntu wartet bzgl. der verzoegerten Elemente.
Hat jemand dieses oder aehnliches Problem bereits angepackt oder kann mir eine Richtung geben?
Herzlichen Dank # cbiehl
Verzoegerung http DMZ web server nach interner Rechner
Moderator: Securepoint
Hallo, danke schon mal fuer die Antwort.
Leider laufen die DNS lookups reibungslos und sehr schnell. Habe dies wiederholt und mit den verschiedenen Websites auf 'Ubuntu' verifiziert.
Darueberhinaus werden die ersten Objekte einer jeden Webpage schnell geladen. Dies setzt ja eine Aufloesung der des FQDN voraus. An einem oder mehreren Objekten der jeweiligen Website haengt's dann trotzdem.
Hat jemand vielleicht noch andere Ideen?
Danke schoen dafuer.
Leider laufen die DNS lookups reibungslos und sehr schnell. Habe dies wiederholt und mit den verschiedenen Websites auf 'Ubuntu' verifiziert.
Darueberhinaus werden die ersten Objekte einer jeden Webpage schnell geladen. Dies setzt ja eine Aufloesung der des FQDN voraus. An einem oder mehreren Objekten der jeweiligen Website haengt's dann trotzdem.
Hat jemand vielleicht noch andere Ideen?
Danke schoen dafuer.
Moin,
ich hatte mal einen ähnlichen Fall. Obwohl es keine Fehler auf den Interfacen der FW gab kam es zu einem "langsamen Aufbau".
Des Rätsels Lösung damals: FW und Switch konnten sich scheinbar nicht auf eine Geschw. einigen bzw. 1000MbiT/s liefen nicht. Vielleicht installieren Sie sich mal die 10.6 und stellen von Autoneg auf 100Mb/s full.
ich hatte mal einen ähnlichen Fall. Obwohl es keine Fehler auf den Interfacen der FW gab kam es zu einem "langsamen Aufbau".
Des Rätsels Lösung damals: FW und Switch konnten sich scheinbar nicht auf eine Geschw. einigen bzw. 1000MbiT/s liefen nicht. Vielleicht installieren Sie sich mal die 10.6 und stellen von Autoneg auf 100Mb/s full.
There are 10 types of people in the world... those who understand binary and those who don\'t.
Hallo an alle,
ungluecklicherweise macht auch die "Gleichschaltung" der Geschwindigkeiten und Duplex-Modi aller Interfaces keinen Unterschied. Das Problem besteht weiterhin unveraendert.
Habe gestern die Firmware-Version 10.6 aufgespielt. Ebenselbe Verzoegerung. Mein neuer Ansatz, Probleme per Ausschlussverfahren aufzuspueren, wird morgen in folgender Aktion gipfeln: das Host-System fuer den virtuellen 'Ubuntu' Rechner in der DMZ fliegt raus und wird durch einen physikalischen Host ersetzt.
Der Austausch von 'Win7' scheint mir unnuetz, zeigt sich doch mit anderen physikalischen Rechnern im internen Netz das identische Problem.
Nach wie vor bin ich fuer jedwede Idee dankbar. Herzlichen Dank schon einmal dafuer.
ungluecklicherweise macht auch die "Gleichschaltung" der Geschwindigkeiten und Duplex-Modi aller Interfaces keinen Unterschied. Das Problem besteht weiterhin unveraendert.
Habe gestern die Firmware-Version 10.6 aufgespielt. Ebenselbe Verzoegerung. Mein neuer Ansatz, Probleme per Ausschlussverfahren aufzuspueren, wird morgen in folgender Aktion gipfeln: das Host-System fuer den virtuellen 'Ubuntu' Rechner in der DMZ fliegt raus und wird durch einen physikalischen Host ersetzt.
Der Austausch von 'Win7' scheint mir unnuetz, zeigt sich doch mit anderen physikalischen Rechnern im internen Netz das identische Problem.
Nach wie vor bin ich fuer jedwede Idee dankbar. Herzlichen Dank schon einmal dafuer.
Hallo,
als erstes würde ich prüfen ob es physikalisch Problem gibt, per "iperf" kann man z.B UDP Traffic mit einer beliebigen Bandbreite erzeugen. Oder Cliet und Server ins selbe Netz stellen.
Sollte dies ohne Verzögerungen in beiden Richtungen funktionieren, würde ich mich EINEM HTTP-Download widmen.
Erst danach würde ich versuchen die Geschwindigkeit einer Webseite zu analysieren.
als erstes würde ich prüfen ob es physikalisch Problem gibt, per "iperf" kann man z.B UDP Traffic mit einer beliebigen Bandbreite erzeugen. Oder Cliet und Server ins selbe Netz stellen.
Sollte dies ohne Verzögerungen in beiden Richtungen funktionieren, würde ich mich EINEM HTTP-Download widmen.
Erst danach würde ich versuchen die Geschwindigkeit einer Webseite zu analysieren.
There are 10 types of people in the world... those who understand binary and those who don\'t.