PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Debian Apache2 Webserver, DNS-Problem Windows Domäne



gast12
05.07.11, 06:52
hallo an alle ;)
Wir nutzen einen Webserver, welcher nur innerhalb unseres VPNs (Domänen-Netzwerk) erreichbar ist. Beim Zugriff auf die 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.

=============================
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

muell200
05.07.11, 10:14
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.


du musst den fehler weiter eingrenzen!!!!

was laueft alles mit joomla?

- welches template testen
- joomla ohne erweiterungen testen
- anderer browser
...

tippe das es an jommla liegt....
-> auf wunsch erstelle ich ein template, das schneller ist :)

gast12
05.07.11, 10:31
wer lesen kann ist im vorteil :)

das joomla 1.6.3 template von joomlart ist mit 300kb recht groß. die webseite besteht wie gesagt fast nur aus text und einigen bildern (<20kb).
ich habe aber den vergleich zu peer-to-peer (siehe 1. Konfiguration) und da ist die seite auch schnell genug.

es liegt nicht am browser!!! der firefox lädt die seite 1-2 sec. schneller. das hilft mir aber relativ wenig, da 98% aller rechner den ie 8 haben.

muell200
05.07.11, 10:42
wer lesen kann ist im vorteil :)


habe den text nur ueberflogen, das war mir zuviel :)



ich habe aber den vergleich zu peer-to-peer (siehe 1. Konfiguration) und da ist die seite auch schnell genug.


was passiert, wenn du die seite mit der ip ansprichst?
wir brauchen mehr details....
werden externe frame eingebunden?
usw....

gast12
05.07.11, 10:46
auch das steht oben im text!!

========================
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.

muell200
05.07.11, 10:53
auch das steht oben im text!!


mhhh - nein, das ist kein test! bzw. ich wurde eine seite nicht "so" testen...

bist du dir 100% sicher, das joomla oder ein modul im hintergrund keine dns abfragen stellt.

sorry, das ich so bloede frage stelle, aber mit deinen angaben ist es nur ein ratespiel....

zb.: wo laueft die db?

gast12
05.07.11, 10:59
auch das steht im text. man eh. auf einem debian 6 amd64.

und ja die seite wird so getestet!

deswegen habe ich auch 2 verfahren angewendet (siehe 1. und 2. configuration)

muell200
05.07.11, 11:10
du bist ja neu hier...
erstmal willkommen auf dem board...


auch das steht im text. man eh. auf einem debian 6 amd64.


NEIN - steht nicht im text! uns interessiert die config / einstellungen...

ES GEHT NICHT IST KEINE FEHLERMELDUNG




und ja die seite wird so getestet!


ok - dann mache ich sei(d)t was falsch...

also, wenn du hilfe erwartet, dann poste relevante info!

gast12
05.07.11, 11:12
hallo? gehts noch?? ich habe nie gesagt es geht nicht. man man. ich bin it-systemadministrator und das wäre das letzte was ich fragen würde.
ich habe alle gesichtspunkte vorgetragen und die möglichkeiten wo vielleicht das problem liegen könnte.

muell200
05.07.11, 11:19
ich habe alle gesichtspunkte vorgetragen und die möglichkeiten wo vielleicht das problem liegen könnte.

sorry das hast du nicht...
ich habe noch keine config gesehen.
du hast immer noch nicht gesagt, wo die db laueft.
welche vpn
welche routen
was passiert wenn du den server per ip ansprichst...


oder sollen wir raten?

gast12
05.07.11, 11:25
welche config wird denn gewünscht?

virtual-host:
<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>

Interfaces:
# The loopback network interface
auto lo
iface lo inet loopback


# 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


# the secondary network interface
auto eth0:0
iface eth0:0 inet static
address 192.168.100.x
netmask ..
broadcast ..

Die mysql-Datenbank wird im phpmyadmin verwaltet.
VPN ist noch nicht wichtig, sondern ich würde gern erst einmal nur 1 Domäne betrachten (die Außenstellen werden erst später überprüft)
der ping von und zum webserver wird mit 1ms quittiert

muell200
05.07.11, 11:45
meine frage wurde noch immer nicht beantwortet...

was passiert wenn du den server per ip ansprichst...



Servername intern.Domäne.de


kann der server den dns vom client aufloesen?



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.

wie meldet sich ein client am dns-server 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.


wie sind die netzwerkeinstellungen?



Die mysql-Datenbank wird im phpmyadmin verwaltet.


nochmal: wo laueft die db?



VPN ist noch nicht wichtig, sondern ich würde gern erst einmal nur 1 Domäne betrachten (die Außenstellen werden erst später überprüft)


sorry - jetzt kann ich dir nicht mehr folgen
du schreibst doch, das genau da das problem liegt?
ueber das lokale netzt ist alles ok, aber ueber vpn ist es langsam - oder




der ping von und zum webserver wird mit 1ms quittiert

ping ist kein test - aber das weisst du bestimmt als it-systemadministrator...

gast12
05.07.11, 12:16
meine frage wurde noch immer nicht beantwortet...

was passiert wenn du den server per ip ansprichst...
client - webserver ping 1ms
webserver -client ping 1ms
dns-server -webserver ping 1ms
webserver - dns-server ping 1ms

kann der server den dns vom client aufloesen?
ja

wie meldet sich ein client am dns-server an? :)

als Domänenbenutzer


wie sind die netzwerkeinstellungen?
statisch mit DNS- und Gateway Eintrag


nochmal: wo laueft die db?
local auf dem Webserver


sorry - jetzt kann ich dir nicht mehr folgen
du schreibst doch, das genau da das problem liegt?
ueber das lokale netzt ist alles ok, aber ueber vpn ist es langsam - oder




ping ist kein test - aber das weisst du bestimmt als it-systemadministrator...
is klar, aber damit weißt du anhand der reaktionszeit schon einmal ob und "wie schnell" der server die anfrage quittiert


sry wenn ich mich manchmal missverständlich ausgedrückt habe.
wahrscheinlich berufskrankheit :)

ctFreez
05.07.11, 12:40
Moin,

6 bis 8 sec. ladezeit / verzögerung klingt nach einem Timeout:
- Protokoll wechsel IPv6 -> IPv4: beim Seitenaufbau und bei der DNS abfrage.
- DNS: welche DNS Server sind beim client eingetragen?

Gruß Felix

gast12
05.07.11, 12:44
wir verwenden momentan durch windows-xp noch ipv4. umstieg irgendwann geplant. nur 1 dns-server in den netzwerkeinstellungen eingetragen (winserver 2008r2). an ein timeout dachte ich auch schon. aber in keiner access bzw. error-log datei vom apache2 ist darüber ein vermerk zu finden

ctFreez
05.07.11, 13:08
Moin,

ich hatte auch eher an einen client seitigen timeout gedacht.
Guck doch mal mit wireshark was der client sendet und ob er auf irgendeinen request keine Antwort bekommt. Ausserdem kannst du so eher eingrenzen, ob das Problem beim DNS request auftritt, beim anfragen an den web Server oder beim übertragen der Daten.

Und nur um's aus zu schließen, check mal die mtu von allen beteiligten Interfaces.

gruß Felix

gast12
05.07.11, 13:43
den netzwerktraffic werde ich nachher mit tcpdump überprüfen.
was ist denn mtu? ich dachte es gibt einen max.wert (siehe http://www.debianhelp.co.uk/mtu.htm) welcher variabel eingestellt werden kann

ctFreez
05.07.11, 14:08
MTU = Maximum Transfer Unit
ich habe mal eine fehlerhafte verbindung gehabt, bei der die MTU falsch gesetzt war. Mit dem Ergebnis, das icmp und vpn funktienierte, aber ich keine Nutzdaten (http & mail) übertragen bzw. nur teilweise übertragen wurden.

Welches Programm du für die Traffic analyse benutzt, ist mir egal, dabei genügend aussagekräftige daten bei rum kommen.

Gruß Felix

gast12
05.07.11, 14:16
hast du die mtu falsch gesetzt oder wurde das vom system aus geändert? ich kann mir nicht vorstellen das ohne einem eingriff sich der wert ändern sollte.

also eth0 hat 1500 sowie eth0:0 und eth0:1 und ist somit standard (minimale abweichung von 1492)

ctFreez
05.07.11, 19:56
hmm 1500 passt so weit. Ich hab das bei einem Kabelmodem, das setzt die MTU nach X.25 auf 576 oder so. Da muss ich im startup per script eingreifen und die MTU fix auf 1500 setzen.

Was macht deine Traffic analyse?

Gruß Felix

gast12
06.07.11, 08:24
ich habe es mit tcpdump -v getestet.
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

ctFreez
06.07.11, 08:54
Moin,

dann tu dir den gefallen und installier auf einem Client Wireshark, da kannst du vernünftig filtern und fehlerhafte Pakete werden farblich gekennzeichnet.

Gruß Felix

muell200
06.07.11, 09:30
bei den zig hundert einträgen bekommt man ja die krise, weil man die nicht richtig sortieren/filtern kann.


das sind aber die fakten von deinem netz :)
sortieren: sollte doch einfach moeglich sein... ( grep, sort,... )

alternative schau dir mal dragonfly (http://www.opera.com/dragonfly/) von opera an
oder wie @ctFreez schon sagt wireshark...
obwohl als it-systemadministrator tcpdump informativer und genauer ist....

dann wurde ich doch einfach mal das netzwerk durchmessen!
oder hast du das schon gemacht?

gast12
06.07.11, 11:21
ich glaube nicht das es mit dem netzwerktraffic zu tun hat sonden der timeout/verzögerung muss beim webserver? liegen

ctFreez
07.07.11, 16:08
Moin,

ich teile nicht deine Meinung, das es am Webserver liegt, daher wirst du den weg alleine weiter vorfolgen müssen.
Sag bescheid, wenn du die Lösung gefunden hast, oder wenn du Hilfe bei der Traffic analyse brauchst.

gruß Felix

muell200
07.07.11, 16:53
Moin,

ich teile nicht deine Meinung, das es am Webserver liegt, daher wirst du den weg alleine weiter vorfolgen müssen.


:) ich auch nicht...
aber wie gesagt, dazu braucht man fakten...