L2TP und Tunneldigger: Unterschied zwischen den Versionen

Aus Freifunk Franken
Wechseln zu:Navigation, Suche
Zeile 16: Zeile 16:
   
   
'''Am Router muss nichts konfiguriert werden!'''
'''Am Router muss nichts konfiguriert werden!'''
Wie man den Tunneldigger in die Firmware einbaut, findest du [[Neues_Paket_in_Firmware_aufnehmen|hier]]


=Am Gateway=
=Am Gateway=

Version vom 12. Oktober 2017, 13:03 Uhr

Seit der Firmware 20161008-beta ist der Tunneldigger für l2tp Tunnel zum Gateway mit dabei. Hier die Anleitung, wie man den Tunnelbroker auf einem Gateway installiert und konfiguriert.

Vorteile: *Weniger CPU Last auf den Gateway Servern und den Routern


Am Router

Eine Firmware ab 20161008-beta oder neuer flashen.

Es wird die Datei vpn.txt auf dem GW geprüft, wenn mit Inhalt l2tp vorhanden, dann l2tp sonst fastd.

Am Router muss nichts konfiguriert werden!

Am Gateway

So, jetzt brauchen wir noch Gateways mit dem Broker. Nebenbei braucht der Gateway auch noch ein Webserver, die Clients fragen ob ein Gateway l2tp anbietet oder nicht.

Vorbereitungen:

Nötige Pakete holen:

apt install iproute bridge-utils libnetfilter-conntrack3 conntrack python-dev  libevent-dev ebtables python-virtualenv apache2


Module

In /etc/modules die Module eintragen:

l2tp_core
l2tp_eth
l2tp_netlink
nf_conntrack_netlink
nf_conntrack
nfnetlink

Mit modprobe "name des Moduls" kann man dann alle Module laden. Beim nächsten reboot geht das dann automatisch.

modprobe l2tp_core
modprobe l2tp_eth
modprobe l2tp_netlink
modprobe nf_conntrack_netlink
modprobe nf_conntrack
modprobe nfnetlink

Installation:

Wir benutzen momentan die Version 0.1.0 des Tunneldigger mit einigen kleinen Anpassungen. Achtung! Für Debian 9 geht die tunneldigger Version nicht mehr. Darum gibt es 2 Repos. In fff-tunneldigger-debian_9 ist ein neues conntrack.py drin. Das wiederum läft auf Debian 8 nicht.

mkdir /srv/tunneldigger 
cd /srv/tunneldigger
virtualenv env_tunneldigger

Für Debian 8

git clone https://github.com/rohammer/fff-tunneldigger-debian_8.git
mv fff-tunneldigger-debian_8 tunneldigger

Für Debian 9

git clone https://github.com/rohammer/fff-tunneldigger-debian_9.git
mv fff-tunneldigger-debian_9 tunneldigger

Hier weiter

cd /srv/tunneldigger 
source env_tunneldigger/bin/activate
pip install -r tunneldigger/broker/requirements.txt

Konfiguration:

Um die Konfiguration zu erleichtern gibt es in tunneldigger/broker ein Skript:

mk-fff-broker-conf.sh

Öffnen, Daten eintragen, laufen lassen, fertig.

Anmerkung: Der hoodname darf maximal 8 Zeichen lang sein!!

Das kann man jetzt mehrfach machen mit unterschiedlichen Konfigurationen für verschiedene Hoods.

Den Routern mitteilen, dass wir l2tp anbieten

Erst aktivieren, wenn für alle Hoods des Gateways die Konfiguration gemacht wurde!!

Im DocumentRoot des Webservers die Datei vpn.txt mit Inhalt l2tp anlegen

echo l2tp > vpn.txt

Danach verbinden sich die Router mit obiger Firmware via l2tp.


Kontrolle

- über systemctl status tunneldigger-broker-xxx.service kann man den Status erfragen.

- mit ip link sieht man für jeden Router ein l2tpXXXX Device mit der entsprechenden Bridge als master.

- mit ip l2tp show tunnel sieht man die einzelnen Tunnel

- mit ip l2tp show session die entsprechenden Devices

- der Broker sollte auch die entsprechenden SNAT und DNAT Einträge gemacht haben: iptables -L -t nat

- das Log findet man in /var/log/

Broker für eine Hood wieder los werden

Beispielhood: hawaii

Service stoppen: (Tipp: Tab-Taste)

systemctl stop tunneldigger-broker-hawaii.service 

Service ausschalten:

systemctl disable tunneldigger-broker-hawaii.service 

Wenn man die ganze Konfiguration weg haben will, geht es weiter.

Unit löschen:

rm /etc/systemd/system/tunneldigger-broker-hawaii.service

systemd davon in Kenntnis setzen:

systemctl daemon-reload

Konfigdateien löschen:

find /srv/tunneldigger/tunneldigger -name '*hawaii.*' -exec rm \{\} \;

Hintergrund

Die ersten Tests haben gezeigt, dass Batman es nicht mag, wenn Interfaces kommen und gehen. Wir können also die L2-Tunnel nicht direkt an Batman hängen.

Die Slovenen schreiben:

Example hook scripts present in the scripts/ subdirectory are set up to create one bridge device per MTU and attach L2TP interfaces to these bridges. They also configure a default IP address to newly created tunnels, set up ebtables to isolate bridge ports and update the routing policy via ip rule so traffic from these interfaces is routed via the mesh routing table. Each tunnel established with the broker will create its own interface. Because we are using OLSRv1, we cannot dynamically add interfaces to it, so we group tunnel interfaces into bridges. We could put all tunnel interfaces into the same bridge, but this would actually create a performance problem. Different tunnels can have different MTU values -- but there is only one MTU value for the bridge, the minimum of all interfaces that are attached to that bridge. To avoid this problem, we create multiple bridges, one for each MTU value -- this is what the example scripts do. We also configure some ip policy rules to ensure that traffic coming in from the bridges gets routed via our mesh routing table and not the main one (see bridge_functions.sh). Traffic between bridge ports is not forwarded (this is achieved via ebtables), otherwise the routing daemons at the nodes would think that all of them are directly connected -- which would cause them to incorrectly see a very large 1-hop neighbourhood. This file also contains broker-side IP configuration for the bridge which should really be changed.

Ähnliche Probleme hatten die mit OLSR. Also haben wir mal die Config deren Vorschlägen angepasst.

Es wird für jede MTU die ankommt eine Bridge aufgemacht und da kommen dann alle Interfaces mit der gleichen MTU rein.