Freifunk ff3l Gateway Server, Vortrag von kpanic im http://technik.cafe/ Lörrach, 2018-01-18
142 Minuten, 0.6 GByte mp4 Video.
Der erste Teil, Freifunk ff3l Firmware bauen, ist hier
00:01:18 Rückblick: erster Teil
ging über Freifunkfirmware, Funktion, Bauen, auf dem Konten = Router selbst. Diesmal: Hintergrund, wie funktionieren die Gateways
00:00:30 Auf Knoten läuft fastd, macht VPN Verbindung zum Gateway
00:01:00 Auf Gateway läuft auch fastd, nimmt die Verbindung vom Knoten entgegen
00:01:20 Am Anfang gab es nur eine community. Fastd - port war 10000
00:03:00 Netzwerkkonfiguration fastd - batman (das mesh-protokoll) interface - bridge br-ff3l. Also umgekehrte Reihenfolge wie beim Router.
00:04:15 Alfred ist auskommentiert, wurde früher verwendet
00:04:30 IPv4 und IPv6 Adresse
00:05:00 Erstes Gateway - war privat
00:05:40 Zweites Gateway - war privat
00:05:40 Drittes Gateway - vereinseigen, gesponsert - ach nein, das ist gateway 4, vorher war noch ein anderes.
00:07:20 gemietete gesponserte VServer (virtuelle Server) - hat nicht gut funktioniert
00:08:00 Gateway 5 - physische Box, leistungsstark, später umbenannt in Gateway 7
00:09:00 Gateways 1, 2 abschalten, andere umbenennen. Jetzt: 7 Gateways bei verschiedenen Hostern
00:09:30 Details, welches Gateway steht wo und und wie
00:14:00 Liste der Gateways im Wiki: (link)
00:14:50 Gateways sind untereinander mit fastd verbunden
00:15:30 fastd/ff3l/peers enthält keys aller Knoten, fastd/ff3l/gateways enthält keys aller Gateways
00:18:20 Architektur: von einem gateway zu vielen, Netzsplit, alle funktionalität auf allen Gateways
00:19:00 dom1 ist HoHo, port 10001, interface ff3l-mesh-vpn-1, bridge br-ff3l-1. Entsprechend für die anderen Subcommunities.
00:19:30 auf jedem Gateway sind alle 9 Subnetze vorhanden. Jedes Subnetz ist auf allen Gateways miteinander verbunden im gleichen Layer 2.
00:20:15 Dagegen: zwischen den Subnetzen der Communities wird geroutet
00:21:00 Subnetze und IPv4 Bereiche: 10.119.0.0 bis 10.119.15.255, das nächste ab 10.119.16.0 und so weiter
00:23:15 Bereiche bei IPv6
00:25:30 Wohin get der Traffic vom Gateway aus? IPv4 ins Internet ist einfach: NAT (Network Address Translation)
00:26:00 IPv6 komplizierter: batman kennt Gateway Modus.
00:28:00 Handy am Knoten will sich verbinden. IPv4: DHCP request. Broadcast. Problem: zu viele Antworten, potentiell von allen Gateways gleichzeitig.
00:29:30 Gateway Modus: filter, unicast statt broadcast nur zu seinem Gteway. Vermeidet unnötigen Traffic.
00:31:20 IPv6 problem: nocht DHCP sondern Router Advertisement, Neighbour Discovery - batman filtert nicht.
00:32:00 Wie vermeidet man trotzdem zuviel Querverkehr? intern ULAs verwenden (Unique Local Address), Prioriäten sind: IPv6 IPv4 ULA
00:38:00 IPv4, netzsplit
00:39:30 Lease time, addressvergabe
00:41:50 IPv4 nur 2 DHCP server auf Gateways 9 und 6 (fallback), die anderen haben DHCP relay. Im Header das 24. Byte ist der Absender. Das wird die Defaultroute - und alles stimmt.
00:47:00 DNS server
00:50:30 ins Internet über firewall. IPv6 ULAs mit network prefix translation auf externe IPv6 des jeweiligen Gateway.
00:52:00 IPs beim verwendeten Rechner. ULA beginnnt mit fd
00:55:30 Arpanet hostfiles per ftp. Öffentliche IPs. Im Gegensatz zu /56 plus MAC adresse.
00:58:00 NAT (Network Address Translation) ersetzt keine Firewall, besonders bei IPv6
00:59:30 Schön wäre provider independent IP address
01:01:30 Provider geben verschiedene Kombinationen von IPv4 und/oder/nicht IPv6
01:03:30 Firewallregeln, forwarding, filter, Zahl der Verbindungen, DHCP v6 server, ports rein und raus.
01:07:14 Provider mag nicht private IP Adressen ins Netz geroutet, z.B. NAS, Fritzbox, dann Freifunk - Route Abfrage zählt als Network abuse.
01:10:00 Diskussion spezieller IP adressen die weggefiltert werden
01:13:15 IPv4 masquerading - alles geht über die eine öffentliche IPv4 Adresse ins Netz. Standardtext auf Anfragen.
01:15:30 Soweit erklärt: Client an Router an Gateway ins Internet.
01:15:45 IC VPN, Netzwerk der teilnehmenden Freifunk communities
01:16:45 IC VPN: ein grosses VPN (tinc), ein Transfernetz, jedes teilehmende gateway (bei uns: 9 und 3) hat eine IP adresse des Transfernetz, darüber werden die anderen erreicht.
01:19:00 Vegleich der gateways: gateway 3 hat viel mehr, die anderen communities, manche davon in rot
01:20:00 Von ff3l nach Hamburg, grafische Netzwerkanzeige
01:21:15 IC VPN meta
01:23:00 start.ffbsee
01:24:15 icvpn.conf
01:25:10 Nutzen des Zugangs zu anderen Netzen
01:25:30 Freifunk - interne Anwendungen und Dienste. Beispiel: Auch vom Freifunk Bodensee aus ist pad.ff3l erreichbar.
01:28:00 Details, wie geht das: lange routing tablelle auf dem gateway
01:31:00 interne IPs von speziellen Organisationen ohne Internet - auf 0 geroutet
01:32:00 dn42 (Decentralized Network 42) peer-to-peer network VPNs BGP Routers. Bastelnetzwerk/internet
01:39:00 Kartenbackend auf Gateway 9. Hopglass (in node.js). Nicht mehr Alfred sondern respondd, muss abgefragt werden.
01:42:00 Multicase request von Hopglass an die Knoten, die geben die JSON daten zurück via unicast - weniger Netzwerkbelastung. 01:43:30 JSON Karten frontend backend versionswirrwarr.
01:45:30 Varianten in verschiedenen Programmiersprachen geschrieben, forks. Problem: pro gateway 9 subnetze Layer 2, 9 node.js respondd instanzen - CPU und RAM Resourcenproblem.
01:50:00 In Python kein Problem.
01:52:00 Diskussion über Ursprung der Tool Komponenten
01:55:00 Freifunk subcommunity: ein grosser Switch, Layer 2. Am Anfang von Freifunk wurde OLSR (Optimized Link State Routing Protocol) verwendet, ein Layer 3 Protokoll, jeder Router hat ein eigenes Subnetz, Vergleich: so wie die Subcommunities jetzt untereinander verbunden sind. 01:57:00 neuer Ansatz über Babel 02:05:40 nextnode.ff3l - der Knoten mit dem man gerade verbunden ist - wie es funktioniert: ganz viele views, je nachdem aus welchem Netz es kommt 02.21.26 Ende.