Freifunk-BGP-Gateway: Unterschied zwischen den Versionen
McUles (Diskussion | Beiträge) |
Keine Bearbeitungszusammenfassung |
||
(2 dazwischenliegende Versionen von 2 Benutzern werden nicht angezeigt) | |||
Zeile 1: | Zeile 1: | ||
In dieser Anleitung geht es darum, wie man BGP spricht und diese Routen ins Babel verteilt, um Adressen aus einem eigenen AS für Freifunk zur Verfügung zu stellen. | {{Outdated}} | ||
In dieser Anleitung geht es darum, wie man BGP spricht und diese Routen ins [[Babel]] verteilt, um Adressen aus einem eigenen AS für Freifunk zur Verfügung zu stellen. | |||
Das ganze ist alles noch im Aufbau und die Anleitung ist auch den ersten Livesystem entstanden. Es kann durchaus sein, das hier noch viel Optimierungspotential vorhanden ist. | Das ganze ist alles noch im Aufbau und die Anleitung ist auch den ersten Livesystem entstanden. Es kann durchaus sein, das hier noch viel Optimierungspotential vorhanden ist. | ||
Zeile 5: | Zeile 7: | ||
== Grundlegendes == | == Grundlegendes == | ||
* Routing im Linux aktivieren | * Routing im Linux aktivieren | ||
* Wir legen | * Wir legen zwei Kernel-Routingtabellen an. In einer landet der Freifunk-Kram in der anderen die Internet-Routen. | ||
== | == BIRD installieren und einrichten == | ||
[[BIRD]] installieren. | |||
<pre> | <pre> | ||
apt-get install bird | apt-get install bird | ||
Zeile 34: | Zeile 36: | ||
=== Bird config === | === Bird config === | ||
Dies ist die Konfiguration von fff-zeus um die F3N Freifunk | Dies ist die Konfiguration von fff-zeus um die F3N-Freifunk-IPs zu announcen. | ||
Die konkreten Werte müssen für ein eigenes Border-Gateway '''UNBEDINGT''' angepasst werden! | Die konkreten Werte müssen für ein eigenes Border-Gateway '''UNBEDINGT''' angepasst werden! | ||
<pre> | <pre> | ||
Zeile 82: | Zeile 84: | ||
</pre> | </pre> | ||
Einzelne Protokolle können ab/aufgewertet werden. Dazu ist folgender Schalter in das Protokoll mit einzubauen: | Einzelne Protokolle können ab-/aufgewertet werden. Dazu ist folgender Schalter in das Protokoll mit einzubauen: | ||
<pre> | <pre> | ||
default bgp_local_pref 10; | default bgp_local_pref 10; | ||
Zeile 96: | Zeile 98: | ||
== Babel == | == Babel == | ||
wird hier neu gemacht -> https://wiki.freifunk-franken.de/w/Freifunk-Gateway_aufsetzen/bird2 | |||
=== Babel config === | === Babel config === | ||
Die | Die [[Babel]]config kann so aussehen: | ||
<pre> | <pre> | ||
[...] | [...] | ||
Zeile 135: | Zeile 139: | ||
</pre> | </pre> | ||
Mit dieser Konfiguration ist eine default-Route für das <default_src_prefix> nun im ganzen Babelnetz bekannt und jeder kann theoretisch im Babelnetz sich nun daraus Subnetze "herausziehen" und z. | Mit dieser Konfiguration ist eine default-Route für das <default_src_prefix> nun im ganzen [[Babelnetz|Babel]] bekannt und jeder kann theoretisch im Babelnetz sich nun daraus Subnetze "herausziehen" und z.B. in eine Hood weiter verteilen. | ||
Hier muss noch diskutiert werden ob und wie das ganze am sinnvollsten gefiltert werden sollte. | Hier muss noch diskutiert werden ob und wie das ganze am sinnvollsten gefiltert werden sollte. | ||
== Freifunk Gateway IPv6 verteilen == | == Freifunk Gateway IPv6 verteilen == | ||
Wie oben bereits gesagt, kann nun aus diesem verteilten Netzblock von oben auf jedem anderen Server im L3 Netz ein /64 herausgezogen und in eine Hood verteilt werden. Dazu ist es zwingend nötig das auf dem ganzen Peeringweg zum BGP Gateway mindestens an jeden GRE Interface die Rule: | Wie oben bereits gesagt, kann nun aus diesem verteilten Netzblock von oben auf jedem anderen Server im L3 Netz ein /64 herausgezogen und in eine Hood verteilt werden. Dazu ist es zwingend nötig das auf dem ganzen Peeringweg zum BGP-Gateway mindestens an jeden GRE Interface die Rule: | ||
* post-up ip -6 rule add iif $IFACE table fff | * post-up ip -6 rule add iif $IFACE table fff | ||
dran hängt. Dies ist mittlerweile auch in der Gateway Anleitung fest geschrieben war aber früher nie der Fall. | dran hängt. Dies ist mittlerweile auch in der Gateway-Anleitung fest geschrieben war aber früher nie der Fall. | ||
Sinnvoll ist natürlich jederzeit ein direktes Peering und dann auch eine Peering IP (am besten eine /128 aus dem Subnetz) auf dem GRE Interface. | Sinnvoll ist natürlich jederzeit ein direktes Peering und dann auch eine Peering-IP (am besten eine /128 aus dem Subnetz) auf dem GRE-Interface. | ||
Ein Babel Peeringinterface kann z.b. dann so aussehen: | Ein [[Babel]]-Peeringinterface kann z.b. dann so aussehen: | ||
<pre> | <pre> | ||
iface eth1 inet6 static | iface eth1 inet6 static | ||
Zeile 154: | Zeile 158: | ||
schon jetzt sollte das BGP Gateway erreichbar sein. | schon jetzt sollte das BGP Gateway erreichbar sein. | ||
Danach nimmt man sich aus dem /48 ein /64 (falls man das BGP Gateway nicht selbst betreibt nach Rückfrage mit dem Betreiber, da dieser evtl. filtert!) und hängt sich davon eine IP ans batX Interface, setzt eine Route in die fff Tabelle und verteilt per radvd | Danach nimmt man sich aus dem /48 ein /64 (falls man das BGP-Gateway nicht selbst betreibt nach Rückfrage mit dem Betreiber, da dieser evtl. filtert!) und hängt sich davon eine IP ans batX-Interface, setzt eine Route in die fff-Tabelle und verteilt per radvd RAs in die Hood: | ||
batX: | batX: |
Aktuelle Version vom 27. Dezember 2022, 19:45 Uhr
Diese Seite enthält veraltete Informationen!
Möglicherweise hat der Inhalt aktuell keine Relevanz mehr oder muss aktualisiert werden.
In dieser Anleitung geht es darum, wie man BGP spricht und diese Routen ins Babel verteilt, um Adressen aus einem eigenen AS für Freifunk zur Verfügung zu stellen.
Das ganze ist alles noch im Aufbau und die Anleitung ist auch den ersten Livesystem entstanden. Es kann durchaus sein, das hier noch viel Optimierungspotential vorhanden ist.
Grundlegendes
- Routing im Linux aktivieren
- Wir legen zwei Kernel-Routingtabellen an. In einer landet der Freifunk-Kram in der anderen die Internet-Routen.
BIRD installieren und einrichten
BIRD installieren.
apt-get install bird
Peering Interfaces
Es muss ein Partner vorhanden sein, mit dem man BGP sprechen kann. Entweder direkt oder per Tunnel. HE bietet kostenlos einen entsprechenden Tunnel an: Tunnelbroker
Privates Peering
(Beispiel, am Ende muss zusammen ausgehandelt werden wie man peert)
auto cd-bgp iface cd-bgp inet6 static address EIGENE-IPv6_TUNNEL_IP/64 pre-up ip tunnel add $IFACE mode ip6gre remote PARTNER-PUBLIC-IP local EIGENE_PUBLIC_IP ttl 255 post-down ip tunnel del $IFACE # -------- # /|_| |_| \ o # | | o # --O---O--==
Bird config
Dies ist die Konfiguration von fff-zeus um die F3N-Freifunk-IPs zu announcen. Die konkreten Werte müssen für ein eigenes Border-Gateway UNBEDINGT angepasst werden!
router id <ipv4-adresse>; # Get interface information protocol device { scan time 15; } # Export all known Routes into ft, which is used as default table protocol kernel { scan time 15; export all; kernel table 100; } # Identify F3N IP's filter net_f3n { if (net ~ <prefix_to_announce_routes_inside>) then { # route is inside F3N Prefix if (net.len != 48) then { # add penalty to less backup-routes bgp_path.prepend(205100); bgp_path.prepend(205100); } accept; } else { reject; } } # Configure F3N IP's static protocol static static_f3n { import all; route <prefix_to_announce> reject; } protocol bgp he { local as <local_as>; source address <peering_ip_local>; neighbor <peering_ip_remote> as <remote_as>; import all; export filter net_f3n; }
Einzelne Protokolle können ab-/aufgewertet werden. Dazu ist folgender Schalter in das Protokoll mit einzubauen:
default bgp_local_pref 10;
- default ist 100
- kleiner ist niedrigere Prio, höher ist höhere Prio.
Paar wichtige CLI Befehle rund um bird:
- birdc6 show route export $PROTOCOL
- birdc6 show protocols all
- birdc6 show route protocol $PROTOCOL primary
Babel
wird hier neu gemacht -> https://wiki.freifunk-franken.de/w/Freifunk-Gateway_aufsetzen/bird2
Babel config
Die Babelconfig kann so aussehen:
[...] redistribute local ip <prefix_to_announce_local_addresses_from> redistribute local deny redistribute ip ::/0 src-ip <only_match_src_specific_routes_inside_this_prefix> src-eq <and_this_src_prefix_length> redistribute ip ::/0 src-ip <only_match_src_specific_routes_inside_this_prefix> metric 512 # backup-route [...]
Babel Interface
Die Konfiguration eines babel-Interface kann so aussehen:
auto ens7 iface ens7 inet6 manual # to f3n post-up ip -6 rule add to 2a0b:f4c0::/40 pref 5000 lookup fff pre-down ip -6 rule del to 2a0b:f4c0::/40 pref 5000 lookup fff # from f3n post-up ip -6 rule add from 2a0b:f4c0::/40 pref 1000 lookup ft pre-down ip -6 rule del from 2a0b:f4c0::/40 pref 1000 lookup ft post-up ip -6 rule add from 2a0b:f4c0::/40 pref 5000 lookup fff pre-down ip -6 rule del from 2a0b:f4c0::/40 pref 5000 lookup fff # add default routes for fff post-up ip -6 route replace default from <default_src_prefix> dev $IFACE table fff proto static pre-down ip -6 route del default from <default_src_prefix> dev $IFACE table fff proto static # less specific (fallback) post-up ip -6 route replace default from 2a0b:f4c0::/40 dev $IFACE table fff proto static pre-down ip -6 route del default from 2a0b:f4c0::/40 dev $IFACE table fff proto static
Mit dieser Konfiguration ist eine default-Route für das <default_src_prefix> nun im ganzen Babel bekannt und jeder kann theoretisch im Babelnetz sich nun daraus Subnetze "herausziehen" und z.B. in eine Hood weiter verteilen. Hier muss noch diskutiert werden ob und wie das ganze am sinnvollsten gefiltert werden sollte.
Freifunk Gateway IPv6 verteilen
Wie oben bereits gesagt, kann nun aus diesem verteilten Netzblock von oben auf jedem anderen Server im L3 Netz ein /64 herausgezogen und in eine Hood verteilt werden. Dazu ist es zwingend nötig das auf dem ganzen Peeringweg zum BGP-Gateway mindestens an jeden GRE Interface die Rule:
- post-up ip -6 rule add iif $IFACE table fff
dran hängt. Dies ist mittlerweile auch in der Gateway-Anleitung fest geschrieben war aber früher nie der Fall. Sinnvoll ist natürlich jederzeit ein direktes Peering und dann auch eine Peering-IP (am besten eine /128 aus dem Subnetz) auf dem GRE-Interface. Ein Babel-Peeringinterface kann z.b. dann so aussehen:
iface eth1 inet6 static address OWN_PEERING_IP/128 post-up ip -6 rule add from all iif eth1 lookup fff ip -6 rule add from all to OWN_SUBNET/48 lookup fff
schon jetzt sollte das BGP Gateway erreichbar sein.
Danach nimmt man sich aus dem /48 ein /64 (falls man das BGP-Gateway nicht selbst betreibt nach Rückfrage mit dem Betreiber, da dieser evtl. filtert!) und hängt sich davon eine IP ans batX-Interface, setzt eine Route in die fff-Tabelle und verteilt per radvd RAs in die Hood:
batX:
[...] post-up ip -6 route add OWN_SUBNET:1::/64 dev $IFACE proto static tab fff post-up ip -6 rule add iif batX lookup fff post-up ip -6 rule add from OWN_SUBNET/48 lookup fff post-up ip -6 addr add OWN_SUBNET:1::1/64 dev batX [...]
Babel muss auch noch ein bisschen erweitert werden:
redistribute local ip 10.50.0.0/16 redistribute local ip 10.83.0.0/16 redistribute local ip fd43:5602:29bd::/48 redistribute local ip OWN_NET::/32 redistribute local deny redistribute ip 10.50.0.0/16 redistribute ip 10.83.0.0/16 redistribute ip 144.76.70.189/32 redistribute ip fd43:5602:29bd::/48 redistribute ip OWN_NET::/32
Es wird dringend empfohlen Babel 1.8 zu installieren. Gibt babeld --v keine Version mit aus ist auf jeden Fall <1.7 installiert. Achtung: Das Init Script von den Debian Repos zeigt auf ein anderes Verzeichnis als wenn man Babel selbst baut. Entweder die Binary ins richtige Verzeichnis kopieren oder das Init Script anpassen!
Version kann man auch herausfinden wenn man sich mit nc ::1 33123 auf die Babelkonsole verbindet, dort wir die aktuell laufende Version ausgegeben.
/etc/radvd.conf:
interface batX { AdvSendAdvert on; MinRtrAdvInterval 60; MaxRtrAdvInterval 300; AdvDefaultLifetime 600; prefix OWN_SUBNET:1::/64 { AdvOnLink on; AdvAutonomous on; }; };