L2TP/Tunneldigger Serverdoku-Thread


#1

Hi,

Hier wird Regelmäßig die neuste Doku für die L2TP/Tunneldigger Server Installation gepostet.
Diese ist außerdem in Git zu finden via: https://github.com/ffrl/ffrl-tunneldigger-docs/blob/master/quickstart.rst

Bitte sendet Änderungsvorschläge und Korrekturen via Github Pull-Request :slight_smile:

Server Installation

In den folgenden Schritten wird die Installation von Tunneldigger für Gluon beschrieben.
Dieses Beispiel nutzt Debian Jessie, für andere Distributionen müssen die Befehle angepasst werden.

Source Code

Die Tunneldigger-Sources können mit dem folgenden Befehl heruntergeladen werden::

git clone git://github.com/ffrl/tunneldigger.git

Dies erstellt einen Ordner mit dem Namen tunneldigger. In diesem befindet sich der Client und Broker Sourcecode.
Dieser Scritt ist nicht teil der Installation und dient nur der Vollständigkeit dieser Dokumentation.

Abhängigkeiten

Tunneldigger benötigt einen aktuellen Linux Kernel (>= 2.6.36) welcher L2TPv3 unterstützt.
Für den Broker-Dienst müssen die folgenden Kernel-Module geladen sein:

  • l2tp_core
  • l2tp_eth
  • l2tp_netlink
  • ebtables

Zusätzlich muss der Kernel NAT via Netfilter unterstützen, ansonsten kann Tunneldigger nicht alle Tunnel über den selben externen Port laufen lassen. Dies ist normalerweise immer der Fall.
Diese Modules sollten beim booten geladen werden indem diese in /etc/modules hinterlegt werden.

Zu den Kernel Modulen werden auch noch Software Pakete benötigt. Auf Debian sind es die folgenden::

  • iproute
  • bridge-utils
  • libnetfilter-conntrack3
  • python-dev
  • libevent-dev
  • ebtables
  • python-virtualenv

Tunneldigger wird in einem so genanten “Python Virtual Environment” betrieben, dadurch können die Python-Pakete für Tunneldigger
seperat von den Betriebssystem Python Paketen installiert werden. Dadurch soll vermieden werden das diese Pakete sich gegenseitig stören.

Um die oben aufgeführten Pakete zu installieren kann der folgende Befehl ausgeführt werden::

sudo apt-get install iproute bridge-utils libnetfilter-conntrack3 python-dev libevent-dev ebtables python-virtualenv 

Installation

Diese Anleitung installiert den Broker unter /srv/tunneldigger
Die installation geschieht mittels:

mkdir /srv
cd /srv
git clone git://github.com/ffrl/tunneldigger.git
virtualenv tunneldigger

Als nächster Schritt werden die Abhängigkeiten für den Broker installiert.
Dafür aktivieren wir die virtuelle Python-Umgebung und installieren die Pakete aus
der Datei requirements.txt

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

Konfiguration

Der Broker benötigt eine Konfigurations-Datei als Commandline-Option, ein Beispiel befindet sich in broker/l2tp_broker.cfg.example. Diese Datei kopieren wir nach /srv/tunneldigger/l2tp_broker.cfg und passen diese an.
Ein paar Optionen müssen angepasst werden, der Rest kann in der Regel so belassen werden.

  • address hier muss die externe IP-Adresse des Brokers eingetragen werden auf welche die Clients verbinden.

  • port hier werden die Ports eingetragen auf welchen der Broker erreichbar ist, es können mehrere Ports eingetragen werden (Mit Komma getrennt)

  • interface der Name des Interfaces auf dem Broker über welches die Clients verbinden.

  • pmtu-discovery muss auf “false” gesetzt werden da Batman-Advanced keine dynamische MTU-Änderung unterstützt.

  • Die Hooks im Abschnitt hooks müssen mit den Pfaden der Interface-Scripts konfiguriert werden. Wenn dies nicht der Fall ist dann werden Verbindungen nur aufgebaut aber die Interfaces nicht konfiguriert.

Hooks

Momentan existieren vier verschiedene hooks

  • session.up wird aufgerufen nachdem das Interface vom Broker erstellt wurde und bereit für die weitere Konfiguration ist. (Hier muss /srv/tunneldigger/scripts/session-up.sh eingetragen werden)

  • session.pre-down wird kurz vor dem entfernen des Interfaces durch den Broker aufgerufen. (Hier muss /srv/tunneldigger/scripts/session-pre-down.sh eingetragen werden)

  • session.down wird aufgerufen nachdem das Interface entfernt wurde und nicht mehr nutzbar ist. (Dies wird momentan nicht genutzt)

  • session.mtu-changed wird bei MTU-Änderungen aufgerufen (Dieser Hook kann momentan nicht genutzt werden da die Clients wegen Batman-Advanced keine dynamischen MTU-Änderungen unterstützen.)

Hook-Scripts

Die folgenden Hook-Scripts müssen unter /srv/tunneldigger/scripts abgelegt werden.

Script: /srv/tunneldigger/scripts/session-up.sh

#!/bin/bash
INTERFACE="$3"
UUID="$8"

log_message() {
    message="$1"
    logger -p 6 -t "Tunneldigger" "$message"
    echo "$message" | systemd-cat -p info -t "Tunneldigger"
    echo "$1" 1>&2
}

if /bin/grep -Fq $UUID /srv/tunneldigger/blacklist.txt; then
        log_message "New client with UUID=$UUID is blacklisted, not adding to tunneldigger bridge interface"
else
        log_message "New client with UUID=$UUID connected, adding to tunneldigger bridge interface"
        ip link set dev $INTERFACE up mtu 1364
        /sbin/brctl addif tunneldigger $INTERFACE
fi

Script: /srv/tunneldigger/scripts/session-pre-down.sh

#!/bin/bash
INTERFACE="$3"

/sbin/brctl delif tunneldigger $INTERFACE
exit 0

Nicht vergessen die Scripts mittels chmod +x ausführbar zu machen!

Client-Blacklist

Wie bei Fastd können Clients ausgesperrt werden, dafür wird die Datei /srv/tunneldigger/blacklist.txt genutzt.
Hier können die NodeIDs der zu sperrenden Clients eingetragen werden, jeweils in einer Zeile.

Betriebssystem-Konfiguration

Nach der Konfiguration von Tunneldigger müssen noch ein paar Dinge im Betriebssystem angelegt werden, ein Start-Script, eine System-Unit sowie die Bridge Konfiguration.

Start-Script und Systemd Unit

Script: /srv/tunneldigger/start-broker.sh

#!/bin/bash

WDIR=/srv/tunneldigger
VIRTUALENV_DIR=/srv/tunneldigger

cd $WDIR
source $VIRTUALENV_DIR/bin/activate

bin/python broker/l2tp_broker.py l2tp_broker.cfg

Script: /etc/systemd/system/tunneldigger.service

[Unit]
Description = Start tunneldigger L2TPv3 broker
After = network.target

[Service]
ExecStart = /srv/tunneldigger/start-broker.sh

[Install]
WantedBy = multi-user.target

Anschließend aktivieren wir den Tunneldigger Dienst damit dieser beim booten startet::

systemctl enable tunneldigger.service

Tunneldigger-Bridge

Anschließend wird die Tunneldigger Bridge konfiguriert. Alle Tunnel werden in einer Bridge zusammengefasst da Batman-Advanced nicht mit vielen Interfaces umgehen kann.
Damit dies nicht zu Problemen mit Batman führt, müssen die Clients untereinander isoliert werden denn die Kommunikation zwischen den Clients übernimmt Batman-Advanced.
Dazu legen wir die folegende Datei an:

Datei: /etc/network/interfaces.d/tunneldigger

# Tunneldigger VPN Interface
auto tunneldigger
iface tunneldigger inet manual
  ## Bring up interface
  pre-up brctl addbr $IFACE
  pre-up ip link set address 0A:BE:EF:25:00:01 dev $IFACE
  pre-up ip link set dev $IFACE mtu 1364
  pre-up ip link set $IFACE promisc on
  up ip link set dev $IFACE up
  post-up ebtables -A FORWARD --logical-in $IFACE -j DROP
  post-up batctl if add $IFACE
  # Shutdown interface
  pre-down batctl if del $IFACE
  pre-down ebtables -D FORWARD --logical-in $IFACE -j DROP
  down ip link set dev $IFACE down
  post-down brctl delbr $IFACE

Hierbei muss die Interface MTU nach eigenen Wünschen angepasst werden, wir nutzen hier 1364 was in Tests die besten Ergebnisse lieferte.
Außerdem sollte eine eindeutige MAC Adresse für jeden Broker gewählt werden.

Zum Abschluss starten wir das Tunneldigger-Bridge Interface sowie den Broker

ifup tunneldigger
systemctl start tunneldigger

[ffdus] l2tp Testbetrieb
Site.conf mit aktuellster Technik für neue Domain
Tunneldigger - Tunnel bleiben nicht aktiv
[ffdus] Firmware für D-Link DIR860l und L2TP bugfix
#2

Ich vermute mal, das Netzwork-Setup auf Ubuntu (16.04) ist etwas abweichend.
“Socket error 113 (No route to host) in tunnel xxx!”

Logs (Plasterouter ist mein eigener und die Dialup-IP habe ich bewusst drinnen gelassen.)

Thu, 07 Apr 2016 11:55:19 INFO     New tunnel (id=420 uuid=e894f6298ece) created.
Thu, 07 Apr 2016 11:55:19 DEBUG    Executing hook 'session.up' via script '/srv/tunneldigger/scripts/session-up.sh ['420', '1', 'l2tp4201', '1446', '176.198.221.162', '47401', '20420', 'e894f6298ece']'.
Thu, 07 Apr 2016 11:55:19 ERROR    Socket error 113 (No route to host) in tunnel 420!
Thu, 07 Apr 2016 11:55:19 DEBUG    Hook '/srv/tunneldigger/scripts/session-up.sh' script stderr:
Thu, 07 Apr 2016 11:55:19 WARNING  New client with UUID=e894f6298ece connected, adding to tunneldigger bridge interface
Thu, 07 Apr 2016 11:56:19 WARNING  Session with tunnel 420 timed out.
Thu, 07 Apr 2016 11:56:19 INFO     Closing tunnel 420.

Ich war jetzt nicht fix genug, diesen tunnel noch anzuzeigen, aber für’s komplette Bild.

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: ens18: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 02:00:00:48:82:d1 brd ff:ff:ff:ff:ff:ff
    inet 164.132.62.122/24 brd 164.132.62.255 scope global ens18
       valid_lft forever preferred_lft forever
    inet6 2001:41d0:1:b5d5::12/64 scope global
       valid_lft forever preferred_lft forever
    inet6 fe80::ff:fe48:82d1/64 scope link
       valid_lft forever preferred_lft forever
3: ens19: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 36:65:38:66:39:37 brd ff:ff:ff:ff:ff:ff
4: ens20: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master bat0 state UP group default qlen 1000
    link/ether 36:63:34:31:62:39 brd ff:ff:ff:ff:ff:ff
    inet 192.168.5.12/24 brd 192.168.5.255 scope global ens20
       valid_lft forever preferred_lft forever
    inet6 fe80::3463:34ff:fe31:6239/64 scope link
       valid_lft forever preferred_lft forever
5: bat0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 7a:19:cd:de:df:45 brd ff:ff:ff:ff:ff:ff
6: tunneldigger: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1364 qdisc noqueue master bat0 state UP group default qlen 1000
    link/ether ca:b1:e9:ca:b1:e0 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::c8b1:e9ff:feca:b1e0/64 scope link
       valid_lft forever preferred_lft forever
330: l2tp4221: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1364 qdisc pfifo_fast master tunneldigger state UNKNOWN group default qlen 1000
    link/ether 12:ae:78:9b:e3:50 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::10ae:78ff:fe9b:e350/64 scope link
       valid_lft forever preferred_lft forever

und:

batctl if
tunneldigger: active
ens20: active

plus

brctl show
bridge name     bridge id               STP enabled     interfaces
tunneldigger            8000.cab1e9cab1e0       no              l2tp4241

Any clues?


#3

Hmm hast du evtl. die falsche Interface IP eingetragen oder das falsche Interface? :slight_smile: No route to host klingt danach das der Tunnel auf dem falschen Interface angelegt wird.

Edit: Eine Übersicht der Config wäre auch super :slight_smile:


#4

Fehler gefunden, falsches interface in der tunneldigger.config.
ens28 stand da, nicht ens18. Ich könnte jetzt behaupten, ich hätte das nie selbst getippt…
(rubberduck-debugging hätte geholfen meinerseits…)
Danke für Hinführen.


#5

Am besten stellst du noch die Mac Adresse für die Tunneldigger Bridge fest ein und trägst die als VPN link in der Map ein, dann wird es auch normal wie mit Fastd angezeigt :smile:


#6

Die ist schon fix. (Du meinst doch die cab1e9cab1e0 (Kabel9-Kabel0)
Aber aliases-json muss noch für die Map, in der Tat.


#7

Ja genau und auch in die aliases-json wie du schon richtig geschrieben hast.


#8

Moin,

sorry das ich diesen alten Faden wiederbelebe, aber das passt nunmal hierzu:

Ich versuche gerade ein Gateway für L2TP aufzuseten. Die L2TP Verbindung zum Gateway scheint zu laufen. Wenn ich meinen Test-Router einschaltet, dann meldet das Gateway

Tunneldigger: New client with UUID=98ded091ec3c connected, adding to tunneldigger bridge interface
Tunneldigger[1282]: New client with UUID=98ded091ec3c connected, adding to tunneldigger bridge interface

Soweit so gut. Wie gehe ich jetzt weiter vor? Gibt es weitergehnde Doku dazu? Das Fastd-Gateway habe ich nach dieser Anleitung aufgesetzt: https://wiki.freifunk.net/Freifunk_Nordlippe_Gateway das funktioniert auch soweit.

Das interface “ffnl-mesh” gibt es dann nicht mehr, dafür dann das Interface “tunneldigger” Verstehe ich das so korrekt?

root@v22017011140543301:~# batctl if
tunneldigger: active

Leider scheint die Kommunikation mit Batman nicht zu laufen:

root@v22017011140543301:~# batctl o
[B.A.T.M.A.N. adv 2014.3.0, MainIF/MAC: tunneldigger/0a:be:ef:25:00:01 (bat0 BATMAN_IV)]
Originator      last-seen (#/255)           Nexthop [outgoingIF]:   Potential nexthops ...
No batman nodes in range ...

Habt ihr eine Idee oder einem Link zu einer (vollständigeren) Anleitung?

Grüße


#9

Posted bitte mal den output auf Deinem supernode von

  batctl if

und

  brctl show

Vermutlich fehlt irgendwas a la

 batctl add if tunneldigger

(oder war es “if add”?) in dem batup-script des fastd. (warum hast Du kein bat0 oder ähnliches im Batman? Wo geht es denn weiter bei Dir?)


#10
root@v22017011140543301:~# batctl if
tunneldigger: active

root@v22017011140543301:~# brctl show
bridge name     bridge id               STP enabled     interfaces
br-ffnl         8000.c2ab15e286df       no              bat0
tunneldigger            8000.0abeef250001       no

Das “tunneldigger”-Interface muss wohl auf auf bat0 zeigen oder?
Das “br-ffnl” ist dann wohl ein überbeilbsel von der FastD Konfiguration?

Probiere ich gleich nach dem Mittagessen mal aus.

Grüße und Danke


#11

Das ist bei meiner Installation der Stand:

Dort geht halt bisher nur ipv4

l2tpgw-doku.pdf (84,9 KB)


#12

Wer ist das? Ist das der Plasterouter oder Dein Server?

Poste doch mal das batctl if und brctl show “vom anderen” bitte.


#13

Moin,

das ist der Server:

root@v22017011140543301:~# batctl if
tunneldigger: active
root@v22017011140543301:~# brctl show
bridge name    bridge id        STP enabled    interfaces
tunneldigger        8000.0abeef250001    no        l2tp1061

Und das ist mein Test-Plaste-Router:

root@ffein98ded091ec3c:~# batctl if
ibss0: active 
mesh-vpn: active
primary0: active
root@ffein98ded091ec3c:~# brctl show
bridge name    bridge id        STP enabled    interfaces
br-client        7fff.98ded091ec3c    no        eth0
                             client0
                             bat0
br-wan        7fff.dad1fba113d8    no        eth1

#14

Hmm. Ich kann wirklich nur jedem raten, sich auf gepflegte geskriptete Installationen zu stützen, sei es https://github.com/ffnord/ffnord-puppet-gateway (Puppet) oder https://github.com/FreiFunkMuenster/Ansible-Freifunk-Gateway (Ansible) oder … Anders als beim cut&waste aus Webseiten kann man da nichts vergessen, und der Vorgang wird bei gleicher Eingabe das gleiche Ergebnis (oder einen Fehler) erzeugen. Ob man Salt, Ansible, Puppet, … nimmt, ist am Ende des Tages egal, wichtig ist, daß man bei einem Tool bleibt und dies konsequent für seine Server einsetzt. Denn nach dem 1. folgt das 2. Gateway (und damit ggf. die Notwendigkeit zur Vernetzung jenseits des Meshs), ab dem 37., voll vermaschten, Gateway möchte man die Ebenen (Mesh/Routing) vielleicht doch trennen, …


#15

Moin da oben auf eine alte Version bezogen wird hier mal wie man die neuste version der ursprünglichen ersteller nutzt.Das ganze habe ich allerdings nur trocken und nicht im Wirkbetrieb getestet also ist das ganze experimentell!
Zudem handelt dies nur vom installieren und nicht Server einrichten oder routing sowie config, dadieses gleich bleibt

Zuerst mal die nötigen Pakete intallieren, dazu unter debian den folgenden command nehmen:

sudo apt-get install iproute bridge-utils libnetfilter-conntrack3 python-dev libevent-dev ebtables python-virtualenv libffi-dev libnfnetlink-dev libnetfilter-conntrack-dev

Anschließend erstellt ihr die nötigen Ordner, klont die source und erstellt das Virtual ENV für python. Dazu diese commands nehmen (Ps ab jetzt in der selben shell bleiben):

# Tunneldigger Ordner erstellen
mkdir -p /srv/tunneldigger
cd /srv/tunneldigger

# Python virtualenv erstellen
virtualenv env_tunneldigger
 
#tunneldigger clonen
cd /srv/tunneldigger
git clone https://github.com/wlanslovenija/tunneldigger.git

#virtual env aktivieren
source env_tunneldigger/bin/activate

Als nächstes installieren wir Tunneldigger. Dieser Teil ist anders als in der offiziellen Doku.

# In den richtigen ordner bewegen
cd /srv/tunneldigger/tunneldigger/broker
 
# Installiere tunneldigger in das virtuelle ENV
python setup.py install --prefix=/srv/tunneldigger/env_tunneldigger/

Nun noch eine Änderung in der start-broker.sh. Die legen wir wie oben schon genannt in /srv/tunneldigger/start-broker.sh an und die sieht so aus:

#!/bin/bash

WDIR=/srv/tunneldigger
VIRTUALENV_DIR=/srv/tunneldigger/env_tunneldigger

cd $WDIR
source $VIRTUALENV_DIR/bin/activate

$VIRTUALENV_DIR/bin/python -m tunneldigger_broker.main  l2tp_broker.cfg

Ich hoffe ich habe keine Pfade zu dollProblematisiert und bei Fragen anpingen :slight_smile: PS das ganze habe ich unter debian9 getestet


#16

Da ich gerade den Kontext nicht habe: Die “offizielle Doku” ist die hier oben aus dem Thread oder die der Tunneldigger-Maintainer?


#17

Beide. Sowohl die von wlanslovenija als auch diese hier sind anders. Wieso die von wlanslovenija nicht geupdated wurde ist mir jedoch unbekannt


#18

Mein großer Traum wäre ja noch immer ein Tunneldigger, der auch über IPv6 connectiert, damit man sich bei DSLite-Anschlüssen den Umwege über das CGN spart. (und ich weiss, dass es am wlanslovenija liegt.)


#19

Naja es ist bei denen ja nen GSoC projekt :slight_smile: also sollte das noch passsieren bald.


#20

Ach PS falls jemand sich wundert woher ich die Installations anweisungen habe: Ich habe in deren openwrt paketen geguckt die haben ein broker openwrt paket :slight_smile: