Netzwerkstörungen vom 02.09. bis 05.09.

    Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

    • Netzwerkstörungen vom 02.09. bis 05.09.

      In den letzten Tagen hatten einige Spieler das Problem, dass sie immer mal wieder nach wenigen Minuten die Verbindung zum MTA-Server verloren haben.

      Nachdem wir schon nach kurzer Zeit davon erfahren haben, erfolgte sofort eine Meldung an unserem Provider, da das Problem in seinem Verantwortungsbereich liegt. Die Fehlersuche gestaltet sich jedoch schwieriger als sonst, unter anderem da für uns - wie an anderer Stelle schon berichtet - besondere Konfigurationen u.a. zur Qualitätssteigerung gelten und kein klares Muster bei den Verbindungsabbrüchen erkennbar ist. Die ungefähre Ursache konnte jedoch schnell ermittelt und andere Fehlerquellen ausgeschlossen werden.

      Da die genaue Analyse noch etwas Zeit in Anspruch nehmen kann und ich es nicht sinnvoll finde, wenn das Problem so lange noch besteht, wurde nach telefonischer Rücksprache am heutigen Tag eine temporäre Lösung gefunden. Diese Form der Verbindungsabbrüche sollte ab sofort erst einmal nicht mehr auftreten. Das bestätigt aktuell auch unser Monitoring.

      Eine genaue Auswertung und die Erarbeitung einer permanenten Lösung durch unseren Provider soll im Verlauf der nächsten Woche erfolgen. Da uns hierbei möglicherweise nichts anderes übrig bleibt, als während des laufenden Betriebs Änderungen vorzunehmen und die Auswirkungen zu beobachten, könnten diese Probleme unter der Woche natürlich kurzzeitig wieder auftreten. Wir versuchen das jedoch nicht gerade auf die Primetime zu legen.

      Sobald das abgeschlossen ist, werde ich ausführlicher berichten.

      Sorry für die Unannehmlichkeiten. :/
    • Kurzfassung:

      Seit der Aktivierung der temporären Lösung am Sonntag gegen 13:30 Uhr traten weder das Problem noch sonstige Störungen auf. Am heutigen Tag fand die angekündigte Analyse unseres Providers im Zeitraum von 15:47 bis 16:32 Uhr statt. Der MTA-Server war in dieser Zeit uneingeschränkt erreichbar. Lediglich ein Spieler war von Verbindungsabbrüchen betroffen. In dieser Zeit wurde der Traffic eingehend untersucht und die Ursache für die Störung zweifelsfrei ermittelt und behoben. Auch unser eigenes Monitoring bestätigt den Erfolg. Seitdem befindet sich unsere Netzwerkanbindung wieder im Regelbetrieb.

      Ursache (Achtung: An manchen Stellen sehr technisch):

      Am Mittwoch, dem 02.09. um 12:58 Uhr verzeichnete unser Monitoring den Verbindungsabbruch fast aller Spieler. Solche Auffälligkeiten kommen in der Regel sehr selten vor, weshalb wir sie direkt an unseren Provider eskalieren. Wir haben erfahren, dass zu dieser Zeit ein weiterer Carrier in Betrieb genommen wurde. Allerdings konnte durch fehlerhafte Präfixfilter des neuen Carriers kein Traffic weitergeleitet werden. Die BGP-Session blieb jedoch stabil. Das Problem konnte daher erst durch manuelles Beenden der BGP-Session behoben werden, weil aus Perspektive der Router unseres Providers die Session einwandfrei lief. Ab spätestens 13:03 Uhr war die Konnektivität wieder vollständig hergestellt.

      Um 20:36 Uhr hatten erneut einige Spieler einen Verbindungsabbruch. Die Ursache lag erneut an fehlerhaften Konfigurationen des neu angeschlossenen Carriers. Unser Provider entschloss sich dazu, die Verbindung zu diesem Carrier wegen der wiederholten Probleme zu trennen. Dadurch kam es erneut zu Verbindungsabbrüchen um 21:08 Uhr und 21:13 Uhr.

      Beide Störungen hatten jedoch nichts mit dem Problem der Verbindungsabbrüche zu tun, auch wenn sie am selben Tag einsetzten. Das stellte sich jedoch schnell als Zufall heraus. Von dieser Störung waren über den gesamten Zeitraum etwa 20 Spieler sehr stark betroffen. Weitere 20 Spieler hatten das Problem nur vereinzelt. Der überwiegende Teil der insgesamt fast 400 Spieler, die sich allein in diesem Zeitraum eingeloggt haben, war selbst überhaupt nicht betroffen. Das war aus zwei Gründen problematisch: Einerseits geht eine solch geringe Anzahl an abgebrochenen Verbindungen im Verhältnis zu korrekt funktionierenden Verbindungen sowie korrekt abgebrochenen Verbindungen (z.B. als DDoS-Gegenmaßnahme) im Monitoring absolut unter. Andererseits erschwert es die Fehlersuche, wenn nur wenige Clients davon betroffen sind und kein klares Muster erkennbar ist.

      Als Verursacher konnte jedoch schnell der DDoS-Schutz ausgemacht werden, der uns eigentlich vor Netzwerkproblemen in Folge eines Angriffes schützen soll. Wir sind auf ihn zwingend angewiesen, da wir regelmäßig und teilweise täglich von DDoS-Angriffen betroffen sind. Die meisten sind jedoch so klein und primitiv, dass sie problemlos ohne großen Aufwand gefiltert werden können. Im Juli erreichten uns jedoch mehrfach außergewöhnlich starke und ziemlich ausgeklügelte Angriffe. Wir zogen deshalb innerhalb weniger Minuten in ein neues Rechenzentrum um, das uns eine weit höhere Schutzbandbreite und mehr Gegenmaßnahmen bot. Durch die Anbindung an dafür spezialisierte Carrier lässt sich ein Großteil der Angriffe abwehren, bevor sie das Rechenzentrum überhaupt erreichen.

      Für unseren Server gelten bei dem DDoS-Schutz noch weitere Besonderheiten. Üblich ist es, dass Samples des eingehenden Traffics in kurzen Intervallen permanent analysiert werden und dadurch ein Angriff innerhalb weniger Sekunden erkannt werden kann. Der Traffic wird im Falle dessen über eine Filterinfrastruktur geroutet, die sicherstellt, dass der Angriff gefiltert wird, ohne legitimen Traffic zu behindern.

      Stattdessen haben wir uns für eine permanente Filterung des eingehenden Traffics entschieden, um mögliche Verbindungsabbrüche durch das Umrouten zu vermeiden und um während der Erkennungszeit von wenigen Sekunden dennoch in jedem Fall uneingeschränkt erreichbar zu sein. Zudem wurde ein für unseren Einsatzzweck angepasster applikationsspezifischer Filter für MTA:SA entwickelt. Während die üblichen Filter recht grob sind und legitimen Traffic in unserem Fall vielleicht dann doch teilweise verwerfen könnten, weil sie für ein möglichst breites Anwendungsfeld eingesetzt werden, erlaubt unsere individuelle Konfiguration eine sehr granulare Filterung und einen vollständigen Schutz über alle Netzwerkebenen hinweg. Auch Angriffe, die speziell auf MTA:SA abzielen, werden im Keim erstickt. Die verwendeten Filter bestehen mitunter aus mehreren tausend Einträgen, die zudem auch noch dynamisch aufgebaut sind, um ohne manuelle Eingriffe ausgeklügelte Angriffe abwehren zu können. Zudem tauschen sie weltweit untereinander noch unbekannte Angriffsmuster aus, um auch neuen Angriffstechniken keine Chance zu bieten. Manuelle Anpassungen an den Filtern nimmt unser Provider zu Geschäftszeiten nahezu stündlich vor. Aus all den Einflüssen kann es dazu kommen, dass Filter sensibler reagieren als sie sollten und legitimen Traffic verwerfen. Normalerweise sind solche Fehler ungewöhnlich, da u.a. vor manuellen Änderungen überprüft wird, ob sich die Filter auf den bisher angefallenen Cleantraffic überhaupt anwenden lassen. Sollte diese Maßnahme dennoch einen Fehler nicht verhindern, erkennt das Monitoring, wenn Filter ungewöhnlich viel Traffic, der vorher als Cleantraffic eingestuft wurde, plötzlich als Angriffstraffic verwerfen. Die komplexe Filterstruktur hat unseren legitimen Traffic jedoch nur in geringem Maße und unter ganz bestimmten äußeren Umständen verworfen und als Angriff detektiert, was die vergleichsweise geringe Anzahl an betroffenen Spielern und das willkürliche Auftreten zeigt.

      Eine erste Prüfung hatte ergeben, dass keine Änderungen vorgenommen wurden, die uns betreffen könnten. Aufgrund des Erscheinungsbildes war es jedoch ziemlich sicher, dass die Filter legitimen Traffic als Angriff erkennen. Hierfür war eine genaue Analyse des Live-Traffics notwendig, die heute stattfand. Nachdem die genaue Ursache ermittelt werden konnte, wurden die Filter entsprechend angepasst. Für die Zwischenzeit wurde eine temporäre Lösung aktiviert, die zuverlässig funktionierte und auf die wir zukünftig bei ähnlichen Problemen durchaus wieder schnell zurückgreifen könnten.