Gateway-Gateway Tunnel

jjsa · 30. März 2016 um 09:23

Gateway Gatweway Datenverkehr

Gateways sind des öfterens über ein Tunnel miteinander verbunden. Damit alle Freifunk Geräte (GW, Node, clients) im gleicher Segment erscheinen werden die entsprechende Tunnel Interface im Batman-adv Switch eingebunden.

IPv6

Die Router Advertissement Nachrichten von alle radvd Server erreichen sämtliche Clients. Die Vorgabe Route für alle beteiligten wird entsprechend der zuletzt empfangenen Router Advertissement Nachrich eingestellt. Dies bedeutet, dass ein großer Teil des Verkehrs über der GW-GW Tunnel zum Ziel geleitet wird.

Die Lösung zu diese Problematik, ist es per ebtables die icmpv6 RA Nachricht aus den falschen Segment zu unterbinden. Damit kann sichergestellt werden, dass der IPv6 Verkehr ohne Umweg über ein weiteren GW im Internet gesendet wird.

IPv4

Alle DHCP Server sind von den clients erreichbar. Ein Client versucht bei eine neue Verbindung die vorgehende IP Adresse zu erhalten. Damit wird auch der Verkher unter umständen über ein weitere GR weitergeleitet. Bei Mobile Geräte die den Bereich eine Node verlassen und sich mit der nächste Node verbinden wäre es sinnvoll und erwünscht falls ein transparente Takeover vorhaden wäre.

Wenn ein Client außerhab des Freifunk Netzes kommt (oder abgeschaltet wird) und später sind wieder mit das Freifunk Netz sich verbindet, ist das Verhalten fehlerhaft. Der Client verlangt nach der zuvor zugeteilte IPV4 Adresse die nicht unbedingt auf der Gateway verwaltet wird mit den der FF-Router verbunden ist.

Batman-adv richtig einzusetzen ist die Lösung des Problems.

GW Beispiel

GW1     GW2_

/                         \   /                          \
    [br0]                        [br0]
          |                            |
    +--[bat0]--+                 +--[bat0]--+
    |          |                 |          |

[fastd]-+      ±[gw2]-> <-[gw1]-+          ±[fastd]
IP4 DHCP Adresse,…

10.x.0.0-10.x.3.254           10.x.4.0-10.x.7.254
IP6      default Gateway (Link-Locale Adresse), …
Vereinfachte Darstellung:

Mit diese Konfiguratuon ist ebtables leider nicht einsetzbar.

Das Routing innerhalb der Brücke br0 kann mit ebtables beeinflusst werden. Da wir lediglich ein einziger Interface in der Brücke haben kann diese Konfiguration nicht verwendet werden.

Wenn die 2 in bat0 eingebundene Schnittstellen in eigenen bat Gerät eingebunden erhalten wir nachstehendes:ſ

GW1       GW2_

/                         \     /                          \
    [br0]                          [br0]
         | |                            | |
  [bat0]-+ +-[bat1]              [bat1]-+ +-[bat0]
    |          |                   |          |

[fastd]-+      ±[gw2]->   <-[gw1]-+          ±[fastd]
IP4 DHCP Adresse,…

10.x.0.0-10.x.3.254           10.x.4.0-10.x.7.254
IP6      default Gateway (Link-Locale Adresse), …
Vereinfachte Darstellung:

Die ebtables Rules sind auf der Bridge br0 anwendbar.
Die Segmente von GW1 und GW2 werden in diesem Fall über die Bridge br0 und nicht mittels batman-adv verbunden. Batctl o listet nicht die Node die über der Nachbar Gateway angeschlossen, es ist jedoch weiterhin die Node zu erreichen.

DHCP Request usw. werden über die bat Geräte nicht "forrwarded". Damit sind Probleme micht vorhanden.

Für der Meshviewer stellt der neuen Aufbau kein Problem die Alfred Master Announcement werden über der Bridge auf alle bat Geräte der Bridge versendet.

Änderung der Dateien /etc/network/Interfaces

Die Änderungen sind nicht umfangreich, es müssen lediglich die Definition der bat1 Schnittstelle eingefügt (Eine angepasste Kopie von bat0) und ftun-q# leicht verändert werden.

auto tun-gw1 iface tun-gw1 inet manual pre-up ip link add tun-gw1 type gretap local <IP-Adresse eth0> remote <Ext. IP Adresse des remote GW> 64 dev eth0 key 111 pre-up ebtables -A INPUT -p ipv6 -i bat1 --ip6-proto ipv6-icmp --ip6-icmp-type router-advertisement -j DROP pre-up ebtables -A FORWARD -p ipv6 -i bat1 --ip6-proto ipv6-icmp --ip6-icmp-type router-advertisement -j DROP pre-up ip link set dev ftun-q0 address <Eindeutige MAC> up post-up batctl -m bat1 if add tun-gw1 post-up bactl -m bat1 it 10000 post-up batctl -m bat1 gw server 50000/50000 post-down ebtables -D INPUT -p ipv6 -i bat1 --ip6-proto ipv6-icmp --ip6-icmp-type router-advertisement -j DROP post-down ebtables -D FORWARD -p ipv6 -i bat1 --ip6-proto ipv6-icmp --ip6-icmp-type router-advertisement -j DROP post-down ip link del tun-gw1

allow-hotplug bat0
…

allow-hotplug bat1
iface bat1 inet6 manual
pre-up modprobe batman-adv
pre-up ip link set dev bat1 address <EIndeutige MAC-Adresse> up
post-up brctl addif br0 bat1
post-up batctl -m bat1 it 10000
post-up batctl -m bat1 gw server 50000/50000

Comacho · 30. März 2016 um 10:20

Sorry das ich so direkt Frage, hast Du Zugang zu einem Freifunk Gateway?
Denn was Du hier schreibst, stimmt teilweise nicht, zumindest im Usecase mit Gluon + Batman.
Oder da versteht jemand nicht wie die Software funktioniert mit der gearbeitet wird.

Zum zweiten Teil bei IPv6, das passiert so aber auch nur wenn dieses GW auch
den BGP Traffic bekommt (ich gehe mal davon aus das kein Nat gemacht wird?).
Ansonsten geht der Traffic trotzdem quer durchs Netz, es sei denn Ihr Announced
auch versch. Präfixe.

IPv4 …Batman richtig einsetzen?

Dir ist schon klar das Batman das auf Gluon Seite immer so macht, wie im Link beschrieben.
Batman wählt das Gateway und forwarded den Request. Filter sind nicht nötig.

Was bringt dieses Setup?

ebtables -A FORWARD -p IPv6 -i bat-XYZ --ip6-proto ipv6-icmp --ip6-icmp-type router-advertisement -j DROP

Mehr gibts bei uns zb. nicht an Rules.

GRETAP kann ich auch niemanden empfehlen, es wird oft von Providern gefiltert
und es ist nur eine frickel Lösung die es nicht mal offiziell von Cisco gibt.
Benutzt besser L2TP da gibts die Auswahl zwischen UDP(Ports) oder IP Encapsuliert.
So sieht bei uns ein Tunnel aus der 5 Batman Instanzen auf den Gateways verbindet.

auto node01-en
iface node01-en inet6 manual
  pre-up ip l2tp add tunnel tunnel_id 30001 peer_tunnel_id 10003 encap ip local 78.xx.xx.xx remote 5.xxx.xx.xx ; exit 0
  pre-up ip l2tp add session tunnel_id 30001 session_id 30101 peer_session_id 10103 name node01-X ; exit 0
  pre-up ip l2tp add session tunnel_id 30001 session_id 30201 peer_session_id 10203 name node01-Y ; exit 0
  pre-up ip l2tp add session tunnel_id 30001 session_id 30301 peer_session_id 10303 name node01-Z ; exit 0
  pre-up ip l2tp add session tunnel_id 30001 session_id 30401 peer_session_id 10403 name node01-A ; exit 0
  pre-up ip l2tp add session tunnel_id 30001 session_id 30501 peer_session_id 10503 name node01-B ; exit 0
  post-up ip link set dev node01-X mtu 1346
  post-up ip link set dev node01-Y mtu 1346
  post-up ip link set dev node01-Z mtu 1346
  post-up ip link set dev node01-A mtu 1346
  post-up ip link set dev node01-B mtu 1346
  post-up ip link set up dev node01-X
  post-up ip link set up dev node01-Y
  post-up ip link set up dev node01-Z
  post-up ip link set up dev node01-A
  post-up ip link set up dev node01-B
  post-up batctl -m bat-X if add node01-X
  post-up batctl -m bat-Y if add node01-Y
  post-up batctl -m bat-Z if add node01-Z
  post-up batctl -m bat-A if add node01-A
  post-up batctl -m bat-B if add node01-B
  post-down ip l2tp del tunnel tunnel_id 30001 peer_tunnel_id 10003 encap ip local 78.xx.xxx.xx remote 5.xx.xxx.xxx

jjsa · 30. März 2016 um 11:13

Wir betreiben 2 Gateways. Diese sind per Gre Tunnel miteinander verbunden.
Da ich sicher sein wollte, dass der Betrieb unsere GW nicht gestört wird, habe ich 2 GW in VirtualBox aufgesetzt und die Interfaces Dateien an meine Vorstellungen angepasst und natürlich einige Tests vorgenommen.
Als Client diente der Rechner auf den die VM installiert wurden. Ich habe der Netzwerkverkehr usw. kontrolliert, konnte kein Problem feststellen.
Router Advertisement werden nicht über die Bridge „forwarded“, somit erhalten die clients keine fehlerhaften Route Informationen. DHCP Discover, … werden durch batman ausgefiltert, damit können sich die Client nur mit das eigentlichen GW unterhalten. Dies sorgt dafür, dass der Tunnel GW<->GW nicht auf eine unangemessene Weise belastet wird.
Die Batman.adv Dok. habe ich schon gelesen, sie ist ein wenig unvollständig!

jjsa · 30. März 2016 um 14:11

Hallo Comacho,

Am 30.03.2016 um 12:31 schrieb Comacho:

Sorry das ich so direkt Frage, hast Du Zugang zu einem Freifunk
Gateway?
Kein Problem!
unsere Node haben ein Freifunk Zugang. Von Meine Rechner aus kann ich
auch ein Zugang „starten“ der Rechner kann parallel zu normaler Betrieb
auch als FF-Router fungieren,

Denn was Du hier schreibst, stimmt teilweise nicht, zumindest im
Usecase mit Gluon + Batman.
Ich befasse mir nur mir die Gateways, ich habe mit VirtualBox 2 GW
konfiguriert, die Verbindung zur AS ist nicht vorhanden, ich könnte
es aber simulieren.
Als Client dient wiederum der PC von dem ich eine Verbindung über
fastd zu einer der „GW“ erstelle.

Oder da versteht jemand nicht wie die Software funktioniert mit der
gearbeitet wird.
ich bin von der Konfiguration die ich auf unsere GW vorgefunden habe
ausgegangen.

Zum zweiten Teil bei IPv6, das passiert so aber auch nur wenn
dieses GW auch den BGP Traffic bekommt (ich gehe mal davon aus das
kein Nat gemacht wird?). Ansonsten geht der Traffic trotzdem quer
durchs Netz, es sei denn Ihr Announced auch versch. Präfixe.
Es geht hier um den querrtrafic zwischen die GW. Dort haben wir kein
BGP. Beide GW sind im gleichen virtuelle Batman-Switch. Damit haben
wir 2 dhcp und 2 Router Advertisement Instance im FF-Netz.

IPv4 …Batman richtig einsetzen?
Gateways - batman-adv - Open Mesh Dir ist
schon klar das Batman das auf Gluon Seite immer so macht, wie im
Link beschrieben. Batman wählt das Gateway und forwarded den
Request. Filter sind nicht nötig.
Das ganze läuft nicht auf Gluon Ebene.

Was bringt dieses Setup?

ebtables -A FORWARD -p IPv6 -i bat-XYZ --ip6-proto ipv6-icmp
–ip6-icmp-type router-advertisement -j DROP

Die RouterAdvwertisements aus bat-XYZ werden nicht im Teilnetz
des GW-UVW weitergereicht. Damit ist im Teilnetz BAT-UVW nur ein
Router Advertisment Server tätig.

Mehr gibts bei uns zb. nicht an Rules.

GRETAP kann ich auch niemanden empfehlen, es wird oft von Providern
gefiltert und es ist nur eine frickel Lösung die es nicht mal
offiziell von Cisco gibt. Benutzt besser L2TP da gibts die Auswahl
zwischen UDP(Ports) oder IP Encapsuliert. So sieht bei uns ein
Tunnel aus der 5 Batman Instanzen auf den Gateways verbindet.

Unterschiedlische Teilbereiche für die FF-Router, sprich hamburg,
berlin, bremen, … ?