1Blu massiv hoher Paketverlust

Noujin

Noujin

New Member
Hallo,
ich miete nun schon seit ungefähr einem Jahr einen VPS mit Ubuntu bei 1Blu zur Bereitstellung von Teamspeak, Webserver und co. Dabei hatte ich schon mal für eine Stunde (in der Regel weniger) Paketverlust sodass wir auf einen anderen Teamspeak ausweichen mussten jedoch dauert der letzte Vorfall nun schon 2 Tage an und es ist kein Ende oder Besserung in Sicht.
Ich habe bereits den Support kontaktiert, aber der konnte keine Probleme feststellen (wie immer). Er hat mir jedoch geraten ihm Ergebnisse eines Traceroutes zu schicken. Dabei kam vom Server zu "google.com" das hier heraus:

MOD: Bilder bitte immer als Anhang. Danke!

Von meinem Privat PC zu dem Server das hier:

MOD: Bilder bitte immer als Anhang. Danke!

Ich verstehe nicht wirklich viel von Netzwerken und sehe einfach keine Logik in der Sache. Der Paketverlust tritt auch nicht nur von mir zum Server auf sondern auch bei etwa 8 anderen Leuten aus ganz Deutschland. Derzeit warte ich noch auf eine Antwort vom Support.

Wenn ich die Paketgröße beim Traceroute auf etwa >1500 stelle, erhalte ich keinerlei Antwort. Ist das normal?

Ich hoffe ihr könnt mir helfen.


MfG
 

Attachments

  • cZx6gDo.png
    cZx6gDo.png
    18.4 KB · Views: 253
  • wo355Fx.png
    wo355Fx.png
    10.5 KB · Views: 245
Last edited by a moderator:
Solange beim letzten Hop kein Packet Loss gibt ist alles ok.
Es gibt Router die nur eine bestimmte Anzahl von Pings beantworten oder dies gar nicht tun.
Daher kommt dann der vermeintliche Packet Loss.
 
Danke erstmal für die Antworten und eure Zeit :)

Das verstehe ich an der ganzen Sache ja auch überhaupt nicht. Sobald ich auf den Teamspeak joine habe ich einen Paketverlust von 30%-100%. Genauso wenn ich einen Counter Strike Gameserver hoste. Dort wird im Spiel ein genauso hoher Paketverlust angezeigt.
Die Auslastung des Servers ist minimal und es hat das ganze letzte Jahr so funktioniert ohne jeglichen Verlust von Paketen. Ich habe auch den Server schon einmal neu installiert gestern Nacht um Probleme meiner Seite auszuschließen.
 
Kannst du mir die IP mal per PN schicken?
Dann schaue ich mal, ob ich packetloss sehe.

E: Danke für die PN. Ich sehe weder von Holland, noch von meinem privaten DTAG-Anschluss oder einem Hetzner-Server (RZ19) packetloss.
 
Last edited by a moderator:
Wie gesagt, per Traceroute sehe ich anscheinend auch nichts. Ich sehe den Paketverlust halt auch nur über Teamspeak und Gameserver. Falls du Teamspeak auf dem Rechner hast würde ich mich freuen wenn du mal versuchen würdest zu connecten. Da müsste dir der Paketverlust auffallen wenn du in deine Verbindungsinformationen reinschaust.
 
Der Packetloss ist ja mal richtig dreckig.
Nach knapp 1:30m flieg ich ausm Teamspeak mit der Meldung "Connection lost" und anschließend wird wieder reconnected.

Hierbei baut sich der packetloss rasant auf, siehe Anhang.
 

Attachments

  • teamspeak.png
    teamspeak.png
    16.1 KB · Views: 427
Jup, genau unsere Erfahrung... Ich habe vor dem Auftreten des Problems keinerlei Änderungen vorgenommen. Kann es sein, dass ab einer bestimmten Paketgröße ein Problem auftritt wegen eines anderen Benutzers der dem gleichen Server zugeteilt wurde?
 
Kann es vielleicht sein das 1blu da irgendwas UDP störendes neu im Netz hat? So in die Richtung DDoS Protection oder so? Ich hatte selber mal eine Firewall mit UDP Floodprotection vor meinem Server und da gabs auch massiv Packetloss im Teamspeak. An der vServer Konfig scheint es ja nicht zu liegen wenn du sogar schon neu installiert hast.
 
Ich werde morgen mal mit dem Support quatschen, danke für die Benennung des wahrscheinlichen Problems. Da habe ich noch so einiges zu lernen :P

Ich werde mich morgen nochmal melden wie es lief!
 
Man kann Traceroutes auch per UDP machen - vielleicht wäre das mal eine Idee ;)

Mit "mtr -u" läuft der MTR per UDP - dann allerdings nur eine Instanz gleichzeitig, sonst kommt er durcheinander.
Alternativ kann man auch einen bestimmten Port angeben. Wenn du mir deine IP und den TS-Port zukommen lässt, kann ich hier von verschiedenen Systemen aus testen, wie hoch der Paketloss auf einem bestimmten Port ist.

Unter Linux lautet der Befehl dafür:
traceroute -U -p DEIN-TS-PORT -q 10 SERVER-IP

Btw: Ruckelnde SSH-Sessions hast du nicht? Dann ist da kein genereller Packetloss (denn die SSH-Pakete kommen ja störungsfrei durch) sondern wirklich nur auf bestimmten Protokollen oder Ports.
 
NACHTRAG:
Ich habe die IP bekommen und mal getestet.
Entweder bei dir auf dem System oder auf dem Host von 1Blu wird Rate-Limiting auf UDP angewendet...

Beispiel Traceroute:
Ich habe DST-Port 53 genutzt, da ich auf Port 9987 garkeine Antwort bekam (weil der TS offenbar mit den praktisch leeren Paketen nichts anfangen kann).
Code: 
traceroute to XXXXXXX (XXXXXXXXX), 30 hops max, 60 byte packets
 1  87.186.224.133 (87.186.224.133)  18.122 ms  18.739 ms  18.702 ms  18.660 ms  19.051 ms  19.016 ms  18.976 ms  18.929 ms  19.342 ms  19.306 ms
 2  87.190.178.146 (87.190.178.146)  24.532 ms  24.496 ms  24.699 ms  24.660 ms  24.620 ms  24.575 ms  22.509 ms  22.057 ms  22.238 ms  22.199 ms
 3  f-ed5-i.F.DE.NET.DTAG.DE (217.5.95.30)  23.920 ms  24.515 ms  24.470 ms  24.430 ms  24.626 ms  24.842 ms  24.069 ms  24.387 ms  24.263 ms  24.160 ms
 4  194.25.211.107 (194.25.211.107)  24.095 ms  24.486 ms  23.933 ms  23.621 ms  23.941 ms  24.160 ms  24.091 ms  23.620 ms  23.869 ms  23.835 ms
 5  ae4.c1.mk.de (213.172.99.25)  24.410 ms  24.783 ms  23.975 ms  23.918 ms  24.290 ms  24.424 ms  24.108 ms  24.013 ms  24.060 ms  24.217 ms
 6  te0-0-0.g1.blubone.net (213.172.99.150)  24.537 ms  24.522 ms  24.198 ms  24.601 ms  24.514 ms  24.664 ms  24.211 ms  24.207 ms  24.542 ms  24.802 ms
 7  te1-1-2.c2.blubone.net (178.254.16.26)  25.462 ms  26.660 ms  26.621 ms  26.578 ms  26.525 ms  26.492 ms  26.442 ms  26.660 ms  26.358 ms  26.577 ms
 8  vh64-9022.1blu.de (178.254.25.6)  25.967 ms  25.908 ms  26.025 ms  24.259 ms  23.857 ms  24.301 ms * * * *
 9  vXXXXXX.1blu.de (XXXXXXXX)  25.509 ms  25.475 ms  25.912 ms  25.867 ms  24.226 ms * * * * *
Der gleiche Traceroute per TCP oder ICMP geht problemlos durch.
Ich habe dann auch mal ganz unverbindlich deinen Nameserver (da solltest du dir evtl. auch überlegen, ob der so erreichbar sein muss) alle 0.3 Sekunden gefragt - und auch der hat mir nur sehr selten Antwort gegeben.
In der von dir verwendeten BIND-Version ist allerdings noch kein Abfragelimit integriert - will heißen, wenn da der Nameserver nicht antwortet, muss das durch eine Firewall vorgefiltert worden sein.

Code: 
16:36:57.664769 IP 93.208.233.147.58836 > XXXXXXXXX.53: 3245+ NS? . (17)
16:36:57.689153 IP XXXXXXXXX.53 > 93.208.233.147.58836: 3245 Refused- 0/0/0 (17)
16:36:57.716919 IP 93.208.233.147.40600 > XXXXXXXXX.53: 40086+ NS? . (17)
16:36:58.716768 IP 93.208.233.147.40600 > XXXXXXXXX.53: 40086+ NS? . (17)
16:36:59.716889 IP 93.208.233.147.40600 > XXXXXXXXX.53: 40086+ NS? . (17)
16:36:59.741647 IP XXXXXXXXX.53 > 93.208.233.147.40600: 40086 Refused- 0/0/0 (17)
16:36:59.768902 IP 93.208.233.147.39731 > XXXXXXXXX.53: 40604+ NS? . (17)
16:36:59.794121 IP XXXXXXXXX.53 > 93.208.233.147.39731: 40604 Refused- 0/0/0 (17)
16:36:59.823124 IP 93.208.233.147.39181 > XXXXXXXXX.53: 19971+ NS? . (17)
16:37:00.823075 IP 93.208.233.147.39181 > XXXXXXXXX.53: 19971+ NS? . (17)
16:37:01.823214 IP 93.208.233.147.39181 > XXXXXXXXX.53: 19971+ NS? . (17)
16:37:02.850177 IP 93.208.233.147.35016 > XXXXXXXXX.53: 54803+ NS? . (17)
16:37:03.850048 IP 93.208.233.147.35016 > XXXXXXXXX.53: 54803+ NS? . (17)
16:37:04.850185 IP 93.208.233.147.35016 > XXXXXXXXX.53: 54803+ NS? . (17)
16:37:05.878301 IP 93.208.233.147.47961 > XXXXXXXXX.53: 61398+ NS? . (17)
16:37:06.878233 IP 93.208.233.147.47961 > XXXXXXXXX.53: 61398+ NS? . (17)
16:37:07.878345 IP 93.208.233.147.47961 > XXXXXXXXX.53: 61398+ NS? . (17)
16:37:08.905267 IP 93.208.233.147.43234 > XXXXXXXXX.53: 64724+ NS? . (17)
16:37:09.905192 IP 93.208.233.147.43234 > XXXXXXXXX.53: 64724+ NS? . (17)
16:37:10.905288 IP 93.208.233.147.43234 > XXXXXXXXX.53: 64724+ NS? . (17)
16:37:10.929561 IP XXXXXXXXX.53 > 93.208.233.147.43234: 64724 Refused- 0/0/0 (17)
16:37:10.958277 IP 93.208.233.147.60851 > XXXXXXXXX.53: 24569+ NS? . (17)
16:37:11.958220 IP 93.208.233.147.60851 > XXXXXXXXX.53: 24569+ NS? . (17)
16:37:12.958345 IP 93.208.233.147.60851 > XXXXXXXXX.53: 24569+ NS? . (17)
16:37:13.985324 IP 93.208.233.147.42678 > XXXXXXXXX.53: 11266+ NS? . (17)
16:37:14.009805 IP XXXXXXXXX.53 > 93.208.233.147.42678: 11266 Refused- 0/0/0 (17)
16:37:14.038555 IP 93.208.233.147.48731 > XXXXXXXXX.53: 26826+ NS? . (17)
Der Packetloss wird sehr wahrscheinlich durch wildes Rate-Limiting verursacht, allerdings ist die Frage noch nicht 100%ig geklärt, wo die Filter ansetzen.

Je nach Virtualisierungstechnik kann der Hoster dir selbst iptables-Regeln in die VM schmeißen - kannst du die vorhandenen Regeln einmal dumpen und nachsehen, ob da Rate-Limitings konfiguriert sind?
Am besten mit "iptables -S", damit werden dann wirklich alle Regeln ausgegeben.
 
Last edited by a moderator:
Die Virtualisierung läuft per Parallels und die Firewall ist auf Default Accept. Das Betriebssystem habe ich ja auch schon neu installiert und von daher sehe ich das Problem eher bei 1Blu.
Hier die IP-Tables:
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-N VZ_FORWARD
-N VZ_INPUT
-N VZ_OUTPUT
-A INPUT -j VZ_INPUT
-A FORWARD -j VZ_FORWARD
-A OUTPUT -j VZ_OUTPUT
Click to expand...
 
Ich habe schon in OpenVZ-Containern gearbeitet, wo iptables-Regeln durch den Host vorgegeben wurden. Die waren dann einfach da und verschwanden auch einfach mal wieder :(

Aber so wie es aussieht würde ich sagen, da hat ein übereifriger Techniker ein bisschen viel Traffic zum Abschuss freigegeben. Ich deute den Traceroute so, dass da auf dem Host gefiltert wird und dadurch die Pakete garnicht erst bei dir ankommen. Das könnte man noch mit tcpdump auf Serverseite verifizieren, aber ich denke, es ist die Zeit gekommen, wo du bei 1Blu mal zaghaft nachfragen solltest, ob das nun ein Feature oder ein Fehler ist ;)

Ich könnte mir vorstellen, dass da auf dem Host ausgehend UDP limitiert wird und die Filter nicht pro VM sondern für den gesamten Host zählen. Bei 20 Nachbarn ist dann das Limit schon schnell erreicht...
 
Noujin said:
Die Virtualisierung läuft per Parallels und die Firewall ist auf Default Accept.
Click to expand...

Hast du mal versucht die Firewall von und in Virtuozzo komplett zu deaktivieren?
Vor einiger Zeit hatte ich mal einen Kunden der ähnliche Probleme mit seinem DNS und dessen Erreichbarkeit hatte. Ebenfalls bei 1Blu.

Lord Gurke hat es ja sehr schön unten aufgeführt :)

Das deaktivieren der Firewall und manuelle Anlegen von Rules hat damals wahre Wunder bewirkt.

Grüße
 
In meiner Verpeiltheit dachte ich natürlich auch noch, dass heute Montag wäre... Also doch erst morgen da anrufen. Habe zwar noch eine E-Mail mit Verweis auf den Thread hier verschickt aber ich finde es schon unter aller Sau wie ich da übergangen werde.
Ich danke dir für deine ausführlichen Berichte :)


MfG


//edit:

Sehe gerade erst die Antwort von dir Knoppers. Die Firewall ist so eingestellt wie sie von 1Blu ausgeliefert wird und ich habe auch die anderen Modi versucht, jedoch weiß ich nicht genau ob man sie auch ganz ausstellen kann. Ich denke mal der Modus "Default: Accept" kommt dem gleich wenn er dann nichts spezielles abweist. Ich werde mich mal schlauer machen!
 
Last edited by a moderator:
Im Auslieferzustand war die Firewall auch aktiviert. Über das Virtuozzo konnte man den irgendwo den Firewall Dienst komplett beenden. Schau aber vorher das du eine SSH Verbindung derweil zum Server hast um notfalls die Rules Manuell zu löschen. Kam hin und wieder vor das ich keine neuen Sessions nach dem Deaktivieren der Firewall starten konnte und so Rebooten musste - sehr nervig.

Bei meinem damaligen Kunden hatte erst das komplette deaktivieren der FW den gewünschten Effekt gebracht. Auch das setzen der Accept Rule half nicht.

Ich habe leider kein Virtuozzo mehr zur Hand wo ich auf kurzem Dienstweg mal nachschauen könnte, sorry.

Sollten aber Rules vom Hoster gesetzt werden bist du leider auch hier machtlos.
 
Ich gehe stark davon aus, dass das 1blu diese Regeln zwar bewusst, aber nicht mit dieser Absicht gesetzt hat. Da DDoS größtenteils per UDP stattfindet, wird hier oftmals schon routerseitig nach typischen Angriffsmustern gefiltert. Standarddienste kommen meistens auch damit klar, aber bei Voice- und (wesentlich schlimmer) Gameservern ist es oftmals schwierig, vernünfigte Werte zu finden. Gerade bei rein "statischen" Werten. Richtige Hardware-Appliances können da natürlich mehr leisten als ein paar iptables :) Aber auch hier muss ständig "nachtrainiert" werden.
 
So ist der Server zumindest nutzlos für mich. Über ein Jahr hat der Server mir ja gute Dienste geleistet. Es lief alles problemlos und nun wird mir vom Support erzählt ich solle doch mal vernünftige Logs herzeigen wenn ich den Thread hier verlinke. Nach meckern hat man mir nun eine Antwort der Techniker noch für heute versprochen. Yippie... Mal sehen.


//edit: 1blu hat das System nun auf einen anderen Wirt gesetzt und nichts weiter zu dem Problem erklärt. Naja, ich hoffe nur der nächste Kunde kriegt das Problem nicht aufgeschoben. Ich danke hier allen für eure Hilfe!
 
Last edited by a moderator:
You must log in or register to reply here.
Back
Top