Wenn man am 3. denkt, es sei Freitag, der 13.

Das neue Jahr ist gerade einmal drei Tage alt, und schon muss sich die Redaktion von teltarif.de mit allerhand technischen Problemen herumärgern: Sowohl der primäre, als auch ein Backup-DSL-Anschluss verweigerten heute den Dienst.

Standardmäßig wird unser Büro über "Festverbindung Internet über DSL" an das Internet angebunden. Dieser Datendienst der Deutschen Telekom bietet einen DSL-Zugang mit einigen Extra-Services wie festen IP-Adressen und Router. Daneben existiert seit einigen Monaten noch ein DSL-Anschluss von QSC, den wir vor allem für Test-Zwecke verwenden. Und eben als Backup.

Als heute morgen die ersten Mitarbeiter im Büro ankamen, erlebten sie nur Probleme: Keine Webseite ließ sich öffnen. Ein Redakteur, der von zu Hause aus arbeitet, hatte das umgekehrte Vergnügen: Er kam nicht ins Firmennetz.

Relativ bald stellte sich heraus, dass der DSL-Anschluss der DTAG das Problem war. Statt vernünftiger Daten kamen dort nur massenhaft leere UDP-Pakete an, alle mit einer IP-Adresse aus Südkorea (!) als Absender. Zwar konnten wir mit Hilfe von "whois" herausfinden, auf welche Firma diese IP-Adresse registriert war. Allerdings erwiesen sich alle dort angegebenen Rufnummern als falsch. Aber selbst dann, wenn wir durchgekommen wären, hätte das nicht geheißen, dass wir jemanden an die Strippe bekommen hätten, der den Wahnsinn abstellen kann: Ein Hacker, der absichtlich den ganzen Datenmüll auf uns loslässt, wird das kaum mit seiner echten IP-Adresse als Absender tun.

Die von uns in der Folge angerufene DTAG-Hotline nahm bereitwillig die Störungsmeldung auf, schien aber mit dem Begriff DOS-Angriff (ausgeschrieben: "Denial Of Service") nicht sonderlich viel anfangen zu können. Man versprach uns die zügige Bearbeitung und den Rückruf eines Technikers.

Gut, man hat ja Alternativen, also QSC. Die Einwahl klappte problemlos, doch nach fünf Minuten war das Intranet wieder abgekapselt vom Rest der Welt. Auch hier verlief die Fehlersuche relativ schnell: Das Modem blinkte hektisch und versuchte eine Neu-Synchronisation. Dieses mal hielt die Verbindung sieben Minuten. Und so ging es weiter: online - offline - online - offline.

Zum Glück nennt unser zentrale Router, eine Linux-Maschine, auch eine ISDN-Karte sein eigen. Also schnell einen ISDN-Zugang konfiguriert - wir haben ja genügend in der Datenbank - und dann ganz klassisch eingewählt. Immerhin waren wir jetzt wieder "online", und das mehr als nur ein paar Minuten.

Weitere Konfigurationsarbeit war notwendig, damit die E-Mail wieder ankam. Denn normalerweise empfangen wir Mails direkt über unseren Mailserver im Intranet. Dessen feste IP-Adresse war aber nicht mehr erreichbar (siehe oben, T-Interconnect DSL). In diesem Fall springt automatisch unser Web-Server als alternativer E-Mail-Server ein. Dieser versucht dann alle paar Minuten, die E-Mail an das Intranet weiterzugeben, damit sie doch noch auf dem richtigen Server landet. Für kurzfristige Ausfälle (ein oder zwei Stunden) ist das auch okay, dass die E-Mails vorübergehend auf dem Webserver liegen. Doch der Ausfall zog sich länger hin.

Wie kommt die E-Mail nun vom Web-Server, vorbei an unserer Firewall, zum eigentlichen E-Mail-Server im Intranet, dessen normale IP-Adresse nicht mehr erreichbar ist? Hier half IPsec, die Pakete auf Umwegen doch ans richtige Ziel zu bringen.

Zum Nachmittag hin "erfreuten" wir uns dann an einer stabilen Verbindung inklusive E-Mail; auch wenn die paar kBit/s, die ISDN hergibt, uns nicht wirklich begeistern konnten. Die Telekom erklärte uns, dass ein Techniker weiterhin mit unserem Anschluss beschäftigt sei; ein Router würde "spucken". Das QSC-Modem hängten wir an einen eigenen Rechner, wo es plötzlich tadellos funktionierte.

Der Stand am Abend: T-Interconnect läuft wieder. Ob hier tatsächlich der Router am Spucken war, ob ein Hacker Schuld an dem Zauber hatte, oder ob die DTAG jetzt einfach die Pakete auf einem vorgelagerten Router sperrt, ist bis jetzt nicht klar. Denn der versprochene Rückruf des Technikers kam bis jetzt nicht.

Beim QSC-Modem kamen wir hingegen der Fehlerursache einen Schritt näher: Wenn wir es direkt an einen Rechner hängen, funktioniert es tadellos. Wird es hingegen über unseren Switch an das Intranet angeschlossen, hält es die Verbindung höchstens wenige Minuten. Dieses Verhalten erscheint uns höchst suspekt: Normalerweise sollte es dem Modem völlig egal sein, ob die PPPoE-Frames direkt von einer Netzwerkkarte kommen, oder dazwischen nochmal über einen Switch laufen. Vielleicht sieht das Modem in dem Fall, dass es am Switch hängt, einige zusätzliche IP-Pakete aus dem Intranet. Diese sollte es aber einfach ignorieren, und sich auf die PPPoE-Pakete konzentrieren, statt die Verbindung total aufzuhängen. Von den DSL-Modems der Telekom kennen wir jedenfalls solche Probleme nicht.

Lange Rede, kurzer Sinn: Am Montag funktioniert unser Intranet wieder tadellos, und wir werden in alter Frische für Sie berichten!