dankumc
Goto Top

Debian Apache2 Webserver, Timeout, DNS-Problem Windows Domäne

hallo an alle ;)
Wir nutzen einen Webserver, welcher nur innerhalb unseres VPNs (Domänen-Netzwerk) erreichbar ist. Beim Zugriff auf die lokalen Webseiten kommt es zu Verzögerungen.

Folgende relevanten Server/Clients sind im Netzwerk:

Webserver: Debian 6 64bit, 4GB RAM, 2x1 Gigabit Ethernet, OHNE GUI, Apache2 (mit Standardeinstellungen) und 4 Virtuellen Hosts!!, SSH, FTP
DNS-Server und Domänencontroller (AD): Windows Server 2008 R2, 8GB RAM, 2x1 Gigabit Ethernet,
Clients: Win XP incl. SP3 / Win 7, Internet Explorer 8, 1x 100Mbit bzw. 1 Gbit Ethernet (in Netzwerkverbindungen DNS-Eintrag vom DNS-Server aber nur bedingt bei einigen auch Gateway)

Um das Problem zu lösen haben wir 2 verschiedene Wege probiert:

1. Konfiguration (Peer to Peer):

Um herauszufinden, ob ein DNS-Problem vorliegt, wurde der Webserver vom Netz genommen.
Anschließend wurde dieser mit einem Arbeitsplatzrechner und einem Switch verbunden.
Der Ping läuft einwandfrei und dies zeigen auch die Ladezeiten der Webseite (ca. 300 kb) vom Webserver (ca. 2-5sec. bis komplette Seite geladen)
Daher kann das Problem schon einmal nicht direkt beim Webserver liegen (geschweige denn an dem Template bzw. der PHP-Code der Webseite)
Die Webseite (Joomla 1.6.3 mit Template von Joomlart) wird ohne iframes, Grafiken mit weniger als 20kb Größe, ohne Einbinden von externen Code geladen.
Anbei ein Auszug der Ladezeit mithilfe von Firebug im Firefox: http://imageshack.us/photo/my-images/834/firebugs.png/

2. Konfiguration (Domänennetzwerk):

Alle Netzkomponenten (Server, Clients etc) sind mit einem Hauptswitch verbunden (100Mbit, 1Gbit). Die Clients melden sich am DNS-Server an der Domäne x an.
Dieser Server ist mit einem Vodafone-Router (Gateway) verbunden - um per VPN die anderen Häuser mit Daten zu versorgen (in diesem Fall mit der Webseite des Webservers).
Leider ist der Router nicht konfigurierbar.

Wenn User 1 die Webseite im Browser aufruft, dann dauer der Ladevorgang ca. 6-12 Sekunden. Dies ist unbefriedigend!

Folgende Einstellungen wurden daher im Internet Explorer 8 gemacht:
In den Internetoptionen wurden im Reiter "Sicherheit" das "lokale Intranet" auf die niedrigste Stufe gestellt und der Name der Webseite sowohl die IP-Adresse des Webservers hinzugefügt.
Genauso wurden beim Reiter "Datenschutz" der Name der Webseite als auch die IP-Adresse angegeben.
Bei den LAN-Einstellungen im Reiter (Verbindungen) wurden bei dem Proxy-Einstellungen der Name der Webseite als auch die der IP-Adresse angegeben.

Die Host-Datei (%WINDOWS%/%System32%/drivers/etc/hosts) wurde wiefolgt ergänzt:
IP-Adresse des Webservers Name der Webseite

Der Ping-Befehl zum Webserver von einem Client bzw. vom DNS-Server aus quittiert die Verbindung mit einer Zeit von weniger als 1ms.
Die Verbindung steht also.

Daher wurde in den DNS-Einstellungen auf dem DNS-Server folgende Einstellungen gemacht:
In der Forward und Reverse Lookup-Zone wurde jeweils der Name sowie die IP-Adresse angegeben.

Jedoch brachte dies alles kein Erfolg.
Die Webseite von dem Linux-Webserver lädt immer noch nach 6-12 sec.
In den Error bzw. CustomLogs steht nichts brauchbares für dieses Problem.

Was haben wir falsch gemacht?
Muss der Webserver in die Windows-Domäne integriert werden?
Kann es an der resolv.conf liegen bzw. an den Virtuellen Hosts vom Apache?

MFG Daniel

Content-ID: 169091

Url: https://administrator.de/forum/debian-apache2-webserver-timeout-dns-problem-windows-domaene-169091.html

Ausgedruckt am: 23.12.2024 um 03:12 Uhr

runlevel2
runlevel2 04.07.2011 um 21:07:17 Uhr
Goto Top
Hi Daniel,

folgende Ideen:

- Was sagt ein Ping vom Webserver in die aussenliegenden Standorte?

- Von beiden Richtungen einen Traceroute laufen lassen und die Route anschauen.

Wenn DNS paßt, hat das mit der Domäne wenig zu tun.

- Wie sind die Virtuellen Hosts konfiuriert; bzw sind diese im DNS eingetragen?

Grüße, Kurt
dankumc
dankumc 04.07.2011 um 21:20:21 Uhr
Goto Top
ping ist im normalen bereich. 1ms in beide richtungen
tracert passt zumal es erst mal nur um die 1 domäne geht. die anderen standorte sind vorerst uninteressant.

Virtuelle Hosts sind ip-basiert aufgebaut und im dns eingetragen (forward und reverse lookup)
Auf Wunsch poste ich morgen den resolv.conf und 1 Virtual Host-Datei.

Gibt es eine Beschränkung bei der Vergabe von IP-Adressen unter /etc/network/interfaces
Hier ist die Rede von 3: Assuming that you interface is eth0, you can assign three IP addresses editing /etc/network/interfaces similar
(siehe hier: http://wiki.debian.org/NetworkConfiguration#Howto_assign_multiple_IP_ad ... )
Ich habe insgesamt 4 interfaces vergeben. Dabei habe ich bei jedem einzelnen das Gateway, Broadcast und den nameserver angeben.

Auf Wunsch poste ich die Datei ebenfalls morgen
runlevel2
runlevel2 04.07.2011 um 21:44:17 Uhr
Goto Top
Zitat von @dankumc:

Gibt es eine Beschränkung bei der Vergabe von IP-Adressen unter /etc/network/interfaces
Hier ist die Rede von 3: Assuming that you interface is eth0, you can assign three IP addresses editing /etc/network/interfaces
similar
Offenbar gibt es eine Beschränkung. Steht was im Syslog oder in den Boot-Meldungen?

(siehe hier: http://wiki.debian.org/NetworkConfiguration#Howto_assign_multiple_IP_ad ... )
Ich habe insgesamt 4 interfaces vergeben. Dabei habe ich bei jedem einzelnen das Gateway, Broadcast und den nameserver angeben.

Gesehen?: "Note that gateway is only assigned to eth0. If you include dns-nameservers, it should also only be specified for eth0."


Vorschlag: Lass den Server mit nur 1 Virtuellen Hosts und nur eth0 laufen und schau, ob sich was ändert.

Gruss, Kurt
dankumc
dankumc 04.07.2011 um 21:50:22 Uhr
Goto Top
Habe ich schon gesehn aber mir noch nichts dabei gedacht. Ich werde auch das morgen mal testen und die Dateien posten.

Wo finde ich die Syslog-Meldungen und die Bootmeldungen?
runlevel2
runlevel2 05.07.2011 um 08:31:58 Uhr
Goto Top
Syslog:
less /var/log/syslog

Bootmeldungen:
dmesg | less
dankumc
dankumc 05.07.2011 um 08:42:54 Uhr
Goto Top
hier sind erst mal die interfaces /etc/network/interfaces

  1. The loopback network interface
auto lo
iface lo inet loopback

  1. the primary network interface
allow-hotplug eth0
auto eth0

iface eth0 inet static
address 192.168.100.x
netmask 255.255.255.0
broadcast 192.168.100.255
gateway 192.168.100.x
dns-nameservers 192.168.100.x
dns-search DOMÄNE

  1. the secondary network interface
auto eth0:0
iface eth0:0 inet static
address 192.168.100.x
netmask ..
broadcast ..
dankumc
dankumc 05.07.2011 um 08:49:54 Uhr
Goto Top
und das sind die virtual hosts (etc/apache2/sites-enabled/intern):

<VirtualHost 192.168.100.60:80>

Servername intern.Domäne.de
ServerAdmin xx

DocumentRoot /var/www/intern

ErrorLog /var/log/apache2/intern_error.log
CustomLog /var/log/apache2/intern_access.log combined

<Directory /var/www/intern>
Options Indexes FollowSymLinks MultiViews
AllowOverride None
Order allow,deny
Allow from all
</Directory>

</VirtualHost>


In den Syslog ist nichts relevantes zu finden: anbei ein screenshot: http://imageshack.us/photo/my-images/215/screensyslog.png/
das sind die meldungen fürs booten: http://imageshack.us/photo/my-images/715/screenboot.png/

was ich beobachtet habe ist, dass bei einem Aufruf der Webseite z.b. http://intern.DOMAIN.de/index.html schneller geht als die Adresse ohne index.html
runlevel2
runlevel2 05.07.2011 um 09:13:50 Uhr
Goto Top
Im Syslog stehen einige "withdrawing"-Meldungen, die vermutlich die Interfaces betreffen.

Wie gesagt, um das auszuschließen, würde ich den Server mit einem Interface und einem Virt Host laufen lassen und erneut testen.

Grüße, Kurt
dankumc
dankumc 05.07.2011 um 09:27:23 Uhr
Goto Top
ich habe jetzt nur 1 ip-adresse im interface angegeben und den virtual host angepasst.
die webseite ist im browser nicht unbedingt schneller..

Anbei ein Auszug der Ladezeit mithilfe von Firebug im Firefox: http://imageshack.us/photo/my-images/834/firebugs.png/

Was mir auffällt ist, dass die Webseite schneller im Firefox lädt als im IE8.
beim IE brauch der knapp 4-8sec. beim firefox 3-6sec.

Leider haben aber fast 98% aller Rechner einen IE ;(
runlevel2
runlevel2 05.07.2011 um 09:55:52 Uhr
Goto Top
OK, das ist schonmal was. Immerhin hat sich die Ladezeit verkürzt. Hast Du die Tests auch mit leeren Browsercache gemacht?

Bisher kann ich nur mutmaßen. So ein Netzwerk-Setup hatte ich noch nicht. ...und bis jetzt in diesem Forum auch noch niemandface-wink.

Wenn hier Dein Problem liegt, solltest Du dir namensbasierte Virtuelle Hosts anschauen. Da brauchst Du nur eine IP und der Rest geht über DNS.

Gruss, Kurt
dankumc
dankumc 05.07.2011 um 10:08:43 Uhr
Goto Top
ich leere den browser cache immer bei jeder änderung face-smile

sry aber namensbasierte kommt für mich aus organisatorischen gründen nicht in frage.
runlevel2
runlevel2 05.07.2011 um 10:30:08 Uhr
Goto Top
Zitat von @dankumc:
ich leere den browser cache immer bei jeder änderung face-smile

sry aber namensbasierte kommt für mich aus organisatorischen gründen nicht in frage.
Dann wäre ein weiteres physikalisches Interface angesagt, wenn es daran liegt.

Kurt
dankumc
dankumc 05.07.2011 um 11:28:29 Uhr
Goto Top
meinst du einen hardwaretausch oder nur eine erweiterung??

dem virtualhost ist es doch egal, von welcher ip-adresse (netzwerkkarte) der gestartet wird.

ich denke es liegt dennoch am dns-server bzw. an der tatsache, dass das debian webserver nicht in der windows-domäne ist.
runlevel2
runlevel2 05.07.2011 um 11:32:27 Uhr
Goto Top
Ich meinte damit die Beschränkung auf 3 Adressen pro Interface; also eine Erweiterung. Damit Du 4 Adressen vergeben kannst.

Happy testing
dankumc
dankumc 05.07.2011 um 11:37:59 Uhr
Goto Top
ich habe schon einen minimalen erfolg erzielt nachdem ich die interfaces angepasst habe.
da kommt es momentan nicht auf eine 2. karte drauf an.
ich will das die webseite in erster linie schneller lädt - da ist die 2. karte nebensache face-smile
runlevel2
runlevel2 05.07.2011 um 11:54:49 Uhr
Goto Top
Mit tcpdump oder Wireshark könntest Du noch den Netzwerk-Verkehr mitschneiden. Am besten auf dem Server tcpdump auf Port 80 laufen lassen. Wireshark benötigt eine grafische Oberfläche.

Kurt
dankumc
dankumc 05.07.2011 um 12:01:09 Uhr
Goto Top
ja das wäre eine möglichkeit. ich habe es mit tcpdump probiert und außer "who has ip_adress" nicht groß gefunden (zumal die ip-addressen alle bei uns im subnetz liegen..)
runlevel2
runlevel2 05.07.2011 um 12:20:20 Uhr
Goto Top
tcpdump -v oder -vv oder -vvv schon probiert?
dankumc
dankumc 05.07.2011 um 13:16:59 Uhr
Goto Top
ja habe ich. aber selbst da habe ich nichts brauchbares gefunden. was wäre denn auffällig?
runlevel2
runlevel2 05.07.2011 um 20:56:15 Uhr
Goto Top
Alles, was Zeit kostet. Also z. B. wiederholte Anfragen, nicht erreichbare Netze, Timeouts aufgrund von Firewalls, etc.

Dann bleibt noch IE versus Firefoxface-wink.
dankumc
dankumc 06.07.2011 um 08:57:23 Uhr
Goto Top
FF3+ lädt schneller nur haben leider 98% der Mitarbeiter den IE8.
bei den zig hundert einträgen bekommt man ja die krise, weil man die nicht richtig sortieren/filtern kann.
auf den ersten blick ist mir nichts merkwürdiges aufgefallen.
es gibt ein paar who-has-ip-adress probleme aber ansonsten sind die flags als correct gekennzeichnet
runlevel2
runlevel2 06.07.2011 um 10:42:45 Uhr
Goto Top
Hi,
Zitat von @dankumc:
FF3+ lädt schneller nur haben leider 98% der Mitarbeiter den IE8.
Immerhin kommst Du mit Firefox auf gute Ladezeiten. Dann sollte das Netzwerk soweit stabil sein.


bei den zig hundert einträgen bekommt man ja die krise, weil man die nicht richtig sortieren/filtern kann.
auf den ersten blick ist mir nichts merkwürdiges aufgefallen.
es gibt ein paar who-has-ip-adress probleme aber ansonsten sind die flags als correct gekennzeichnet
Diese Adressen würde ich mir näher anschauen. Vielleicht gibt es noch woanders Probleme.

Gruss, Kurt
dankumc
dankumc 06.07.2011 um 12:21:29 Uhr
Goto Top
ich glaube nicht das es mit dem netzwerktraffic zu tun hat sonden der timeout/verzögerung muss beim webserver? liegen
runlevel2
runlevel2 07.07.2011 um 08:45:17 Uhr
Goto Top
Zitat von @dankumc:
ich glaube nicht das es mit dem netzwerktraffic zu tun hat sonden der timeout/verzögerung muss beim webserver? liegen
Möglich. Hast Du schonmal die Antwortzeiten bei einer statischen Seite getestet?

Kurt