Probleme mit der Erreichbarkeit einiger großer Webseiten, z. B. Twitter

Wir (FFMS) haben das Problem, dass aus einigen Domänen Twitter nicht erreichbar ist. Ich habe mal in #gluon gefragt und dort haben einige von ähnlichen Problemen berichtet, auch mit anderen großen Webseiten (z. B. Stackoverflow).
Ein wget auf Twitter braucht manchmal fünf Versuche, bis dann eine Antwort kommt (301 auf HTTPS), vorher stirbt die TCP-Session. @Zaunei dachte an ein Rate-Limit, aber kb-light meinte, dass beim Freifunk Hochstift keine ähnlichen Probleme bekannt sind und einer ihrer Core-Router gerade ca. 1000 Clients bedient.
Dies Thema soll dazu dienen, der Ursache auf die Spur zu kommen und so die Probleme letztendlich hoffentlich beseitigen zu können. Das Problem hat nicht unbedingt direkt etwas mit dem FFRL-Backbone zu tun, aber vielleicht könnt ihr bei der Fehlersuche helfen.

^^ Zickt auch gelegentlich

Ja wir (Freifunk Westpfalz) haben das gleiche Problem. Vor allem Twitter funktioniert quasi gar nicht. Twitter zu kontaktieren scheint auch quasi unmöglich zu sein. Von MWU und Karlsruhe haben wir auch schon von solchen Problemen gehört. Beide gehen auch per FFRL-Exit raus.

Ich kann (FFRE) von Problemen mit PSN und Xbox live berichten. (Zumindest meine Nachbar haben Probleme. Ich kann das hier nicht nachprüfen, da ich keine Konsole habe).

Bitte mal prüfen, ob es eher an IPv6 hängt als an IPv4.
Und ob es (bei IPv4) einen Unterschied gibt, ob die Exit-IP „in Berlin“ liegt oder nicht.

Twitter kann kein v6. In dem Fall sind es die Berliner Adressen, ja. Die Düsseldorfer sind aktuell nicht in Benutzung

1 Like

Die Ps3 und Xbox360 können ebenfalls nur Ipv4. Dementsprechend auch deren Dienste. Wie kann ich den nachprüfen, welcher Exit benutzt wird?

Eine beliebige IP Check Webseite besuchen.

myip.dk

1 Like

:joy: Blöde Frage von mir. Das wäre dann die 185.66.195.7.

Wenn man aber die Adressen nicht genau kennt und reverse Mapping auch keine Hinweise gibt, so
scheint mir das besser:

https://www.heise.de/netze/tools/meine-ip-adresse/

dann noch mal auf die Adresse klicken und dann kommt mehr (Ripe-)Info.

in Aachen kann man per IPV4 keine Mails verschicken. Ich habe mich dran gewöhnt und tunele alles zusätzlich nochmal über ein VPN.

http://www.abuseat.org/lookup.cgi?185.66.193.42

IP Address 185.66.193.42 is listed in the CBL. It shows signs of being infected with a spam sending trojan, malicious link or some other form of botnet.

It was last detected at 2017-01-19 19:00 GMT (+/- 30 minutes), approximately 2 days, 20 hours, 29 minutes ago.

It has been relisted following a previous removal at 2017-01-18 09:22 GMT (4 days, 5 hours, 41 minutes ago)

Schickst du deine Mails ohne Authentifizierung raus?

1 Like

Das Verhalten zeigt sich wie folgt: Es wird eine TCP Verbindung aufgebaut. Dann wird versucht darauf irgendwie HTTP oder HTTPS zu sprechen. Dann wird die Verbindung direkt wieder abgebaut. Bei HTTPS passiert dort quasi gar nichts. Bei HTTP bekommt gefühlt 1 von 5 Requests eine Antwort.

Ich habe mir mal die Route zu einer betroffenen Twitter-IP angeschaut. Mir ist aufgefallen, dass die Route nicht konsistent ist. Gehe ich jedoch lokal raus (steuerbar indem man die quell IP vorgibt), sieht die Route konsistent aus.

Nachdem weiter oben thematisiert wurde, dass man prüfen solle ob die „Berliner Adressen“ betroffen seien, habe ich das mal auf all unseren Gateways mit Anbindung ans FFRL Backbone gemacht:

Man sieht, es betrifft nicht alle Gateways. Und überall wo dieses eher untypische Verhalten sichtbar ist, gehen die Pakete über syseleven.

Die Gateways (mit FFRL-IP) sind (von links nach rechts, zeilenweise):

  • parad0x: 185.66.193.51
  • c1024: 185.66.193.48
  • fanlin: 185.66.193.49
  • des1: 185.66.195.21
  • des2: 185.66.195.23
  • nightbounce: 185.66.193.50

Man sieht, dass nicht alle Betroffenen Gateways eine „Berliner-IP“ haben, aber alle als nächsten Hop über Berlin (195er war doch Berlin, oder?) gehen (wir sollten unser Routing bei der einen Kiste da im Übrigen mal fixen).

Mir ist das Problem auf jeden Fall schon bei des1 und des2 aufgefallen. Ob das jetzt wirklich an diesem komischen Routing liegt, weiß ich nicht. Aber es ist ein interessanter Ansatzpunkt.

Vermutlich muss ich mich noch mal hin setzen und die kaputten Verbindungsaufrufe mitschneiden, es ist leider schon ein bis zwei Monate her, als ich das tat.

Edit: Hier noch mal die numerische Ausgabe (leider als Screenshot, da im Report-Modus die unterschiedlichen Hops nicht dargestellt werden):

Nachtrag2:

Ich habe jetzt noch mal per wget über die FFRL Adresse auf allen GWs gecheckt: Bei den 3 GWs, die über Berlin gehen (des1,des2, nightbounce) treten die o. g. Probleme (http geht manchmal, https geht quasi nie) auf. Bei den anderen GWs ist alles OK.

5 Likes

Hallo zusammen,

wir haben das Routing zu twitter geändert sodass der Traffic jetzt bevorzugt an einem festen Punkt übergeben wird.
Es kann mit einem Anycast Setup bei twitter zusammenhängen.

Zusätzlich schauen wir uns an wie wir den Hash Algorithmus für die Paketverteilung verbessern können (sprich Kernel Updates).

Viele Grüße,
Lars

11 Likes

Scheint jetzt tatsächlich wieder ordentlich zu gehen. Danke fürs fixen :heart_eyes:

1 Like

Ich gehe mal davon aus, dass in ffrl-dus_b derzeit Wartung läuft. (maybe slightly offtopic, falls es nicht zum Thema hier passen sollte.)

Zumindest scheinen mehrere betroffen zu sein.

P.S. ist wieder erreichbar.

2 Likes

Uns wurde vorgetragen, und wir konnten es auch nachvollziehen, dass einige andere Domains ebenfalls nicht erreicht werden können. Hier sind ebenfalls die Gateways betroffen, die über Berlin raus gehen. Ich habe unser Routing jetzt erstmal so angepasst, dass die Gateways mit „Berliner IP“ ebenfalls über DUS gehen. Das ist eher suboptimal, und auch nur temporär, aber so funktioniert es zumindest für den Anwender.

Betroffene Domains sind u. a. netflix.com und movie1080p (oder so :wink: ).

P. S.: Was mir bei meinen damaligen Tests bemerkt hatte: Wenn ich den Google DNS (8.8.8.8) oder den DNS Server der Telekom bei mir Zuhause am privaten Anschluss nach z. B. twitter.com befrage und auf die Adresse im Freifunk teste, funktioniert es. Afaik (ich habe die DNS Geschichte bei uns nicht implementiert) befragen unsere DNS Server für Freifunk direkt die Root-Nameserver. So weit ich weiß, machen „die großen“ ja auch Geolocation über DNS. Machen die das auch über die Root-DNS Server? Möglicherweise liegt hier ein Teil des Problems.

2 Likes