Freifunk-Gateway aufsetzen/gre: Unterschied zwischen den Versionen

Version vom 23. Juni 2019, 13:18 Uhr

GRE

Da GRE ein sehr schnelles Tunnelprotokoll ist und wenig Overhead erzeugt ist es für die Verbindung zwischen Routern in Rechenzentren sehr gut geeigent.

Interface anlegen

Um die einzelnen Hoods miteinander zu verbinden werden die jeweiligen Router über GRE-Tunnel miteinander verbunden. Dafür muss auf beiden Seiten ein passendes Interface angelegt werden. Hierfür muss man mit dem Admin des jeweiligen Tunnelpartners in Kontakt treten. Eine unvollständige Liste an Peeringangeboten findet sich hier: Portal:Layer3Peering.

Da Babel über IPv6-Multicasts kommuniziert, müssen dem Interface noch link-local Adressen hinzugefügt (passiert nicht immer automatisch) und Multicast aktiviert werden. Am besten generiert man sich die link-local zufällig um Kollisionen zu vermeiden.

Die Debian Interfacekonfiguration sollte dann etwa so aussehen. Der Interfacename (Platzhalter "<IFNAME>") kann frei gewählt werden (meist maximal 15 Zeichen):

auto <IFNAME>
iface <IFNAME> inet6 static
	address fe80::IRGENDWAS/64

	#IPv4 GRE
	#pre-up ip -4 tunnel add $IFACE mode gre local EIGENEPUBLICIP remote REMOTEPUBLICIP ttl 255
	#IPv6 GRE
	pre-up ip -6 tunnel add $IFACE mode ip6gre local EIGENEPUBLICIP remote REMOTEPUBLICIP ttl 255

	post-down ip tunnel del $IFACE

	# Enable Multicast for Babel
	up ip link set dev $IFACE multicast on

	# iif rules
	post-up ip -6 rule add iif $IFACE table fff
	post-down ip -6 rule del iif $IFACE table fff

iface <IFNAME> inet static
	address 10.83.252.x/32
	scope link

	# iif rules
	post-up ip -4 rule add iif $IFACE table fff
	post-down ip -4 rule del iif $IFACE table fff

Die Interfacekonfiguration kann dann über den Aufruf von ifup <IFNAME> bzw. ifdown <IFNAME> gestartet bzw. gestoppt und damit das Interface konfiguriert bzw. dekonfiguriert werden.

Verbindung testen

Nach Aufruf von ip link bzw. ip addr sollte ein passender Eintrag für den Tunnel auftauchen:

7: <IFNAME>@NONE: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1448 qdisc noqueue state UNKNOWN group default qlen 1
    link/gre6 EIGENEPUBLICIP peer REMOTEPUBLICIP
    inet 10.83.252.x/32 brd 10.83.252.x scope link <IFNAME>
       valid_lft forever preferred_lft forever
    inet6 fe80::IRGENDWAS/64 scope link 
       valid_lft forever preferred_lft forever

Ein Multicast Ping auf das GRE-Tunnel-Interface zeigt, ob die Gegenstelle korrekt erreichbar ist:

ping ff02::1%<IFNAME>

@@ Zeile 1: / Zeile 1: @@
 == GRE ==
-Da GRE ein sehr schnelles Tunnelprotokoll ist und wenig Overhead erzeugt macht es Sinn Gateways (sofern beide Seiten eine feste IP haben und nicht hinter NAT stecken) per GRE Tunnel zu verbinden und darüber Babel laufen zu lassen. Alternativ kann z.b. wireguard verwendet werden wenn eine Seite hinter einem NAT steckt und/oder keine feste IP hat (bei dezentralen Gateways oft der Fall).
+Da GRE ein sehr schnelles Tunnelprotokoll ist und wenig Overhead erzeugt ist es für die Verbindung zwischen Routern in Rechenzentren sehr gut geeigent.
-Theoretisch kann man natürlich auch OpenVPN oder fastd oder einen ganz anderen Layer 3 Tunnel verwenden, ob dies Sinn macht muss jeder für sich entscheiden.
 === Interface anlegen ===
-Um die einzelnen Hoods miteinander zu verbinden, werden die jeweiligen Gateways über GRE-Tunnel miteinander verbunden. Es reicht dabei nicht, den GRE Tunnel nur auf einem Gateway einzurichten, vielmehr müssen beide zu verbindende Gateways konfiguriert werden. Hierfür muss man mit dem Admin des jeweiligen Tunnelpartners in Kontakt treten => [[Portal:Layer3Peering]].
+Um die einzelnen Hoods miteinander zu verbinden werden die jeweiligen Router über GRE-Tunnel miteinander verbunden.
+Dafür muss auf beiden Seiten ein passendes Interface angelegt werden. Hierfür muss man mit dem Admin des jeweiligen Tunnelpartners in Kontakt treten. Eine unvollständige Liste an Peeringangeboten findet sich hier: [[Portal:Layer3Peering]].
-Da Babel über IPv6-Multicasts kommuniziert, müssen den GRE-Tunnel noch link-local Adressen gegeben werden, da GRE-Tunnel auf Layer3 arbeiten und somit keine MAC-Adresse haben -> link-local kann nicht aus MAC automatisch generiert werden.
+Da Babel über IPv6-Multicasts kommuniziert, müssen dem Interface noch link-local Adressen hinzugefügt (passiert nicht immer automatisch) und Multicast aktiviert werden.
-Am besten generiert man sich die link-local zufällig.
+Am besten generiert man sich die link-local zufällig um Kollisionen zu vermeiden.
-Siehe: http://wiki.hwmn.org/w/GRE_Tunnel#Babel_support
+Die Debian Interfacekonfiguration sollte dann etwa so aussehen.
+Der Interfacename (Platzhalter "<IFNAME>") kann frei gewählt werden (meist maximal 15 Zeichen):
-Die Schnittstellenkonfiguration sollte dann etwa so aussehen:
 <pre>
-auto DEVICENAME
+auto <IFNAME>
-iface DEVICENAME inet static
+iface <IFNAME> inet6 static
-  address 10.83.252.x/32
+	address fe80::IRGENDWAS/64
-  #IPv4 GRE
+	#IPv4 GRE
-  #pre-up ip -4 tunnel add $IFACE mode gre local EIGENEPUBLICIP remote REMOTEPUBLICIP ttl 255
+	#pre-up ip -4 tunnel add $IFACE mode gre local EIGENEPUBLICIP remote REMOTEPUBLICIP ttl 255
-  #IPv6 GRE
+	#IPv6 GRE
-  pre-up ip -6 tunnel add $IFACE mode ip6gre local EIGENEPUBLICIP remote REMOTEPUBLICIP ttl 255
+	pre-up ip -6 tunnel add $IFACE mode ip6gre local EIGENEPUBLICIP remote REMOTEPUBLICIP ttl 255
-  up ip link set dev $IFACE multicast on
+	post-down ip tunnel del $IFACE
-  post-up ip rule add iif $IFACE table fff
+	# Enable Multicast for Babel
-  post-down ip rule del iif $IFACE table fff
+	up ip link set dev $IFACE multicast on
-  post-down ip tunnel del $IFACE
+	# iif rules
+	post-up ip -6 rule add iif $IFACE table fff
+	post-down ip -6 rule del iif $IFACE table fff
-iface DEVICENAME inet6 static
+iface <IFNAME> inet static
-  address fe80::IRGENDWAS/64
+	address 10.83.252.x/32
+	scope link
-  post-up ip -6 rule add iif $IFACE table fff
+	# iif rules
-  post-down ip -6 rule del iif $IFACE table fff
+	post-up ip -4 rule add iif $IFACE table fff
+	post-down ip -4 rule del iif $IFACE table fff
 </pre>
-Der Tunnel kann über den Aufruf von
+Die Interfacekonfiguration kann dann über den Aufruf von <code>ifup <IFNAME></code> bzw. <code>ifdown <IFNAME></code> gestartet bzw. gestoppt und damit das Interface konfiguriert bzw. dekonfiguriert werden.
-<code>
-ifup <tunnel>
-</code>
-...aufgebaut werden, wobei <tunnel> der Name des GRE-Interfaces ist (im Beispiel ro1)
 === Verbindung testen ===
-Nach Aufruf von ip link bzw. ip addr..
+Nach Aufruf von <code>ip link</code> bzw. <code>ip addr</code> sollte ein passender Eintrag für den Tunnel auftauchen:
-<code>
-ip link
-</code>
-sollten wir einen Eintrag für den Tunnel vorfinden:
 <pre>
-.
+: <IFNAME>@NONE: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1448 qdisc noqueue state UNKNOWN group default qlen 1
-.
-yy: DEVICENAME@NONE: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1448 qdisc noqueue state UNKNOWN group default qlen 1
      link/gre6 EIGENEPUBLICIP peer REMOTEPUBLICIP
-     inet 10.83.252.x/32 brd 10.83.252.x scope link DEVICENAME
+     inet 10.83.252.x/32 brd 10.83.252.x scope link <IFNAME>
         valid_lft forever preferred_lft forever
      inet6 fe80::IRGENDWAS/64 scope link
         valid_lft forever preferred_lft forever
-.
-.
 </pre>
-Ein Multicast Ping auf das GRE-Tunnel-Interface zeigt ob die Gegenstelle erreichbar ist:
+Ein Multicast Ping auf das GRE-Tunnel-Interface zeigt, ob die Gegenstelle korrekt erreichbar ist:
 <code>
-ping ff02::1%[GRE-Tunnel-Name]
+ping ff02::1%<IFNAME>
 </code>