»Time to say ›Goodbye‹«: im Laufe des Tages werden die ›Legacy-Gateways‹ deaktiviert.
Heute nacht wurden die Meshes zusammengeschaltet; am Freitag laufen beide Netze parallel, im Laufe des Freitags werden aber sukzessive die alten FFGT-Gluon-Gateways deaktiviert, sodaß Knoten gezwungen werden, sich zu den neuen Gateways zu verbinden. In der Theorie ein sanfter Übergang — da wir derlei vorher noch nicht gemacht haben und auch nur begrenzt proben können, kann alles passieren, von »nur« besserer Performance bis zum totalen Stillstand. Daumen drücken kann also nicht schaden ;)
Diese Darstellung wird dem einen oder anderen neuen Technik-Mitstreiter hoffentlich auch ein wenig zu mehr Klarheit verhelfen — und ja, auch dieses wird wieder (leider) ein techniklastiger Beitrag. Aber wir hoffen natürlich, daß ein paar Leute sich auch für die Technik ›hinter den Antennen‹ interessieren, denn ganz ohne Aufwand ist Freifunk leider nicht zu haben.
Ganz unten sehen wir also die Freifunk-Knoten (TP-Link 841, 1043, CPE210, Ubiquiti Nanostation usw. usf.), die – symbolisiert über die lilafarbende gestrichelte Linie – sich über handelsübliche Internetzugänge zu unseren Freifunk-Gateways verbinden und so (mit ihren WLAN-Antennen) Teil des Freifunk-Meshs werden.
Die Knoten verbinden sich über ein sog. »Virtual Private Network«, d. h. durch einen sog. Internet-Tunnel, mit unseren Gateways — hier als gw01 bis gwNN bezeichnet. Diese Gateways – im neuen Setup durch sehr schnelle Layer-2-Tunneling-Protokoll-Tunnel (L2TP), auch als »virtuelles Ethernet« bezeichnet, untereinander verbunden – haben den Überblick und wissen letzlich, welches (End-) Gerät über welchen Knoten und welche Verbindung dorthin erreichbar ist — und sie teilen diese Information mit allen anderen Knoten. Das ist einerseits toll, denn so weiß mein Freifunk-Knoten zuhause nicht nur, wo’s zum Internet geht, sondern auch, wie er denn Rechner X hinter Knoten Y erreichen kann (über gw02 zu gw03 und dort zu Knoten A zu Knoten Y und dann Rechner X) — der Nachteil ist der relativ hohe sogenannte »Overhead« an Datenverkehr: es wird nicht gefragt, ob mein Knoten obige Information wissen will. Sie wird jedem Konten zwangsweise zuteil, und dadurch steigt, je mehr Geräte wir im Netz haben, leider das »Grundrauschen« an. Aber dazu demnächst mehr …
Hier und heute geht es um die Funktionsweise des (neuen) Netzes; nachdem ein Knoten sich also per fastd mit einem Gateways verbunden hat, sorgt unser Layer-2-Routingprotokoll – batman_adv – dafür, daß (normalerweise) dieses Gateway auch für alle DHCPv4-Anfragen verwendet wird. Clients (Endgeräte), die sich an gw02/gw04 (neu) verbinden, gehen nun wieder in Gütersloh ins Internet; nach den letzten Tests haben wir das Gütersloher Netz konsequent auf die 1 GBit/sec-Infrastruktur umgezogen und auch die IPv4-Übergänge auf GBit-Interfaces gelegt; und zumindest knapp 100 MBit/sec singulär laufen jetzt auch durch jenes Netz:
ffgt@testvm:~$ wget -O /dev/null http://cachefly.cachefly.net/100mb.bin --2015-10-30 00:34:52-- http://cachefly.cachefly.net/100mb.bin Resolving cachefly.cachefly.net (cachefly.cachefly.net)... 205.234.175.175 Connecting to cachefly.cachefly.net (cachefly.cachefly.net)|205.234.175.175|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 104857600 (100M) [application/octet-stream] Saving to: ‘/dev/null’ 100%[=================================================================================================>] 104,857,600 8.24MB/s in 11s 2015-10-30 00:35:03 (9.15 MB/s) - ‘/dev/null’ saved [104857600/104857600]
ffgt@testvm:~$ traceroute cachefly.cachefly.net traceroute to cachefly.cachefly.net (205.234.175.175), 30 hops max, 60 byte packets 1 gw02.ffgt (10.255.0.12) 1.395 ms 2.228 ms 2.195 ms 2 bgp1-gw02.ospf.ffgt (10.255.145.20) 3.921 ms 3.899 ms 3.875 ms 3 100.64.0.6 (100.64.0.6) 4.350 ms 4.327 ms 4.301 ms 4 xmws-gtso-de11.nw.mediaways.net (192.251.226.202) 5.159 ms 5.264 ms 5.343 ms 5 ae1.cr-mira.gut1.he-core.de (80.237.129.49) 5.306 ms 5.222 ms 5.201 ms 6 xmws-gtso-de31-chan-2.nw.mediaways.net (195.71.9.1) 5.166 ms 3.175 ms 2.954 ms 7 et-0-1-0-0.0001.prrx.13.fra.de.net.telefonica.de (62.53.2.59) 8.528 ms et-7-1-0-0.0001.prrx.13.fra.de.net.telefonica.de (62.53.2.57) 9.694 ms 10.232 ms 8 et-7-1-0-0.0001.prrx.13.fra.de.net.telefonica.de (62.53.2.57) 8.428 ms 7.874 ms et-0-1-0-0.0001.prrx.13.fra.de.net.telefonica.de (62.53.2.59) 8.320 ms 9 vip1.G-anycast1.cachefly.net (205.234.175.175) 7.837 ms 8.593 ms 8.264 ms
Vom »Router« gehts direkt, trotz NAT, deutlich schneller weiter, insofern bleibt die Hoffnung, daß sich die Einzelmeldungen im laufenden Gesamtsystem nicht bewahrheiten:
root@bgp1:~# wget -4 --bind-address=10.255.144.1 -O /dev/null http://cachefly.cachefly.net/100mb.bin --2015-10-30 00:37:47-- http://cachefly.cachefly.net/100mb.bin Resolving cachefly.cachefly.net (cachefly.cachefly.net)... 205.234.175.175 Connecting to cachefly.cachefly.net (cachefly.cachefly.net)|205.234.175.175|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 104857600 (100M) [application/octet-stream] Saving to: ‘/dev/null’ 100%[=========================================================================================>] 104,857,600 78.9MB/s in 1.3s 2015-10-30 00:37:49 (78.9 MB/s) - ‘/dev/null’ saved [104857600/104857600]
Rekapitulieren wir: ein Endgerät verbindet sich über einen Knoten mit einem Gateway und bekommt von diesem die IPv4-Konfiguration. Wird gw02 oder gw04 verwendet, geht der Datenverkehr über Gütersloh direkt ins Internet, bei gw01 und gw03 nutzen wir die dankenswerterweise vom Freifunk Rheinland aufgebaute und bereitgestellte Infrastruktur.
Anders als im bisherigen Netz, wo die Gateways nicht nur Übergang zum Internet waren, sondern auch als DHCP- und DNS-Server fungierten, haben wir im Neuen Netz zentrale IP-Vergabe per DHCPv4: hierzu baut jedes Gateway einen L2TP-Tunnel mit einem kleinen IPv4-Netz zum DHCP-Server auf – in der Grafik in Gelb gehalten –, über welches dann die IPv4-Adressvergabe zentral stattfindet. Vorteil: der Adressraum kann effizienter genutzt werden und die Clients können die IPv4-Adressen auch über mehrere Accesspoint-Wechsel behalten. Aktuelle Baustelle: auch dieser Dienst sollte redundant erbracht werden, außerhalb Güterslohs haben wir aber noch keine ›Server‹ konfiguriert (=> der »FFGT-Server«-Block sollte auch rechts in der Grafik existieren).
Von den Gateways aus, auch dies ist im neuen Netz anders, geht es dann zu einem der vier NAT- oder Exit-Server, die wir bgpX genannt haben. Wir können hier nun also endlich unabhängig von den Exit-Servern die Anzahl der Gateways verändern, also bei Bedarf skalieren. Die CPU-Leistung für das Entpacken des VPN-Tunnels fällt nur auf den Knoten und den Gateways an, die Exit-Server routen nur IP-Pakete (und im Falle IPv4 machen sie noch NAT). Pro »Standort« (»RZ Gütersloh« und »sonstige Hoster«) haben wir aus Gründen der Ausfallsicherheit zwei dieser Exit-Server, jedes Gateway hat ein über das Routing bevorzugtes zugewiesen, würde bei Ausfall aber in Sekunden auf das andere schwenken. Über die Exit-Gateways halten wir auch Verbindung zu anderen Freifunk-Netzwerken, nämlich über das sogenannte InterCity-VPN (ICVPN).
Das ganze Konstrukt wird auf unserer Seite in Form von Linux-VMs über z. Zt. 6 Linux-Server (drei im RZ Gütersloh, drei bei verschiedenen Hostern) und etliche Punkt-zu-Punkt-Tunnel in verschiedenen Protokollen (GRE, L2TP, fastd, TINC) realisiert — und ist ab heute live ;)