L2TP und Tunneldigger: Unterschied zwischen den Versionen

Aus Freifunk Franken
Wechseln zu:Navigation, Suche
KKeine Bearbeitungszusammenfassung
 
(5 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 1: Zeile 1:
'''Veraltet!'''
'''Die neuere Node-Firmware > 20181202 unterstützt keinen Tunneldigger mehr!'''


__TOC__
__TOC__


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


Vorteile: *Weniger CPU Last auf den Gateway Servern und den Routern
Vorteile:  
 
Weniger CPU Last auf den Gateway Servern und den Routern.
Mehr Durchsatz durch die Tunnel.


Nachteile:
Auf kleinen Gateways (Vserver, 1 Kern) kommt es bei vielen Tunnel >100 zu Problemen. Die CPU Last steigt überproportional zur Tunnelzahl. Besonders ein Anstieg von si - software interrupts ist zu beobachten und es kommt zur Kernelpanic.




Zeile 18: Zeile 29:


=Am Gateway (KeyXchangev2!!)=
=Am Gateway (KeyXchangev2!!)=
'''Für alte Hoods nur mit älterem Kernel! '''


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.
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.
Zeile 45: Zeile 54:
  modprobe l2tp_netlink
  modprobe l2tp_netlink


===Installation:===
==Installation:==


mkdir /srv/tunneldigger
Eine Installationsanleitung findet man hier:
cd /srv/tunneldigger
virtualenv env_tunneldigger
git clone https://github.com/wlanslovenija/tunneldigger.git


'''Für alte Hoods einige Commits zurück'''
  https://tunneldigger.readthedocs.io/en/latest/server.html
  cd tunneldigger
git checkout eee2770174ff
cd ..
'''sonst hier weiter'''


'''Problem hohe CPU Last durch mtu-discovery'''


Die mtu-discovery verursacht bei mehreren Tunnel hohe CPU Last. Ihr habt folgende Möglichkeiten:
Es gibt auch eine angepasste Version des Brokers für die fff-Gateways.
* Das Gateway hat genug Power und es stört nicht. -> nichts machen.
* Den Timer erhöhen, so dass seltener geprobed wird ->
in /srv/tunneldigger/tunneldigger/broker/src/tunneldigger_broker/tunnel.py ca. Zeile 220 hinten den Timer erhöhen
self.create_timer(self.pmtu_discovery, timeout=random.randrange(500, 700))
* Diese Rekursion ganz aus schalten, dann wird nur noch einmal beim Tunnelaufbau geprobed ->
in /srv/tunneldigger/tunneldigger/broker/src/tunneldigger_broker/tunnel.py ca. Zeile 220 diese Zeile auskommentieren.
#  self.create_timer(self.pmtu_discovery, timeout=random.randrange(500, 700))
* In der entstehenden Konfigurationsdatei gibt es die Möglichkeit das ganz aus zu schalten. -> Nicht empfohlen!


Die folgenden Zeilen müsst ihr auch wiederholen, wenn ihr später obige Änderungen macht!
'''Hierfür die Anleitung:'''


mkdir /srv/tunneldigger
cd /srv/tunneldigger
virtualenv env_tunneldigger
git clone  https://github.com/rohammer/tunneldigger.git
  source env_tunneldigger/bin/activate  
  source env_tunneldigger/bin/activate  
  cd  /srv/tunneldigger/tunneldigger/broker  
  cd  /srv/tunneldigger/tunneldigger/broker  
  python setup.py install
  python setup.py install


===Konfiguration:===


==Konfiguration:==


Um die Konfiguration zu erleichtern gibt es ein Skript:
Im Brokerverzeichnis findet ihr eine Beispielkonfigdatei: l2tp_broker.cfg.example. Wir brauchen für jede Hood eine Konfigdatei.


http://fff-sw.freifunk-schweinfurt.de/mk-fff-broker-conf.sh
Diese Datei kopieren wir für jede Hood einmal nach /etc/tunneldigger/


Öffnen, Daten eintragen, laufen lassen, fertig.  
mkdir /etc/tunneldigger
cp /srv/tunneldigger/tunneldigger/broker/l2tp_broker.cfg.example /etc/tunneldigger/hood.cfg


'''Anmerkung: Der hoodname darf maximal 8 Zeichen lang sein!!'''
In die Konfigdatei die Parameter der Hood eintragen. Die Datei ist selbsterklärend.


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


===Den Routern mitteilen, dass wir l2tp anbieten===
Wir legen für jede Hood eine systemd unit Datei an:


'''Erst aktivieren, wenn für alle Hoods des Gateways die Konfiguration gemacht wurde!!'''
Z.B. /etc/systemd/system/td-broker-hood.service


Im DocumentRoot des Webservers die Datei vpn.txt mit Inhalt l2tp anlegen
[Unit]
Description=tunneldigger tunnelling network daemon using l2tpv3
After=network.target auditd.service
[Service]
Type=simple
WorkingDirectory=/srv/tunneldigger/tunneldigger
ExecStart=/srv/tunneldigger/env_tunneldigger/bin/python -m tunneldigger_broker.main /etc/tunneldigger/hood.cfg
KillMode=process
Restart=on-failure
[Install]
WantedBy=multi-user.target


echo l2tp > vpn.txt
==Unit aktivieren==


Danach verbinden sich die Router mit obiger Firmware via l2tp.
systemctl enable td-broker-hood.service


==Broker starten==


===Kontrolle===
systemctl start td-broker-hood.service


- über ''systemctl status tunneldigger-broker-xxx.service'' kann man den Status erfragen.
Der Broker startet beim nächsen Booten automatisch.


- mit ''ip link'' sieht man für jeden Router ein l2tpXXXX Device mit der entsprechenden Bridge als master.
==Den Routern mitteilen, dass wir l2tp anbieten==


- mit ''ip l2tp show tunnel'' sieht man die einzelnen Tunnel
'''Erst aktivieren, wenn für alle Hoods des Gateways die Konfiguration gemacht wurde!!'''


- mit ''ip l2tp show session'' die entsprechenden Devices
Im DocumentRoot des Webservers die Datei vpn.txt mit Inhalt l2tp anlegen


- der Broker sollte auch die entsprechenden SNAT und DNAT Einträge gemacht haben: ''iptables -L -t nat''
  echo l2tp > vpn.txt


- das Log mit journalctl -u tunneldigger-broker-HOOD.service
Danach verbinden sich die Router via l2tp.


===Spezialfall alte Hood - neuer Kernel===
==Kontrolle==


Bei neueren Kernels ist der Bug, dass nicht auf unique Tunnel ID geprüft wird, beseitigt. Die alten tunneldigger in den "alten" Hoods funktionieren aber nicht ohne diesen Bug auf dem Gateway.
- über ''systemctl status td-broker-xxx.service'' kann man den Status erfragen.
Man hat nun die Möglichkeit den Bug wieder einzubauen.  


So in etwa sollte das funktionieren: http://fff-sw.freifunk-schweinfurt.de/l2tp-uniq-id-bug
- mit ''ip link'' sieht man für jeden Router ein l2tpXXXX Device mit der entsprechenden Bridge als master.


===Konfiguration von Hand===
- mit ''ip l2tp show tunnel'' sieht man die einzelnen Tunnel


* Dokumentation: http://tunneldigger.readthedocs.io/en/latest/index.html
- mit ''ip l2tp show session'' die entsprechenden Devices
* Besonderheiten für Freifunk Franken
** Der Port ergibt sich aus fastd-port + 10000
** Wir passen die HookSkripte an (Beispiel Hood swv2)


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


''session.up=/srv/tunneldigger/tunneldigger/broker/scripts/swv2.up''
- das Log mit journalctl -u td-broker-HOOD.service
 
#!/bin/bash
TUNNEL_ID="$1"
INTERFACE="$3"
MTU="$4"
BATDEV=bat0
. /srv/tunneldigger/tunneldigger/broker/scripts/swv2-bridge_functions
# Set the interface to UP state
ip link set dev $INTERFACE up mtu $MTU
# Add the interface to our bridge
ensure_bridge br-swv2${MTU}
brctl addif br-swv2${MTU} $INTERFACE
 


''session.pre-down=/srv/tunneldigger/tunneldigger/broker/scripts/swv2.down''


#!/bin/bash
TUNNEL_ID="$1"
INTERFACE="$3"
MTU="$4"
ROUTER="$8"
# Remove the interface from our bridge
brctl delif br-swv2${MTU} $INTERFACE
''session.mtu-changed=/srv/tunneldigger/tunneldigger/broker/scripts/swv2-mtu_changed.sh''
#!/bin/bash
TUNNEL_ID="$1"
INTERFACE="$3"
OLD_MTU="$4"
NEW_MTU="$5"
BATDEV=bat0
MTU="$NEW_MTU"
. /srv/tunneldigger/tunneldigger/broker/scripts/swv2-bridge_functions
# Remove interface from old bridge
brctl delif br-swv2${OLD_MTU} $INTERFACE
# Change interface MTU
ip link set dev $INTERFACE mtu $NEW_MTU
# Add interface to new bridge
ensure_bridge br-swv2${NEW_MTU}
brctl addif br-swv2${NEW_MTU} $INTERFACE
''/srv/tunneldigger/tunneldigger/broker/scripts/swv2-bridge_functions''
ensure_policy()
{
  ip rule del $*
  ip rule add $*
}
ensure_bridge()
{
#MAC aus MTU generieren (auf jedem GW eine Stelle ändern)
  mac=$(echo $MTU |  sed -E "s/^(..)/0a:66:01:01:\1:/")
  local brname="$1"
  brctl addbr $brname 2>/dev/null
  if [[ "$?" == "0" ]]; then
    # Bridge did not exist before, we have to initialize it
    ip link set dev $brname address $mac
    ip link set dev $brname up
    # Neue Bridge batman hinzufügen
    batctl -m $BATDEV if add $brname
    # Disable forwarding between bridge ports
    ebtables -A FORWARD --logical-in $brname -j DROP
  fi
}


==Broker für eine Hood wieder los werden==
==Broker für eine Hood wieder los werden==
Zeile 212: Zeile 147:


Service stoppen:  (Tipp: Tab-Taste)
Service stoppen:  (Tipp: Tab-Taste)
  systemctl stop tunneldigger-broker-hawaii.service  
  systemctl stop td-broker-hawaii.service  


Service ausschalten:
Service ausschalten:
  systemctl disable tunneldigger-broker-hawaii.service  
  systemctl disable td-broker-hawaii.service  


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


Unit löschen:
Unit löschen:
  rm /etc/systemd/system/tunneldigger-broker-hawaii.service
  rm /etc/systemd/system/td-broker-hawaii.service


systemd davon in Kenntnis setzen:
systemd davon in Kenntnis setzen:
Zeile 226: Zeile 161:


Konfigdateien löschen:
Konfigdateien löschen:
  find /srv/tunneldigger/tunneldigger -name '*hawaii.*' -exec rm \{\} \;
  rm /etc/hawaii.cfg

Aktuelle Version vom 27. Oktober 2019, 11:15 Uhr

Veraltet!

Die neuere Node-Firmware > 20181202 unterstützt keinen Tunneldigger mehr!


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. Mehr Durchsatz durch die Tunnel.

Nachteile:

Auf kleinen Gateways (Vserver, 1 Kern) kommt es bei vielen Tunnel >100 zu Problemen. Die CPU Last steigt überproportional zur Tunnelzahl. Besonders ein Anstieg von si - software interrupts ist zu beobachten und es kommt zur Kernelpanic.


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 (KeyXchangev2!!)

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-get install iproute bridge-utils libnetfilter-conntrack-dev libnfnetlink-dev libffi-dev python-dev libevent-dev ebtables python-virtualenv
apache2


Module

In /etc/modules die Module eintragen: 

l2tp_core
l2tp_eth
l2tp_netlink

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

Installation:

Eine Installationsanleitung findet man hier: 

https://tunneldigger.readthedocs.io/en/latest/server.html


Es gibt auch eine angepasste Version des Brokers für die fff-Gateways.

Hierfür die Anleitung: 

mkdir /srv/tunneldigger
cd /srv/tunneldigger 
virtualenv env_tunneldigger 
git clone  https://github.com/rohammer/tunneldigger.git
source env_tunneldigger/bin/activate 
cd  /srv/tunneldigger/tunneldigger/broker 
python setup.py install


Konfiguration:

Im Brokerverzeichnis findet ihr eine Beispielkonfigdatei: l2tp_broker.cfg.example. Wir brauchen für jede Hood eine Konfigdatei.

Diese Datei kopieren wir für jede Hood einmal nach /etc/tunneldigger/ 

mkdir /etc/tunneldigger
cp /srv/tunneldigger/tunneldigger/broker/l2tp_broker.cfg.example /etc/tunneldigger/hood.cfg

In die Konfigdatei die Parameter der Hood eintragen. Die Datei ist selbsterklärend.

Start einrichten

Wir legen für jede Hood eine systemd unit Datei an:

Z.B. /etc/systemd/system/td-broker-hood.service 

[Unit]
Description=tunneldigger tunnelling network daemon using l2tpv3
After=network.target auditd.service

[Service]
Type=simple
WorkingDirectory=/srv/tunneldigger/tunneldigger
ExecStart=/srv/tunneldigger/env_tunneldigger/bin/python -m tunneldigger_broker.main /etc/tunneldigger/hood.cfg

KillMode=process
Restart=on-failure

[Install]
WantedBy=multi-user.target

Unit aktivieren

systemctl enable td-broker-hood.service

Broker starten

systemctl start td-broker-hood.service

Der Broker startet beim nächsen Booten automatisch.

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 via l2tp.

Kontrolle

- über systemctl status td-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 mit journalctl -u td-broker-HOOD.service


Broker für eine Hood wieder los werden

Beispielhood: hawaii

Service stoppen: (Tipp: Tab-Taste) 

systemctl stop td-broker-hawaii.service

Service ausschalten: 

systemctl disable td-broker-hawaii.service

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

Unit löschen: 

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

systemd davon in Kenntnis setzen: 

systemctl daemon-reload

Konfigdateien löschen: 

rm /etc/hawaii.cfg
Abgerufen von „https://wiki.freifunk-franken.de/mediawiki/index.php?title=L2TP_und_Tunneldigger&oldid=16500“
Creative Commons „Namensnennung, Weitergabe unter gleichen Bedingungen“
Powered by MediaWiki