Netzwerkprobleme / kein Verbindungsaufbau möglich

favo · n00b Joined: 15 Oct 2003 Posts: 18

Moin

Seit ein paar Tagen habe ich ein gentoo system laufen, welches zwar wunderbar läuft, aber Probleme unter Last hat.

Das Problem sieht so aus, das zwar Webabfragen für einen Zeitraum von mehreren Minuten oder Stunden durchgehend laufen. Aber dann immer wieder mal alle eingehenden connections fehlschlagen für die Dauer von mehreren Sekunden. Als wenn das System kurzzeitig offline wäre, allerdings betrifft das nur neue eingehende Verbindungen und nicht bestehende.
Ein Austausch des Webservers brachte keine Änderung, es liegt also nicht am http-daemon.

Das System läuft mit einem vanilla kernel 2.4.22.

Jemand eine Idee was es sein könnte oder an welcher Stelle ich mehr Informationen finden kann um den Fehler zu beheben?
Falls ihr mehr Info's braucht, sagts

Danke schonmal für jede Antwort & Hilfestellung

ruth · Posted: Wed Oct 15, 2003 5:56 pm Post subject:

moin,
also ich tippe jetzt mal wild ins blaue... ;-)

hast du an deiner arp tabelle gespielt?
was heisst unter last?
wieviele verbindungen werden den synchron benötigt?
also ich meine:
die arp tabelle hat nur einen bestimmten platz für einträge.
jede verbindung wird hier intern festgehalten.
der eintrag in die arp tabelle wird übrigens schon nach dem ersten schritt
des tcp/ip triple way handshake vorgenommen.
darauf beruhen verschiedene bestimmte angriffe auf server.
ich kann als angreifer z.b. eine verbindung aufbauen. -> ARP eintrag
diese verbindung breche ich schon vor dem ende des twh ab und initiiere eine neue von einem anderen rechner aus -> neuer ARP eintrag.
der kern lässt den arp eintrag zur abgebrochenen verbindung aber noch eine weile in der tabelle, denn es könnte ja sein, dass sich der gegenüber doch nochmal meldet... ( is das nicht nett von dem kernel ?? ;-)

)
wenn das schnell genug passiert, ist die arp tabelle voll, mit dem effekt, dass keine _neuen_ verbindungen aufgebaut werden können und die ganzen halboffenen verbindungen erst wieder aus der arptab fliegen müssen, was ein bisschen dauert...
bestehende verbindungen betrifft das nicht, da ja kein neuer arp eintrag hinzugefügt werden muss.
das ist so eine abart eines DOS angriffs.
oder du hast ein system vor dir, was du besser mit load-balancing handeln solltest ???
also, diese symptomatik wäre auf diese art durchaus zu erklären.
schau dir halt mal die tabelle an ;-)

btw: das ist jetzt wirklich _wild_ spekuliert, das alles, obwohl es deine symptomatik vollständig erklären würde... ;-)

aber zuerst:
beschreib mal dein system näher.
v.a. auch deine kernel konfiguration, verwendete protokolle, syslogs, usw
und alle webserver bieten ja die möglichkeit zu konfigurieren, wieviele clients maximal connecten dürfen - ist dieser wert zu klein ???

gruss
rootshell

favo · n00b Joined: 15 Oct 2003 Posts: 18

danke für die antwort erstmal

überraschend und schön so ausführlich schonmal empfangen zu werden mit dem problem

die concurrent connections kann ich dir nicht exakt nennen, laut netstat zwischen 600 und 700 mit TIME_WAIT und zwischen 20 und 30 ESTABLISHED .. das limit des webservers kann es nicht sein .. und ich denke das die niedrige anzahl an established connections nicht so hoch ist .. die time_waits sind allerdings maybe der reason den du ansprichst? das der kernel die verbindung noch etwas in seiner arp table hält um sie evt. nochmal zu verwenden?
wie betrachte ich die arp-table, ebenfalls via netstat?

die oben genannten zahlen 600/700 & 20/30 sind auch in etwa die, bei denen dann das problem aufkommt das "nichts mehr geht" und keine neue connection mehr möglich ist

kernel: vanilla 2.4.22
protokolle? reines http .. sogar nur statische seiten

webserver limit: wie gesagt, hoch genug und auch hardware des servers ist ausreichend (dual 2.4ghz/2GB/0% auslastung laut top)

arp table: nein, nicht daran gespielt

aber maybe beim kernel was schlank machen verwirbelt?

unter last? > ist im grunde keine wirkliche last, sondern nur die testweise in betriebnahme und damit die erste kleinere "auslastung" für diese bzw. entlastung für eine andere maschine zu übernehmen

danke schonmal für weitere hilfe

favo · n00b Joined: 15 Oct 2003 Posts: 18

sonst niemand eine idee was es sein könnte? oder in bezug auf rootshells "schuss ins blaue" noch etwas weiterführende ideen?

ruth · Posted: Fri Oct 17, 2003 1:57 pm Post subject:

moin,
also ohne der postings von konfigurationsdetails wie:
ausgabe von ifconfig, route, netstat -a, arp -a, bootlogs, serverlogs,
verwendete serversoftware, usw kann man halt nicht so viel sagen.
poste das doch mal.
und die entsprechenden befehlsausgaben wenns funktioniert und wenn nicht.... ;-)

also, mehr info, bitte
ich weiss ja nicht mal, welchen server du verwendest, ob eine fw drauf läuft ( ja, auch eine fw kann sowas machen, wenn sie entsprechend konfiguriert ist )
und ich meine damit die genaue ausgabe aus der shell gepastet... ,-)
tritt das problem nur bei dem webserver auf?
wieviele verbindungen sind per ssh / ftp / usw möglich?
u.u. codierst du dir ein teil, welches sich wild auf irgendwelchen ports verbindet, und dabei forke'd ?
so eine art killer - wget ?
keine ahnung, obs sowas schon gibt, vielleicht...
ich meine ein programm, welches z.b. 100 childs abgibt, von denen jedes eine verbindung versucht aufzubauen, zu bestimmten port, die du testen willst.
was sagt denn das webserver log, wenn keine zusätzliche verbindung möglich ist ? also, paste das mal, check die connections auf anderen port, wie diese sich verhalten....

gruss
rootshell

tacki · Guru Joined: 29 Jun 2002 Posts: 418 Location: Germany

steht ne firewall zwischen client->webserver?

wenn ja, wär die konfiguration auch nen blick wert...

favo · n00b Joined: 15 Oct 2003 Posts: 18

okayyyy ... dann mal step by step:

ifconfig

favo · n00b Joined: 15 Oct 2003 Posts: 18

tacki · Guru Joined: 29 Jun 2002 Posts: 418 Location: Germany

tacki · Guru Joined: 29 Jun 2002 Posts: 418 Location: Germany

probier mal folgendes...

starte den server neu, so dass keine offene verbindungen vorhanden sind (mit netstat prüfen), dann connectest du per ssh drauf und gehst dann gleich wieder runter. dann wieder per netstat schauen ob die verbindung sauber getrennt wurde oder noch als offen da steht...

favo · n00b Joined: 15 Oct 2003 Posts: 18

tacki · Guru Joined: 29 Jun 2002 Posts: 418 Location: Germany

das ist schonmal definitiv viel zu lang

wenn ich das hier an einem (heute installierten) gentoo-rechner mach, ist der connect beim schliessen des fensters auch sofort weg...

favo · n00b Joined: 15 Oct 2003 Posts: 18

wo kann ich es dann auf eine kürzere zeit reduzieren?

tacki · Guru Joined: 29 Jun 2002 Posts: 418 Location: Germany

das ist eine gute frage *g*

ich weiss es (noch) nicht, vielleicht per iptables.... hmm....

ruth · Posted: Fri Oct 17, 2003 3:36 pm Post subject:

moin nochmal,
also TIME_WAIT bedeutet, dass der socket ( des servers ) auf die
remote shutdown retransmission wartet.
d.h. die tcp/ip verbindung wurde _nicht_ normal beendet.
das passiert normalerweise so:
client sendet aktives CLOSE
Server reagiert darauf mit einem passiven CLOSE
Client ist jetzt in FIN_WAIT2
server sendet aus CLOSE_WAIT ein FIN
Server geht in LAST_ACK
Client sendet letztes ACK

wenn der Server dieses ACK erhält, beendet er die Verbindung.
wenn nicht, wartet er 2x MSL ab, ( ca. 1.minute ) *grins*
daraus folgt:
lowlevel tcp/ip debugging is angesagt:
musst dir 'n paar lowlevel tools besorgen; schau mal bei http://freshmeat.net
angefangen von nmap bis ....
setz mal n paar iptables rules, wo du den verkehr zwar loggst, aber durchlässt.
setz mal statt dem server einen traffic analyzer auf den port ( 80 )
dann kannst du genau verfolgen, an welcher stelle der tcp/ip verkehr zusammenbricht.
fahr die virtuellen interfaces runter.
hast du den kern manuell gebaut oder mit genkernel?
u.u. hardwareproblem???
mal andere karte versuchen?
und die MSL kannst du durch hacken des kernels reduzieren... *grins*
dazu musst du in /usr/src/linux/include/net/tcp.h
das preprocessor macro in zeile 317 ( ? ) editieren. ist kommentiert ;-)

favo · n00b Joined: 15 Oct 2003 Posts: 18

danke für die mühe

erstmal habe ich das gleiche auf zwei anderen maschinen nachvollzogen (reconnect mit SSH und check bei netstat), beides red hat maschinen und unterschiedliche kernel

ergebnis war das gleiche, noch ca. 60 sec wurde die connection mit TIME_WAIT aufgeführt und war danach erst "verschwunden"

.. hardwarefehler würde ich somit ausschliessen, ebenfalls im grunde eine änderung die ich via genkernel durchführte, jedenfalls in bezug auf die 60 sec

.. kernel hatte ich via genkernel auch neu kompiliert heute um testweise ohne iptables support zu schauen ob das problem dann noch fortbesteht, tat es leider

und eines dieser zwei eben erwähnten systeme hatte die gleiche software mit der gleichen konfiguration vorher laufen ohne das dieses problem auftrat

liegt evt. doch an einer anderen stelle?

ruth · Posted: Fri Oct 17, 2003 4:37 pm Post subject:

hallo,
die 60 sec TIME_WAIT sind dennoch falsch.. ( !! )
wenn eine verbindung _ordnungsgemäss_ abgebaut wird _gibt_es_keine_60_sec_ TIME_WAIT.
deine verbindung bricht _definitiv_ falsch ab.
u.u. ein problem mit dem switch? hub?
wenn ich bei meinen rechnern per ssh reingeh und die verbindung trenne,
taucht die verbindung auch nicht mehr auf, geschweige denn als TIME_WAIT.
da ist dein fehler ( !! )
bei einer ordnungsgemäss abgebauten verbindung _bleibt_der_server_NICHT_in TIME_WAIT

und definitiv verhalten sich auch deine redhat maschinen hier falsch. ( !! )
oder es kann auch an den clients liegen, die das letzte ACK nicht senden.
glaubs mir
überleg mal:
ca. 1300 Verbindungen in TIME_WAIT in einem _nicht ausgelasteten system.
hältst du das für normal? *grins*
neee, oder?
also:
tcp/ip lowlevel debug...

gruss
rootshell

favo · n00b Joined: 15 Oct 2003 Posts: 18

nein, natürlich ist das nicht normal, die red hats waren übrigens default install und liegen in einem gänzlich anderem netzwerk bei einem anderen provider .. womit hub & switch z.b. ausfallen würden als begründung .. sind beides dedizierte maschinen die bei einem anderen provider angemietet wurden

ich denke mir nur auf grund dessen, das dort die gleichen symptome zu sehen sind wie auf dem gentoo system und das problem aber nicht auftauchte, das es nicht daran liegt, sondern an etwas anderem?

für "low level debuggin" der connections werd ich morgen mal schauen und mich nach deinen vorschlägen richten

favo · n00b Joined: 15 Oct 2003 Posts: 18

ich muss mich erstmal in aller form entschuldigen, denn die tests die oben aufgeführt waren habe ich von zu hause aus mit einem router zwischendrin durchgeführt ... habe es eben von wo anders ausprobiert und die verbindungen waren sofort wieder geschlossen und weg .. der router zu haus war demnach der auslöser dafür das es bei allen drei unterschiedlichen servern passierte - sorry, daran hatte ich nicht gedacht wie ihr mich nach routern/hubs fragtet

ebenfalls habe ich den kernel kurzerhand gegen einen ähnlich konfigurierten se-2.4.21 ausgetauscht und das gleiche problem erneut erlebt

da ich den kernel mit gernkernel abgespeckt hatte liegt meine vermutung an irgendeiner stelle da, ist das auszuschliessen weil darauf niemand näher einging oder könnte es tatsächlich dort an etwas liegen?