Seit etwa einem Monat suchen wir nach einem neuen Standort für unser Gateway. In diesem Beitrag wollen wir erklären warum und was wir suchen.
Aktuell läuft unser Gateway auf einem kleinem virtuellen Server. Der ist kräftig was CPU angeht, verspricht bis zu einem Gigabit und auch relativ kostengünstig. Offloading erfolgt per AirVPN (ipv4) und HE Tunnelbroker (ipv6). Nun, das solche Server so günstig sind, hat den Hintergrund, dass eine gewisse Mischkalkulation gemacht wird. Das wiederum bedingt, dass es im Interesse des Providers ist, dass nicht einzelne Superheavy-User mehr Ressourcen nehmen wie allgemein einkalkuliert ist. Wir werden uns also kurz oder lang von dieser relativ schlanken Lösung trennen müssen.
Wenn man also eh schon auf der Suche ist, warum sollten wir dann nicht grundsätzlich darüber achdenken was wir tun. Die Störerhaftung ist bald weg, es gäbe also keinen Grund mehr für Freifunk mit diesem ganzen komischen VPN und den OpenWRT/LEDE-Firmwares, die nicht ganz so schnell sind… Oder? Oder doch?
Unsern Richtfunkbackbone direkt ans Gateway anstöpseln!
Wir haben in Kitzingen lange an einem Richtfunkbackbone gebaut. Dieser Treibt, je nachdem wie er eingestellt wird, 600 Mbps synchron durch die Luft. Eigentlich geil. Aber so bald das wieder ins Internet muss, haben wir ein Problem: VPN.
Deswegen ist, wenn man grundsätzlich drüber nachdenkt, der erste wichtige Punkt, dass man Datentransfer ohne VPN zu unserem Gateway bekommt. Dieser Punkt ist sozusagen elementar.
Weil wir kein Geld für ewig große Lichtwellenleiteranmietung haben, muss unser Gateway also näher zu uns. Im Prinzip gibt es 3 Anbieter/Optionen, die wir als Freifunker aus Kitzingen lokal haben, alle sind in oder nah dran an Würzburg. In Kitzingen selbst gibt es unserer aktuellen Kenntnis nach keine solche Colocation/Rechenzentrum-Infrastruktur oder Anbieter, die für uns interessant sind.
Wir wollen also unser Gateway direkt per Richtfunk erreichen, wobei es nur noch besser ginge, wenn wir irgendwo eine Lichtwellenfaser von Kitzingen zu unserem Gateway finden würden. Anyways, Würzburg sind nur 15 km entfernt, es findet sich schon auch mit Richtfunk ein Weg mit 2 oder 3 Hops zwischen drin.
Der Gewinn für unseren Gateway-Betrieb ist, dass wir nicht alles doppelt – rein und raus – durch den Anschluss vom Gateway schieben müssen. Wir sparen Bandbreite und je nachdem auf welches Abrechnungsmodell wir gehen (Flat, Burst, 95 th percentile) sparen wir auch Geld gegenüber VPN.
BGP please, Netze und AS Nummer
BGP ist ein Routingprotokoll. Es sorgt dafür, dass autonome Routersysteme die Route für Traffic kennen, auch wenn diese niemand “manuell” eingestellt hat. Im prinzip funktioniert das so: Jeder sagt welche Netze ihm gehören und kündigt die entsprechend allen Nachbarn an. BGP ist quasi die Eingangsvoraussetzung, wenn man langfristig plant ein Gateway zu betreiben – und dabei nicht nur mit einem Provider, sondern möglichst mit allen anderen ISPs und Providern, die man erreichen kann, Traffic direkt auszutauschen. Dieses direkte Austauschen von Traffic nennt man Peering. Peering spart Transit und Transit kostet Geld.
Um das verständlich herunter zu brechen: Sie haben beispielsweise einen DSL-Anschluss, das ist quasi wie “Transit”, sie geben alles zum DSL-Anschluss, der kümmert sich darum egal ob jemand in Japan oder der Nachbar die Datenpakete empfängt. Mit ihrem Nachbarn machen Sie nun einen Deal, ihre Backups speichern Sie auch noch mal in seinem Haus, damit wenn ihr Haus abbrennt, kein Datenverlust entsteht. Jetzt ist das aber doof, alles durch das 10.000er DSL durchzuwürgen. Sie machen eine direkte Leitung zu ihrem Nachbarn. Das wäre dann sozusagen das “Peering”.
Um mit anderen Autonomen Systemen eBGP zu machen, braucht man selbst eine AS Nummer. Wir arbeiten bislang nur mit einer privaten AS-Nummern – aber das soll ja nicht so bleiben. Also kommt noch dazu, dass wir uns wünschen, das unser neuer regionaler Provider uns eine AS Nummer besorgt.
Dann brauchen wir natürlich auch eigene Netze. Derzeit ist ipv4 defakto erschöpft, PI-Netze (also IP-Adressen die uns und nicht dem Provider gehören) werden nicht mehr herausgegeben oder müssen teuer gekauft werden. Eine Möglichkeit ist eine Ripe Mitgliedschaft, aber auch diese ist teuer. Bei BGP wird mindestens ein /24 benötigt um jemand anderem irgendwas zu announcen – also 250+ Adressen. Viel zu viel für uns.
Deswegen wollen wir ein /29 PA-Netz (IP-Adressen gehören dem Provider) um unser Gateway und ein paar Dienste wie nextcloud, Email und Moitoring, im legacy-IP-Adressbereich erreichbar zu halten. In den WLANs werden private IPv4-Adressen ausgegeben (10.0.0.0/8), d.h. das Gateway macht hier NAT.
Es gibt bei ipv4 keine Berührungspunkte zwischen der Firmware und welche Adressen man nutzt. Das ist aber bei dem ipv6-Bereich anders: Hier geben wir öffentliche ipv6-Adressen auch im WLAN aus. Aufgrund von Sicherheitseinstellungen, dem sogenannten “Chaos Calmer”, bekommt die Firmware unsere Netze eingepresst. Dadurch kann die Firmware im Access Point alles wegwerfen, was nur stört und Chaos verursacht. Um das in Zukunft nicht mehr ändern zu müssen, wollen wir also ein /48 ipv6-Netz das bei uns bleibt.
Dann können wir zwar nur ipv6 BGP, aber wer implementiert heute, in 2017, noch ipv4 neu? Wir sehen fast immer über 40% ipv6-Traffic, in manchen Spitzen auch mal 80%. Es gibt keinen Grund einem immer kleiner werdenden Anteil an ipv4-Traffic noch Geld hinterzuwerfen um ein announcebares /24 zu bekommen.
Was darf’s Kosten?
Wenn wir Geld sammeln um ein neues Projekt zu machen, ist die Finanzierung in den seltensten Fällen ein Problem. Einmalige Kosten, projektbezogen, sind kein Problem. Es findet sich immer jemand der das jeweilige Projekt ausreichend geil findet, Standort X an den Richtfunk-Backbone anzubinden oder irgendwie dort WLAN zu haben, um es zu finanzieren.
Anders stellt sich das ganze dar, wenn es um laufende Kosten geht. Quasi keiner hat Interesse, laufende Kosten zu tragen. Die Folge für uns ist ganz einfach: Kaufen vor mieten, wo sich regelmäßige Zahlungen vermeiden lassen, vermeiden wir sie. Das ist aber keine Option, wenn man Traffic/Transit etc. einkaufen muss oder sich in ein Rechenzentrum einmieten muss. Irgendwas wird man wohl regelmäßig zahlen müssen.
Im nächsten Blogpost berichten wir dann was wir gefunden haben…
