Freifunk-Gateway aufsetzen/gre: Unterschied zwischen den Versionen

Aus Freifunk Franken
Wechseln zu:Navigation, Suche
(Die Seite wurde neu angelegt: „== 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 h…“)
 
Zeile 45: Zeile 45:
</code>
</code>
...aufgebaut werden, wobei <tunnel> der Name des GRE-Interfaces ist (im Beispiel ro1)
...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 ip link bzw. ip addr..
Zeile 63: Zeile 65:
.
.
</pre>
</pre>
Ein Multicast Ping auf das GRE-Tunnel-Interface zeigt ob die Gegenstelle erreichbar ist:
<code>
ping ff02::1%[GRE-Tunnel-Name]
</code>

Version vom 11. Februar 2019, 16:07 Uhr

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). 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.

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. Am besten generiert man sich die link-local zufällig.

Siehe: http://wiki.hwmn.org/w/GRE_Tunnel#Babel_support


Die Schnittstellenkonfiguration sollte dann etwa so aussehen:

auto DEVICENAME
iface DEVICENAME inet static
  address 10.83.252.x/32

  #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

  up ip link set dev $IFACE multicast on

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

  post-down ip tunnel del $IFACE

iface DEVICENAME inet6 static
  address fe80::IRGENDWAS/64

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

Der Tunnel kann über den Aufruf von ifup <tunnel> ...aufgebaut werden, wobei <tunnel> der Name des GRE-Interfaces ist (im Beispiel ro1)

Verbindung testen

Nach Aufruf von ip link bzw. ip addr.. ip link sollten wir einen Eintrag für den Tunnel vorfinden:

.
.
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
       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 erreichbar ist:

ping ff02::1%[GRE-Tunnel-Name]