ich hab’ mal wieder auf einen unserer ICVPN-Peers geschaut, und das Ergebnis war ernüchternd: Ich sehe 24 BGP-Sessions im Status »Established« und 25, die »Neighbor lost« oder ähnliches melden.
Da wir derzeit von Puppet (ICVPN-Rezepte vorhanden) nach Ansible (nüscht da) schwenken und Altlasten (wie die bisherigen, von Puppet konfigurierten, ICVPN-Peers) loswerden wollen, mal die Frage in die Runde: wie ist Eure Meinung, insbesondere zur Frage, ob das ICVPN in der aktuellen Form noch zeitgemäß sei?
Ich würde wirklich gerne einen Neustart sehen, mit L2TP- oder WireGuard- statt TINC-Links, auch mit mehr aktivem Engagement statt reiner »ich habe die Skripte mal gestartet«-Attitüde. (No offense meant; that’s how we run it.)
Letztlich überholt die Zeit die ICVPN-Idee: wer einen Public-v6-Präfix hat, muß nicht mehr über ein virtuellen IX gehen, es stehen öffentliche IX zur Verfügung.
Andererseits eröffnet gerade ULA die Chance, Dienste zwar in der Freifunk-Wolke anzubieten, aber ohne dies für die ganze Welt zu tun.
Meine Meinung dazu hat sich wenig geändert in den letzten Jahren:
Der administrative Aufwand ist hier Selbstzweck und allenfalls „Admin-Bildungsobjekt“.
Es gibt keinen sinnvollen realistischen Usecase für das ICVPN.
Sowohl weil es den Nutzenden nicht zu vermitteln ist, wie das zu benutzen ist, geschweige denn dass es Dienste dafür gibt, die -ausser für Tests- auch nur ansatzweise genutzt werden.
Die möglicherweise konstruierbaren Usecases sind dann
sowohl unrealistisch (weil in solchen Ausnahmesituationen auch hier zu viele SinglePointOfFailures schon vorher zuschlagen, also
mangelnde DoS-Festigkeit von Freifunknetzen bei halbwegs kompetenten Angreifenden, oder schlicht der
Nein. Es diente nur dazu aufzuzeigen, welche Argumentation „pro ICVPN“ / „mögliches ICVPN-Einsatzszenario“ ich für politisch verwerflich halte. Das ist so aluhütig, dass ich nicht glaube, dort Leute überzeugen zu könen. Für solche Szenarien sollen sie halt planen, wenn sie es für realistisch und/oder gesellschaftpolitisch vertretbar halten, auf Szenarien hinzuarbeiten in denen „die großen Provider (Internet, Strom) abgeschaltet werden“. Aber ich selbst werde solches Preppertum nicht unterstützen
der Grund warum wir gerade nicht im ICVPN sind ist, dass ich tinc nicht dazu überredet bekommen habe den encapsulierten Traffic in einer VRF rauszuwerfen. Wenn wir eine Technik nehmen mit der das geht, wäre ich interessiert. Ich würde dann auch gerne PTP-Tunnel bauen statt einer großen L2-Wolke, das scheint mir deutlich besser kontrollier und vor allem debugbar.
Das schließt stand heute
L2TP
Wireguard
Tinc (ich lasse mich gerne eines besseren belehren)
aus. Wenn ich mal Langeweile* habe wollte ich mir mal angucken wie sehr man auf Wireguard einschlagen muss, damit es eine outer-VRF kann. Das könnte aus Performancegründ schneller passieren als mir lieb ist.
Ein „Killer-Feature“ vom ICVPN war früher für mich immer die Erreichbarkeit der anderen Router (über die ULA-Adressen der anderen Städte) als natives IPv6 noch nicht weit genug verbreitet war.
Mittlerweile mit nativem IPv6 hab ich es schon länger nicht mehr vermisst. Einige Communities haben DN42, das ist auch ganz nett… Dort hat sich wireguard jetzt auch als neuer Default rausgebildet (und funktioniert sehr gut), muss halt manuell gepeered werden und verbindet sich nicht automatisch zu einer Liste an Peers.
Da würde aber auch ein großes Git-Repo mit einem YAML File für alle Communities reichen, was dann von einem kleinen Shellscript in wireguard und einen BGP-Deamon der Wahl eingekippt wird.
Das funktioniert eigentlich ziemlich top (inbs. mit Link-Local v6 und Point-to-Point v4)
Wir sind nicht mehr im ICVPN, weil keiner mehr die Notwendigkeit gesehen hat seit es v6 gibt. Wir haben noch nicht einmal Cross v4 Traffic in unseren eigenen Domains, sondern auch hier nur v6. Also ergibt für uns ICVPN keinen Sinn mehr.
Ich fände es auf jeden Fall wünschenswert, wenn kleinere Freifunk-Gruppen mehr direkte IPv6-Peerings untereinander einrichten, ob nun über einen physischen IX oder über $tunnel. Für mich wäre insbesondere bei $tunnel das hauptsächliche Argument, dass der Traffic zwischen den verschiedenen Freifunk-Netzen somit nicht mehr über ‚fremde‘ Router läuft und somit weniger wahrscheinlich in die Massenüberwachung aufgenommen wird.
Am Ende betreiben ja (fast) alle nur große Tunnelgebilde. Es wäre auch möglich, einigen Traffic über eigene Peerings (von Supernode Blech über $tunnel zu IX) abzuwickeln und den Rest über einen Tunnel zu Freifunk Rheinland / Freifunk Nordwest / … zu leiten.
Will sagen: Zwischen eigenes AS mit upstream, v4 space, hardware usw. und „alles über einen Tunnel zu FFRL“ gäbe es theoretisch viele Zwischenstufen.
Wenn ein service nur Freifunk-intern erreichbar sein soll, kann man das ja auch über eine Firewall auf dem Service-Host umsetzen.
Es sollte doch möglich sein, tinc auf einer VM zu betreiben und die resultierenden Routen in einer VRF zu versenken? Oder was überseh ich/verstehe ich da nicht? Frage also: ist da wirklich ein technisches Problem oder nur zu wenig Elan, das zu umgehen, weil eh’ gefühlt kein Mehrwert?
IPv4 macht imho auch keinen Sinn mehr— aber ich bin da »Gluon-minded«, wo ohne v6 gar nichts ginge und v4 nur ein Zugeständnis an die real existierenden Clients ist. (Note to self: mal wieder angucken, wie ein Gluon-NAT64-Netz aussehen müßte.)
Ein »ICVPN Reloaded« würde ich aber tatsächlich als v6-only sehen; Zukunftsfähigkeit und so, tote Pferde und alte Zöpfe …
Puh, Transit. Das (bisherige) ICVPN für die essentielle IP(v6)-Versorgung von Communities zu nutzen, erscheint mir nicht zweckmäßig (tinc, Supportaufwand) — und war in der Vergangenheit auch eher so suboptimal, imho.
Für Transit würde ich sagen: Geh’ an den Community-IX, da haste (technisch sauberen) Transit
Allerdings muß man dazu ein paar technische Voraussetzungen (eigener Netzbereich; eigene AS-Nummer; geeignete Vor-Ort-Hardware, die Colocation und Interconnection – sowie Kosten – nach sich zieht, …) schaffen, die nicht jede Community aus dem Ärmel schütteln kann.
Mein Vorschlag wäre daher, einen virtuellen Freifunk-IX nach Vorbild des physischen Community-IX zu etablieren: gut angebundene[r] Server, woran FF-Communities per L2TP, GRE, Wireguard – alternativ mit L2TP-over-{GRE,Wireguard} für 1500er MTU – sich verbinden können und mit privaten AS-Nummern mit »FFCIX«-Routeservern peeren.
Wenn man diesen »FFCIX« nun mit seinem zu besorgenden öffentlichen ASN z. B. an den Community-IX anschlösse, könnten darüber Communities mit geringem Aufwand öffentliches v6 nutzen. Öffentlicher IPv6-Adressraum ist ja über den Förderverein vorhanden und ohne das Erfordernis einer physischen Präsenz in bestimmten Rechenzentren sänken die Eintrittshürden deutlich.
Optimal wäre es, gäbe es >1 Standort, dann könnten die Communities zu »FFCIX BER« und »FFCIX FRA« – als fiktive Beispiele – sich verbinden und hätten dadurch Redundanz.
Vorteil generell: jede interessierte Community hat nur noch Verbindung(en) zu dem/den »FFCIXen«. Anders als heute kann man diese sinnvoll überwachen, und anders als beim Full-Mesh des heutigen Setups muß nicht jeder was ändern, wenn sich woanders die Parameter ändern.
So ein zentralisiertes Setup widerspricht natürlich dem Dezentralisierungsgedanken und konzentriert den Traffic auf dem/den »FFCIX[en]«. Andererseits funktioniert das Internet durch dezentrale zentralisierende IXPs (früher »MAE-X«, heute »DECIX X« ).
Ob man nach Community-IX-Vorbild einen über Standorte verteiten IX baut oder eher getrennte IXe – z. B. »FFCIX BER« und »FFCIX FRA« – hängt imho davon ab, welche Partner man gewinnen kann — if any.
Technisch würde ich auf ein klassisches Peering-LAN verzichten, da eh’ nur BGP und L3-Routing stattfinden soll. Die Tunnel bekomen /64; ein /48 bietet IIRC 64K /64, sollte reichen. Ob man dafür auf PI v6 (50 EUR/Jahr netto), IXP-PI v6 (50 EUR/Jahr netto) oder PA v6 (2001:bf7:fc10::/44, 0 EUR/Jahr) setzt, sei dahingestellt (IXP-Präfixe werden i. d. R. nicht geroutet).
Hmm, ja; aber da man nie wußte, ob nun das ICVPN an sich oder nur der Peer drüben kaputt war, war das nicht wirklich nützlich — IMHO, YMMV.
Verständlich; da es aber noch immer Communties mit NAT-v4 und ULA-v6 gibt – AFAICS auch wegen des Aufwandes für Public-v6 –, wäre ein FFCIX schon nett, IMHO.
Any-to-any skaliert nicht; ich möchte daher dieses ICVPN-Gedöns schnellstmöglich loswerden, denn es ist nicht überwachbar (im Sinne des klassischen NOC-Monitorings). Und bzgl. der Überwachbarkeit: HTTPS existiert, ein offenes WLAN transportzuverschlüsseln erscheint nicht zielführend.
Das ist korrekt; mit AS206813 sind wir den Weg »eigenes AS« relativ früh gegangen, auch weil die Voraussetzungen da waren (v4-Netze, Know-How im Hintergrund, …) — »wir« (die Leute hinter jenem AS) kommen halt aus dem ISP-Umfeld.
Aber RZen und darüber IXP zu erschließen, das erfreut den IT-Geek, aber ist nicht wirklich täglich Brot der Masse der Freifunker da draußen. Wenn sich ein paar Communities zusammenschlössen – ähnlich wie FFRL, FFNW, … beim Exit – und nach skizziertem Model v6-Transit anböten, könnte das meiner Ansicht nach durchaus verschiedenen Communities den Weg ebnen, in echte Unabhängigkeit per IPv6 zu investieren.
Wir überlegen ob wir ein Modell in die Richtung anbieten können und wie das technisch am Besten per Ansible Playbook lösbar ist :). Wir denken über ein Wireguard/Vxlan Modell nach.
Nice. Aber wieso VXLAN, das bietet doch ggü. Wireguard für Layer 3 keinen Vorteil und anders als L2TP keine Möglichkeit, bei 1500er MTU zu bleiben, sondern verringert die innere MTU noch weiter? Ein Peering-WAN ist doch für BGP auch nicht notwendig?
Wir wollen vielleicht reines VXLAN oder reines Wireguard bereitstellen nicht ineinander. Aka man kann auswählen ob mit oder ohne Verschlüsselung. Beides aus dem Grund weil eh schon im Stack vorhanden und auch die Automatisierung beides kann ;).
Wie genau wir alles machen wollen steht aber noch etwas in den Sternen, erstmal muss unser zweiter Standort online kommen. Dann haben wir auch wieder Zeit uns mit sowas zu beschäftigen und wie man Transit für andere Communities stellen könnte.
).