Home Explore Help
Sign In
mark22k
/
mk16.de
mirror of https://codeberg.org/mark22k/mk16.de.git
Watch 1
Star 0
Fork 0
Files Issues 0
Tree: 143bffb5d7
Branches Tags
mk16.de
/
blog
/
beitritt_crxn.md

beitritt_crxn.md 6.4 KB
History Raw

layout: page title: Ich trete CRXN bei permalink: /blog/beitritt_crxn/ keywords: crxn,netzwerk,ipv6,routing,babel,beitreten,blog description: Ich bin dem CRXN Netzwerk beigetreten. Hier zeige ich die Unterschiede zum dn42 und welche Schritte ich gegangen bin, um beizutreten. lang: de feed: true

date: 2022-11-22 00:00:00 +0100

Hallo,

heute bin ich dem CRXN Netwerk beigetreten. Das CRXN ist ähnlich wie das dn42, jedoch mit vier Unterschieden:

  • Es verwendet nur IPv6
  • Es verwendet das Routing Protokoll babel
  • Es ist deutliche klein, was man an der Anzahl der Prefixe sehen kann
  • Es wird fastd als Tunnel verwendet

Ich wollte das CRXN auf den gleichen Knoten haben, die ich auch das dn42 Netzwerk benutzte, jedoch dürften sich die Routen der beiden Netzwerke nicht vermischen, da ihre Registries nicht miteinander synchronisiert sind, andere Routingprotokolle verwenden und allgemein keine Interkonnectivität zwsichen ihnen vorhanden ist. Dies stellte eine kleine Herausforderung da.

Des Weiteren ist es im CRXN aktuell (noch) nicht möglich die Routen zu validieren, sodass Route Hjacking oder ähnliches recht leicht ist.

Es verwendet nur IPv6

Ich halte für eine gute Entscheidung, nur IPv6 zu verwenden. Nicht umsonst ist IPv6 die Zukunft. CRXN verwendet den ULA Bereich. Dieser entspricht dem privaten IPv4 Bereich. Dieser Bereich ist so groß, dass es (wenn die Prefixe zufällig generiert werden) im Normalfall zu keiner Kollision zum Beispiel mit dem dn42 kommt.

Es verwendet das Routingprotokoll babel

Babel wird eigentlich für IGP eingesetzt, jedoch ist es auch möglich Netze damit zu verbinden. Das Routing wird so effizienter, da als Auswahlkriterium eine Metric bentzt wird, welche in der Referenzimplementierung (babeld), der Latenz in ms entspricht. Somit wird immer der Pfad mit der kürzesten Latenz verwendet. Auch bird und frr haben babel mittlerweile implementiert, jedoch wird dort die Metric (leider) nicht automatisch berechnet. Ich habe es so gemacht, dass ich diese zu Anfang eines Peering messe und dann manuell eintrage. Das Problem daran ist, dass sich Latenzen bedauerlicherweise verändern können - beispielsweise wenn sich das Underlay-Netzwerk (hier das Clearnet) verändert.

Es ist klein

Wenn man keine strenge Validierung der Routen vornimmt, erhält man ca. 20 IPv6 Prefixe. Wenn man eine strengere Validierung vornimmt, erhält man etwa 10 Prefixe. Bei dn42 (+ NeoNetwork + IC-VPN + ChaosVPN) sind es ca. 600 Prefixe.

Es verwendet fastd

In dn42 wird normalerweise WireGuard zum Peering benutzt, da dies einfach zu konfigurieren ist und eine gute Sicherheit bietet. Davor wurde OpenVPN verwendet. OpenVPN ist einmal langsamer und einmal unsicherer, wenn man es mit einem Preshared Key (PSK) verwendet. fastd wird auch von Freifunk / IC-VPN verwendet. Es handelt sich dabei auch um eine Tunnellösung, welche auch mit guter Sicherheit verschlüsselt ist. In Gegensatz zu WireGuard operiert es auf Layer 2 des OSI-Modells (MAC-Adressen), wobei WireGuard auf Layer 3 (IP-Adressen) arbeitet.

Mehrere Netze auf einem Knoten

Mehrere Netze auf einem Knoten - dafür gibt es verschiedene Lösungsansätze. Eine Lösung wäre mehrere bird Instanzen zu verwenden. Für diese Lösung fällt mir das Wissen und ist damit für mich zu aufwendig. Ein anderer Lösungsansatz wäre die Verwendung von verschiedenen Routing Tabellen. So könnte man mit ipv6 table crxn; eine zweite IPv6 Routing Table erstellen. Problematisch wird dieser Ansatz, wenn man - wie ich - mehrere Knoten hat, welche über iBGP verbunden ist. Ich müsste als doppelt so viele BGP Sessions als jetzt haben, da in einer BGP Session nicht mehrere Routing Tabellen übertragen werden können. Eine andere Möglichkeit ist das "markieren" von Routen. Beim Import würde die dn42 Routen mit "dn42" markiert und die CRXN Routen mit "crxn". Beim Export könnte man nun jede Route dem entsprechenden Netz zuordnen. Es gibt verschiedene Möglichkeiten, eine Route zu markieren. Die bekannteste ist wohl BGP Communities bzw. Large BGP Communities (bei 32-Bit ASNs) anzuhängen. Da dn42 Peers jedoch nur dn42 Routen erwarten, ist die Information, dass es sich um dn42 Routen handelt, unnötig und würde nur Platz in der Globalen Routing Tabelle einnehmen. Dies bedeutet, man müsste die entsprechenden Communities beim Export löschen. Das nächste Problem mit Communities war, dass ich zwei AS-Nummern habe. Einmal von dn42 und einmal vom NeoNetwork. Mit welcher sollte ich die Routen markieren? Da es nur intern wäre, wäre es egal. Eine Alternative zu den BGP communities stellen benutzerdefinierte BGP Attribute dar. Ein BGP Attribut ist beispielsweise bgp_local_pref oder bgp_med, jedoch kann man auch selber welche definieren. Für diese Möglichkeit habe ich mich entschieden. Ich habe mit attribute int netid; ein neues ganzzahliges Attribut mit dem Namen netid erstellt. Wenn die Route vom dn42 Netz bekommt, bekommt sie die ID 1. Wenn die Route vom CRXN Netz kommt, bekommt sie die ID 2. Entsprechend muss ich das andere Netz beim Export filtern. Somit habe ich alle Routen in einer Routing Tabelle und entsprechend markiert.

Fehlende Validierung der Routen

In dn42 kann man sich aus dem Registry ROA Einträge erzeugen lassen. In diesen steht drin, welches AS, welche Prefixe und mit welcher Länge announcen darf. In CRXN gibt es jedoch keine AS-Nummern, weshalb eine ROA Filterung nicht in Frage kommt. Als Registry gibt es lediglich eine entitydb, in welcher der Name des Netzwerkes und der Prefix des Netzwerkes angegeben ist. Die Dateien darin befinden sich im JSON Format. Die einzige Validierung, welche ich somit vornehmen kann, ist zu sagen, dass nicht-CRXN Prefixe nicht exportiert werden. Die Prefixe, welche erlaubt sind, parse ich mir wiederum aus der entitydb. Alle anderen Routen verwerfe ich.

Zukunft

Geplant ist eine eventuelle Vernetzung mit dem dn42. Dabei soll es eine ASN geben, welche die Berechtigung hat, alle CRXN Routen zu exportieren. Mit entsprechender Konfiguration könnte man so mehrere Gateways zwischen dem dn42 und dem CRXN herstellen. Es bleibt spannend.

Links