L2TP und Tunneldigger: Unterschied zwischen den Versionen

Aus Freifunk Franken
Wechseln zu:Navigation, Suche
KKeine Bearbeitungszusammenfassung
 
(101 dazwischenliegende Versionen von 8 Benutzern werden nicht angezeigt)
Zeile 1: Zeile 1:
{{Entwurf}}
'''Veraltet!'''
 
'''Die neuere Node-Firmware > 20181202 unterstützt keinen Tunneldigger mehr!'''
 
__TOC__
__TOC__


Dies sind sie ersten zaghaften Versuche von fastd auf L2TP zu switchen, bzw. beide parallel zu nutzen. Dies soll nur eine kurze Zusammenfassung sein, was schon gemacht wurde. Nicht dass doppelte Arbeit geleistet wird. Doku folgt bei Erfolg


Vorteile: *Weniger CPU Last auf den Gateway Servern


Nachteile: *Umstellung von GWs und Firmware
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.


'''Aktuell (19.3.): Auf allen 4 Gateways in den Hoods Hasberge und Hasberge-Süd läuft der Tunnelbroker'''
Vorteile:  


Das heisst, ihr könnt komplett auf l2tp umschalten, da alle GWs direkt erreicht werden.
Weniger CPU Last auf den Gateway Servern und den Routern.
Mehr Durchsatz durch die Tunnel.


'''To do: Wir brauchen eine Firmware zum testen mit den nötigen Patches und Konfigs''
Nachteile:


===Am Router===
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.


Wir haben noch keine fertige Firmware zum Testen. Vorerst geht auch das:


=Am Router=


Sicherstellen das am Router die Kernelmodule enthalten sind. Bei meinen wr1043 v0.5.2 war dies nicht der Fall.
Eine Firmware ab 20161008-beta oder neuer flashen.


  lsmod
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!'''


sollte u.a. folgende Ausgabe liefern:
=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.
l2tp_core              12733  4 l2tp_ip6
l2tp_eth                2672  1
l2tp_ip                4704  0
l2tp_ip6                5760  0
l2tp_netlink            6536  1 l2tp_eth
...


dann ist das Kernelmodul im Router enthalten und es kann nach Anleitung fortgefahren werden.
==Vorbereitungen:==


Folgendes am Router ausführen:
'''Nötige Pakete holen:'''


  wget -P/ langhammer-mainberg.de/fff/tunneldigger.tar
  apt-get install iproute bridge-utils libnetfilter-conntrack-dev libnfnetlink-dev libffi-dev python-dev libevent-dev ebtables python-virtualenv
  cd / && tar -xf tunneldigger.tar
  apache2


Jetzt einmal die Konfig erstellen:


l2tunnel conf
'''Module'''


und starten (macht der Router beim nächsten Reboot automatisch)
In /etc/modules die Module eintragen:


  /etc/init.d/tunneldigger start
  l2tp_core
l2tp_eth
l2tp_netlink


man steuert das ganze mit dem Kommando '''l2tunnel'''
Mit  modprobe "name des Moduls"  kann man dann alle Module laden. Beim nächsten reboot geht das dann automatisch.


Viel Spass damit!
modprobe l2tp_core
modprobe l2tp_eth
modprobe l2tp_netlink


Wenn der Router neu startet, läuft fastd und tunneldigger. Alles bleibt beim alten nur dass jetzt beide Tunnel laufen.
==Installation:==


Wie man den Tunneldigger in die Firmware einbaut, findest du [[Neues_Paket_in_Firmware_aufnehmen|hier]]
Eine Installationsanleitung findet man hier:


===Am Gateway===
https://tunneldigger.readthedocs.io/en/latest/server.html
So, jetzt brauchen wir noch Gateways mit dem Broker.
Aus der Doku auf https://tunneldigger.readthedocs.org/en/latest/server.html
haben wir mal die wichtigen Zeilen rausgezogen:


Voraussetzungen
Nötige Pakete holen:


sudo apt-get install iproute bridge-utils libnetfilter-conntrack3 python-dev  libevent-dev ebtables python-virtualenv
Es gibt auch eine angepasste Version des Brokers für die fff-Gateways.


'''Installation:'''
'''Hierfür die Anleitung:'''


  mkdir /srv/tunneldigger <br />
  mkdir /srv/tunneldigger
  cd /srv/tunneldigger <br />
  cd /srv/tunneldigger  
  virtualenv env_tunneldigger <br />
  virtualenv env_tunneldigger  
cd /srv/tunneldigger  <br />
  git clone https://github.com/rohammer/tunneldigger.git
  git clone https://github.com/wlanslovenija/tunneldigger.git <br />
  source env_tunneldigger/bin/activate  
  . env_tunneldigger/bin/activate <br />
  cd  /srv/tunneldigger/tunneldigger/broker  
  pip install -r tunneldigger/broker/requirements.txt <br />
python setup.py install


'''Konfiguration:'''


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. Schade, dann könnte man no_rebroadcast einschalten.
==Konfiguration:==


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


''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.''
Diese Datei kopieren wir für jede Hood einmal nach /etc/tunneldigger/
''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.
mkdir /etc/tunneldigger
Also haben wir mal die Config deren Vorschlägen angepasst.
cp /srv/tunneldigger/tunneldigger/broker/l2tp_broker.cfg.example /etc/tunneldigger/hood.cfg


Es wird für jede MTU die ankommt eine Bridge aufgemacht und da kommen dann alle Interfaces mit der gleichen MTU rein.
In die Konfigdatei die Parameter der Hood eintragen. Die Datei ist selbsterklärend.
'''Beispiel-config für has und has-sued Hood auf GW von Max (fff-has  78.47.36.148)'''


Die l2tp_broker-xxxxx.cfg Dateien in ''/srv/tunneldigger/tunneldigger/broker/''
==Start einrichten==


l2tp_broker-has.cfg :
Wir legen für jede Hood eine systemd unit Datei an:


[broker]
Z.B. /etc/systemd/system/td-broker-hood.service
; IP address the broker will listen and accept tunnels on
address=78.47.36.148
; Ports where the broker will listen on
port=20004
; Interface with that IP address
interface=eth0
; Maximum number of tunnels that will be allowed by the broker
max_tunnels=1024
; Tunnel port base
port_base=24000
; Tunnel id base
tunnel_id_base=4000
; Namespace (for running multiple brokers); note that you must also
; configure disjunct ports, and tunnel identifiers in order for
; namespacing to work
namespace=has
; check if all kernel module are loaded. Do not check for built-ins.
check_modules=true
[log]
; Log filename
filename=tunneldigger-broker.log
; Verbosity
verbosity=DEBUG
; Should IP addresses be logged or not
log_ip_addresses=false
[hooks]
; Arguments to the session.{up,pre-down,down} hooks are as follows:
;
;    <tunnel_id> <session_id> <interface> <mtu> <endpoint_ip> <endpoint_port>  <local_port>
;
; Arguments to the session.mtu-changed hook are as follows:
;
;    <tunnel_id> <session_id> <interface> <old_mtu> <new_mtu>
;
; Called after the tunnel interface goes up
session.up=/srv/tunneldigger/tunneldigger/broker/scripts/has.up
; Called just before the tunnel interface goes down
session.pre-down=/srv/tunneldigger/tunneldigger/broker/scripts/has.down
; Called after the tunnel interface goes down
session.down=
; Called after the tunnel MTU gets changed because of PMTU discovery
session.mtu-changed=/srv/tunneldigger/tunneldigger/broker/scripts/mtu_changed- has.sh


 
  [Unit]
l2tp_broker-hassued.cfg :
  Description=tunneldigger tunnelling network daemon using l2tpv3
  [broker]
  After=network.target auditd.service
  ; IP address the broker will listen and accept tunnels on
address=78.47.36.148
; Ports where the broker will listen on
port=20005
; Interface with that IP address
interface=eth0
; Maximum number of tunnels that will be allowed by the broker
max_tunnels=1024
; Tunnel port base
port_base=21000
; Tunnel id base
tunnel_id_base=1000
; Namespace (for running multiple brokers); note that you must also
; configure disjunct ports, and tunnel identifiers in order for
  ; namespacing to work
namespace=hassued
; check if all kernel module are loaded. Do not check for built-ins.
check_modules=true
   
   
  [log]
  [Service]
  ; Log filename
  Type=simple
  filename=tunneldigger-broker.log
  WorkingDirectory=/srv/tunneldigger/tunneldigger
  ; Verbosity
  ExecStart=/srv/tunneldigger/env_tunneldigger/bin/python -m tunneldigger_broker.main /etc/tunneldigger/hood.cfg
verbosity=DEBUG
; Should IP addresses be logged or not
log_ip_addresses=false 
   
   
KillMode=process
Restart=on-failure
   
   
  [hooks]
  [Install]
  ; Arguments to the session.{up,pre-down,down} hooks are as follows:
  WantedBy=multi-user.target
;
;    <tunnel_id> <session_id> <interface> <mtu> <endpoint_ip> <endpoint_port>  <local_port>
;
; Arguments to the session.mtu-changed hook are as follows:
;
;    <tunnel_id> <session_id> <interface> <old_mtu> <new_mtu>
;
; Called after the tunnel interface goes up
session.up=/srv/tunneldigger/tunneldigger/broker/scripts/has-sued.up
; Called just before the tunnel interface goes down
session.pre-down=/srv/tunneldigger/tunneldigger/broker/scripts/has-sued.down
; Called after the tunnel interface goes down
session.down=
; Called after the tunnel MTU gets changed because of PMTU discovery
session.mtu-changed=/srv/tunneldigger/tunneldigger/broker/scripts/mtu_changed- has-sued.sh
 


Skripte in ''scripts/''
==Unit aktivieren==


bridge_functions.sh:
  systemctl enable td-broker-hood.service
  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:00:03:01:\1:/")
  local brname="$1"
  brctl addbr $brname 2>/dev/null
  if <nowiki>[[ "$?" == "0" ]]</nowiki>; then
    # Bridge did not exist before, we have to initialize it
    ip link set dev $brname address $mac 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 starten==


has.up:
systemctl start td-broker-hood.service


#!/bin/bash
Der Broker startet beim nächsen Booten automatisch.
TUNNEL_ID="$1"
INTERFACE="$3"
MTU="$4"
BATDEV=bat4
. scripts/bridge_functions.sh
# Set the interface to UP state
ip link set dev $INTERFACE up mtu $MTU
# Add the interface to our bridge
ensure_bridge l2-br-has${MTU}
brctl addif l2-br-has${MTU} $INTERFACE
 
has-sued.up:


#!/bin/bash
==Den Routern mitteilen, dass wir l2tp anbieten==
TUNNEL_ID="$1"
INTERFACE="$3"
MTU="$4"
BATDEV=bat7
. scripts/bridge_functions.sh
# Set the interface to UP state
ip link set dev $INTERFACE up mtu $MTU
# Add the interface to our bridge
ensure_bridge l2-br-sued${MTU}
brctl addif l2-br-sued${MTU} $INTERFACE
 
 
mtu_changed-has.sh
 
#!/bin/bash
TUNNEL_ID="$1"
INTERFACE="$3"
OLD_MTU="$4"
NEW_MTU="$5"
BATDEV=bat4
MTU=$NEW_MTU
. scripts/bridge_functions.sh
# Remove interface from old bridge
brctl delif l2-br-has${OLD_MTU} $INTERFACE
# Change interface MTU
ip link set dev $INTERFACE mtu $NEW_MTU
# Add interface to new bridge
ensure_bridge l2-br-has${NEW_MTU}
brctl addif l2-br-has${NEW_MTU} $INTERFACE


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


mtu_changed-has-sued.sh
Im DocumentRoot des Webservers die Datei vpn.txt mit Inhalt l2tp anlegen


  #!/bin/bash
  echo l2tp > vpn.txt
TUNNEL_ID="$1"
INTERFACE="$3"
OLD_MTU="$4"
NEW_MTU="$5"
BATDEV=bat7
MTU=NEW_MTU
. scripts/bridge_functions.sh
# Remove interface from old bridge
brctl delif l2-br-sued${OLD_MTU} $INTERFACE
# Change interface MTU
ip link set dev $INTERFACE mtu $NEW_MTU
# Add interface to new bridge
ensure_bridge l2-br-sued${NEW_MTU}
brctl addif l2-br-sued${NEW_MTU} $INTERFACE


Danach verbinden sich die Router via l2tp.


has.down
==Kontrolle==


#!/bin/bash
- über ''systemctl status td-broker-xxx.service'' kann man den Status erfragen.
TUNNEL_ID="$1"
INTERFACE="$3"
MTU="$4"
# Remove the interface from our bridge
brctl delif l2-br-has${MTU} $INTERFACE


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


has-sued.down
- mit ''ip l2tp show tunnel'' sieht man die einzelnen Tunnel


#!/bin/bash
- mit ''ip l2tp show session'' die entsprechenden Devices
TUNNEL_ID="$1"
INTERFACE="$3"
MTU="$4"
# Remove the interface from our bridge
brctl delif l2-br-sued${MTU} $INTERFACE


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


'''Start einrichten:'''
- das Log mit journalctl -u td-broker-HOOD.service


In ''/etc/systemd/system/'' Units erstellen


tunneldigger-broker-has.service:


[Unit]
==Broker für eine Hood wieder los werden==
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 broker.main  /srv/tunneldigger/tunneldigger/broker/l2tp_broker-has.cfg
KillMode=process
Restart=on-failure
[Install]
WantedBy=multi-user.target


Beispielhood: hawaii


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


[Unit]
Service ausschalten:
Description=tunneldigger tunnelling network daemon using l2tpv3
  systemctl disable td-broker-hawaii.service
After=network.target auditd.service
[Service]
Type=simple
WorkingDirectory=/srv/tunneldigger/tunneldigger
  ExecStart=/srv/tunneldigger/env_tunneldigger/bin/python -m broker.main  /srv/tunneldigger/tunneldigger/broker/l2tp_broker-has.cfg
KillMode=process
Restart=on-failure
[Install]
WantedBy=multi-user.target


Jetzt noch den Service anmelden, autostart und manuell Start <br />
Wenn man die ganze Konfiguration weg haben will, geht es weiter.
systemctl daemon-reload  <br />
systemctl enable tunneldigger-broker-sued.service tunneldigger-broker-has.service  <br />
systemctl start tunneldigger-broker-sued.service  tunneldigger-broker-has.service  <br />


Das kann man jetzt mehrfach machen mit unterschiedlichen Konfigurationen für verschiedene Hoods.
Unit löschen:
rm /etc/systemd/system/td-broker-hawaii.service


systemd davon in Kenntnis setzen:
systemctl daemon-reload


über "systemctl status tunneldigger-broker-xxx.service" kann man den Status erfragen.
Konfigdateien löschen:
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