Orginaler Blog-Post: Dem GAU sein kleinerer Bruder … – Freifunk Kreis GT
… hat uns heimgesucht: Der Ausfall des Servers in Berlin hatte unerwartet schwerwiegende Auswirkungen; daß sich dann die verbliebene Routing-VM in Gütersloh verabschiedete, machte grundlegende Änderungen nötig — mit anderen Worten »ein Wochenende zu vergessen«.
Unser Autonomes System bis vor ein paar Tagen …
Um zu erklären, was geschah, muß ich etwas ausholen. Der Freifunk im Kreis Gütersloh betreibt seit November 2016 ein eigenes so genanntes »Autonomes System«. Das hat nichts mit brandschatzenden Linksextremisten zu tun, ein »AS« ist vielmehr die kleinste Einheit im weltumspannenden Zusammenschluß kleiner und großer Netze, dem globalen Internet. Technisch zusammengehalten wird »das Internet« durch standardisierte Routingprotokolle – wie kommt das Datenpaket vom heimischen Internetzugang zu z. B. »tagesschau.de«? –, u. a. BGP und OSPF.
Und hier begint das Problem schon: wenngleich unsere Wiege quasi die Server im Gütersloher Rechenzentrum waren, sind sie doch die einzigen bislang, bei denen wir bei der Anbindung nicht ganz auf eigenen Füßen stehen: »historisch bedingt« sagt der Provider Plusserver »Moin, zu den Servern in 192.251.226., von 0 bis 255, bitte hierlang«. Seit ca. 2017 sagen wir das gleiche, nur mit anderem Wegweiser bei »hier«: statt »AS61157« malen wir da »AS206813« drauf. Das funktioniert, solange denn alle Systeme im AS alle anderen über wenigstens einen Weg erreichen können.
Mit der Zeit hatten wir nicht nur in Gütersloh Server stehen, sondern mittlerweile auch – je einen – in Berlin, Frankfurt, Hamburg. Und überall dort konnten wir erreichen, daß unsere Server Zugang zu sogenannten Internet-Austauschpunkten bekommen; in Hamburg an den DE-CIX Hamburg (sowie als »Remote Peering« nach Frankfurt, Düsseldorf, München) und den ECIX Hamburg; in Berlin an den Community-IX sowie darüber an den BCIX, den Berliner CIX; in Frankfurt wiederum an den Community-IX und darüber u. a. an den DE-CIX Frankfurt, den größten Datenaustauschpunkt der Welt.
Damit aus den einzelnen Inseln ein Netzwerk wird, verbinden wir die Inseln über Tunnel. Das kann man sich ähnlich wie Straßentunnel vorstellen, statt einmal von Gütersloh über A2 und A7 nach Hamburg zu fahren, haben wir eine virtuelle direkte Verbindung zwischen den beiden Rechenzentren konfiguriert. Anders als der Straßentunnel ist das nicht zwingend kürzer oder schneller – wir haben eben keine direkte Verbindung gebuddelt, sondern bauen diese auf bestehenden Internetverbindungen auf –, aber es ermöglicht unter anderem die Verbindung der Teilnetze zu einem Gesamtnetz; dadurch bleiben die Daten logisch in unserem Netz:
root@l2tp-ham01 ~ # traceroute web01.4830.org traceroute to web01.4830.org (192.251.226.22), 30 hops max, 60 byte packets 1 bgp-ham02.4830.org (193.26.120.113) 0.241 ms 0.219 ms 0.198 ms 2 bgp-fra01.4830.org (193.26.120.81) 6.501 ms 6.495 ms 6.477 ms 3 bgp-gut01.4830.org (193.26.120.82) 18.212 ms 18.201 ms 18.114 ms 4 web01.4830.org (192.251.226.22) 18.818 ms 18.792 ms 19.093 ms
Im Schaubild sind die Tunnel die gestrichelten Verbindungen. Bei einem idealen Aufbau hätten wir je Standort eigene Netze (ab »/24« – 256 Adressen – bei IPv4, ab »/48« bei IPv6), dann wären die Tunnel verzichtbar(er); bei IPv6 haben wir diese Situation, bei IPv4 leider nicht, sodaß wir die /24 über die Standorte verteilen müssen.
Eine weitere Besonderheit der Gütersloher Serverfarm liegt darin, daß wir dort anbieterseitig keine IPv6-Anbindung haben. Auch das hat eher historische Gründe; jedenfalls stellt dies aber ein gleich noch wichtiges Detail dar. Denn die getunnelte Netzverbindung muß somit über IPv4 laufen; an den anderen Standorten haben wir aber keine relevante Bandbreite über IPv4 der dortigen Colocationanbieter (Hamburg: 100 MBit/sec, Frankfurt: ähnlich). Einzig in Berlin konnten wir bislang mit sinnvollen Bandbreiten über IPv4 der Colo mit Güterlsoh kommunizieren.
Unser AS nach dem Ausfall Berlins: die Verbindung zw. GUT und dem Rest ist Geschichte :-(
Donnerstag Mittag wurde der Server in Berlin nach einem weiteren Ausfall der 10GBit/sec-Karte wegen Überhitzung vorerst abgeschaltet; vermutlich durch mehr Datenverkehr überhitzt die 10G-Karte, über die unsere Anbindung an Community-IX und BCIX läuft, immer schneller; um weiteren Schaden zu vermeiden, erschien die Abschaltung am sinnvollsten.
Allerdings lief der Datenverkehr nun über nicht ausreichende bzw. technisch nicht gut funktionierende Tunnel (FRA-GUT und HAM-GUT, in den Schaubildern wegen geplanter Abschaltung nicht eingezeichnet), somit wurde die Erreichbarkeit der Server im Freifunknetz problematisch, auch die Nutzung des Freifunknetzes war beeinträchtigt. Hier konnte in der Nacht zu Freitag keine generelle Verbesserung erreicht werden. Am Freitag abend wurde intensiver an der Problemlösung gearbeitet, doch die Anbindung der Gütersloher Server über Tunnel blieb schwierig — auch durch Eingriffe der Netzwerkbetreiber in den Datenstrom (DPI: Deep Packet Inspection).
Es wurden Testreihen gefahren mit GRETAP, GRE, L2TP-in/over-GRE(TAP), Wireguard, L2TP-over-Wireguard-over-GRE, … Und dabei kam es zu weiteren Problemen — nun mußte nicht nur der Standort Berlin ersetzt werden sondern auch das Routing in Gütersloh neu gedacht und gemacht.
Und dabei kam wieder das »AS-Problem« zum tragen: während wir z. B. über da Netz 193.26.120.0/24 die alleinige Kontrolle haben, existiert unabhängig und auch nicht einfach durch uns beeinflußbar im Internet derzeit immer auch eine Route, die 192.251.226.0/24 über das AS61157 von Plusserver erreichbar macht. Somit kann es dazu kommen, daß der Weg über Plusserver für manche Provider kürzer ist als über unsere Anbindungen — siehe im Traceroute ab Hop 5:
root@bg0:~# traceroute -4 stats.4830.org traceroute to stats.4830.org (193.26.120.16), 30 hops max, 60 byte packets 1 gw.ipv4.layer6.net (217.12.202.1) 0.428 ms 0.404 ms 0.463 ms 2 ip-77-21.telehouse.bg (78.128.77.21) 8.955 ms 9.493 ms 10.012 ms 3 * * * 4 178.132.80.19 (178.132.80.19) 0.447 ms 0.603 ms 0.592 ms 5 bgp-ham02.4830.org (193.26.120.85) 31.904 ms 31.908 ms 31.886 ms 6 bgp-fra01.4830.org (193.26.120.81) 58.221 ms 33.950 ms 33.921 ms 7 bgp-gut01.4830.org (193.26.120.82) 45.502 ms 45.267 ms 45.441 ms 8 * stats.guetersloh.freifunk.net (193.26.120.16) 44.987 ms 45.142 ms root@bg0:~# traceroute -4 web01.4830.org traceroute to web01.4830.org (192.251.226.22), 30 hops max, 60 byte packets 1 gw.ipv4.layer6.net (217.12.202.1) 0.635 ms 0.603 ms 0.567 ms 2 ip-77-21.telehouse.bg (78.128.77.21) 17.549 ms 18.043 ms 18.687 ms 3 * * * 4 178.132.80.19 (178.132.80.19) 7.525 ms 0.577 ms 0.554 ms 5 ae1.cr2.fra.plusserver.com (80.81.202.112) 28.018 ms 28.029 ms 28.001 ms 6 ae1.cr2.gut1.plusserver.com (85.119.200.54) 36.497 ms 36.625 ms 36.574 ms 7 te1-5.xmws-gtso-de12.gut1.plusserver.com (85.119.200.234) 36.764 ms 36.407 ms 36.412 ms 8 web01.4830.org (192.251.226.22) 40.449 ms 40.671 ms 40.684 ms
Die Route über Plusservers AS61157 war also immer präsent, unsere (AS206813) nicht immer — da die meisten Adressen in Gütersloh liegen, stammte auch die ›Hauptroute‹ in unsere Netz von einem Router in Gütersloh. Da aber die Verbindung nach Gütersloh aus HAM und FRA nicht sauber funktionierte, fehlte die Route 192.251.226.0/24 mindestens sporadisch. So konnte es also passieren, daß Pakete aus unserem Netz zwei, drei Hops weit kamen und man danach nur noch Sterne im Traceroute sah: Die Antwortpakete kamen dann in Gütersloh über Plusserver an, konnten aber nicht mehr nach Hamburg oder Frankfurt weitergeschickt werden, weil die Tunnel nicht funktionierten. Da unserem lokalen Router in Gütersloh wiederum die Routen ins Internet fehlten (der weiß ja nichts davon, daß er das Internet auch über Plusserver erreichen kann), waren auch die meisten Systeme in Gütersloh nicht erreichbar.
Screenshot von http://gw-gut01.4830.org/ffgt.status
Letztlich kamen also ein paar Dinge zusammen, die im Kern aber jeweils auf fehlende Redundanz zurückzuführen waren:
- Keine redundanten Tunnel nach Gütersloh (einzig Berlin-Gütersloh funktionierte)
- Keine redundanten Router mehr in Gütersloh (in HAM, FRA, BER z. Zt. witzlos, da Einzelserver)
- Durch unkoordinierte Announcements einerseits, fehlendem Peering mit dem Upstrem in GT/fehlender Fallback-Defaultroute dorthin andererseits, war 192.251.226.0/24 in Gänze nicht verfügbar, egal an welchem Standort
Weitere Dinge die aufielen; im Zweifel aufgeschrieben, damit ich beim nächsten Mal™ bei der Suche danach erinnert werde ;)
- Erst das Reverse Path Filtering ausschalten, dann Interfaces hochfahren. Anderenfalls ist man als Router plötzlich ein schwarzes Loch für Pakete …
- Es hilft, wenn man Paketweiterleitung (Packet Forwarding) für die Protokolle auch aktiviert hat, die man nun routen möchte (konkret: mit /etc/sysctl.conf _anfangen_, wenn man einen Host zum Router aufwertet ;-)).
- Bird6 nimmt ab irgendeiner Version und/oder mit/ohne einer unbekannten Option keine Routen via Link-Local-Adressen (fe80::/10) mehr an. (Eine weitere Stunde erfolglosen Fehlersuches, danke. Nicht!)
- OpenVPN 2.3.10 scheint
ifconfig-ipv6 2001:db8:1317:210::1/64 2001:db8:1317:210::2zu schlucken, aber auch zu verschlucken; unterip addr showtaucht die IP jedenfalls nicht auf.
Anyway, sorry for the inconvenience; seit Sonntag Nachmittag sollten die Mesches wieder rund laufen.