Umstellung auf L2TP

Orginaler Blog-Post: https://freifunk-kreisgt.de/umstellung-auf-l2tp/

Wie schon berichtet, geht die Erneuerung der Infrastruktur inkl. Änderungen an der Firmware weiter.

Mit dem nächsten Schritt werden wir dem »fastd«-Protokoll den Rücken kehren und auf L2TP als Tunnel-Lösung umstellen. Hierzu gibt dieser Beitrag ein paar Hinter­grund­in­for­mationen.

Vorteile:

  • Höherer Datendurchsatz auch bei kleinen Routern:
    Da L2TP ein Protokoll ist, welches direkt durch den Linux-Kernel unterstützt wird, gibt es weniger sogenannte Contextswitches zwischen Kernel- und Userspace. Dies führt zu einem erheblichen Durchsatzzuwachs. Mit dem veralteten, aber auch weit verbreiteten, Router TP-Link WR841N sind Geschwindigkeiten bis zu 30 Mbit/s möglich; mit größeren Modellen deutlich mehr (sofern es lokaler Internetzugang und die Infrastruktur in unserem Backend erlauben).
     
  • Entlastung der Gateways:
    In geringerem Umfang, aber prinzipiell genauso, profitieren auch unsere Gateways von der niedrigeren Last durch den Wechsel auf L2TP. Theoretisch stehen auch bei stärkerer Nutzung unseres Netzwerkes nun mehr Resourcen zur Verfügung — wir werden sehen, wie das in der Praxis sich zeigt.

Nachteile:

  • IPv4-only:
    Die eingesetzte Lösung, die die L2TP-Tunnel zwischen Gateways und Knoten aushanelt, kann derzeit Tunnel nur über das veraltete Protokoll IPv4 aufbauen. Insbesondere an Kabelanschlüssen mit »DS-Lite«, also ohne »echte« IPv4-Adresse und providerseitigem Tunneling von IPv4 über IPv6, kann sich dies als Nachteil erweisen (MTU, Durchsatz).

Die entsprechende Firmware und die dazugehörigen neuen Gateways sind derzeit im Alpha-Test. Aus technischen Gründen (Wechsel auch der Batman-Version) können alte und neue Firmware nicht koexistieren — die Test-Firmware spannt daher die SSID »l2tp.Kreis­GT.frei­funk.net« (und »l2tp.mue­ritz.frei­funk.net« sowie »l2tp.feld­berg.frei­funk.net«) auf, was zu einer kurz­zeitig gefühlt schlechteren Abdeckung führen wird.

FTR, dieser Beitrag kommt über einen Knoten im ‘zzz’-Mesh (außerhalb unseres normalen ‘Versorgungsgebietes’) über L2TP (und das hinter einem Mobilfunkrouter). DNSv6 auf dem Frankfurter Gateway war noch borked, das ist nun aber auch behoben … Anbindung an Kartenserver fehlt allerdings noch :slight_smile:

2 „Gefällt mir“

Wollte gerade nur gute Erfahrungsberichte mit L2TP schreiben, aber da hakt noch etwas im Wiedenbrücker Raum.
Habe gerade 33378-freifunk-a42bb0f43a87 umgestellt. Koordinaten von Wiedenbrück beibehalten. Alte Einstellungen sind auch übernommen worden. DNS Auflösung ist auch OK, aber scheinbar das Routing nicht.

Routenverfolgung zu google-public-dns-a.google.com [8.8.8.8]
über maximal 30 Hops:

1 29 ms 28 ms 29 ms 10.255.128.2
2 * * * Zeitüberschreitung der Anforderung.
3 * * * Zeitüberschreitung der Anforderung.
4 * * * Zeitüberschreitung der Anforderung.
5 * * * Zeitüberschreitung der Anforderung.
6

Zu den beiden Knoten in Rietberg, die seit einiger Zeit umgestellt sind, von dort habe ich keine Probleme gehört, bzw. selber feststellen können. Speed ist besser, aber was soll man von einer 12000 Leitung erwarten (nicht viel).

Hmm. IPv4 stimmt in der Tat nicht:

Chain POSTROUTING (policy ACCEPT 2391 packets, 160K bytes)
 pkts bytes target     prot opt in     out     source               destination         
 […]
    0     0 SNAT       all  --  *      tun-ffgt+  0.0.0.0/0            0.0.0.0/0            to:192.251.226.214

Aber:

root@l2tp-ham01 ~ # ip -4 route show table ffnet
default via 193.26.120.113 dev ens3 proto bird 

ens3 != tun-ffgt* => kein NAT => kein Rückweg.

Should be fixed by:

root@l2tp-ham01 ~ # iptables -A POSTROUTING -t nat -s 0.0.0.0/0 -o ens3 -j SNAT --to-source 192.251.226.214

Aber: 10.255.128.2 ist “Domäne 00”, das sollte “zzz”-Locationcode sein, “unbekannt”/“janz weit draußen”. Lt. http://hopglass.4830.org/all/#!/de/map/a42bb0f43a87 hatte der Knoten allerdings die RHWD-Einstellung. Odd.

Ja war ein RhWD Knoten. Habe nur das update installiert. Keine Änderung an den Geo Daten gemacht.


Archer C7 als Oflloader an Unifi APs mit VDSL50(Max 55.504 kbit/s
10.032 kbit/s)

1 „Gefällt mir“

FTR, noch ein Routingproblem behoben (aus Hamburg ging Traffic zur DTAG statt über Berlin und unsere Anbindung an den Community-IX über Amsterdam und Coloclue an den AMSIX):

root@gw01 ~ # traceroute -s 192.251.226.210 87.142.37.40
traceroute to 87.142.37.40 (87.142.37.40), 30 hops max, 60 byte packets
 1  bgp-ham02.4830.org (193.26.120.85)  9.753 ms * *
 2  nl0.as206946.net (193.26.120.65)  29.918 ms  29.914 ms  29.883 ms
 3  * * *
 4  amx-gw2.nl.dtag.de (80.249.209.211)  25.866 ms  25.847 ms  25.780 ms
 5  87.137.214.209 (87.137.214.209)  31.808 ms  31.952 ms 87.137.220.105 (87.137.220.105)  31.938 ms
 6  p578E2528.dip0.t-ipconnect.de (87.142.37.40)  35.599 ms  36.147 ms  36.324 ms
 7  p578E2528.dip0.t-ipconnect.de (87.142.37.40)  37.282 ms  37.271 ms  39.410 ms

Grund war, daß die L2TP-Links nach Berlin mit Präferenz 90 schlechter bewertet wurden als die gelpanten WireGuard-Links mit 100, die WG-Infrastruktur aber noch nicht existiert (stattdessen sind die Links meist VXLAN derzeit) und somit die internen Links schlechter bewertete wurden als externe (100).

Fixed:

root@gw01 ~ # traceroute -s 192.251.226.210 87.142.37.40
traceroute to 87.142.37.40 (87.142.37.40), 30 hops max, 60 byte packets
 1  bgp-ham02.4830.org (193.26.120.85)  9.781 ms  9.773 ms  9.770 ms
 2  bgp-ber01.4830.org (193.26.120.86)  12.650 ms  12.651 ms  12.638 ms
 3  dtag.l105.community-ix.de (185.1.74.27)  25.609 ms  26.552 ms  26.552 ms
 4  87.137.214.213 (87.137.214.213)  25.540 ms  25.527 ms  25.496 ms
 5  p578E2528.dip0.t-ipconnect.de (87.142.37.40)  35.119 ms  35.518 ms  35.536 ms
 6  p578E2528.dip0.t-ipconnect.de (87.142.37.40)  35.790 ms  31.659 ms  32.192 ms

Gerade einmal geschaut was das Knoten im Configmode ausgibt ohne etwas zu verändern.

Hostname 33378-freifunk-a42bb0f43a87
MAC-Adresse a4:2b:b0:f4:3a:87
Hardware-Modell TP-Link Archer C7 v2
Gluon-Version ae67c5f
Firmware-Release 1.1.5~3
Community Freifunk KreisGT (Stadt RHWD)brokers

IP bleibt auch einem Neustart 128er Bereich.

root@33378-a42bb0f43a87:~# uci get gluon.core.domain
rhw

Ja, PEBKAC (Problem Exists Between Keyboard And Chair) …

  brokers = {
    'rhw.l2tp-gut01.4830.org:10000',
        'rhw.l2tp-gut02.4830.org:10000',
        'rhw.l2tp-ham01.4830.org:10000',
        'rhw.l2tp-ham02.4830.org:10000',
        'rhw.l2tp-fra01.4830.org:10000',
        'rhw.l2tp-ams01.4830.org:10000',

wusel@ysabell:~$ host rhw.l2tp-gut01.4830.org
rhw.l2tp-gut01.4830.org has address 127.6.6.6
wusel@ysabell:~$ host rhw.l2tp-ham01.4830.org
rhw.l2tp-ham01.4830.org is an alias for l2tp-ham01.4830.org.
l2tp-ham01.4830.org has address 193.26.120.125
l2tp-ham01.4830.org has IPv6 address 2a06:e881:1702:1:400:c1ff:fe1a:787d
wusel@ysabell:~$ 

Soweit, so gut.

root@l2tp-ham01 ~ # netstat -anp | grep python
udp    10752      0 193.26.120.125:10000    0.0.0.0:*                           680/python          
udp    32256      0 193.26.120.125:10001    0.0.0.0:*                           692/python          
udp        0      0 193.26.120.125:10002    0.0.0.0:*                           628/python          
udp        0      0 193.26.120.125:10004    0.0.0.0:*                           685/python          
udp        0      0 193.26.120.125:10005    0.0.0.0:*                           632/python          
udp        0      0 193.26.120.125:10006    0.0.0.0:*                           689/python          
udp    30720      0 193.26.120.125:20101    91.36.179.65:34792      ESTABLISHED 680/python          
[…]

l2tp-ham01 ist nach der (adaptierten) Münsteraner Ansible-Rolle (nennt man das so? Bei Puppet heißt die Beschreibung “Rezept” …) aufgesetzt: jede (numerische) “Domäne” hat einen Tunneldigger auf Port ($Basis + $Domaene), hier: 10000+0 für “zzz”.

domaenen:
  "01":
    name: Freifunk KreisGT (Stadt GT)
    community: Freifunk KreisGT
    site_code: "gut"
    ffv4_network: 10.234.128.0/20
    ffv6_network: 2001:bf7:1310:128::/64
…
  "04":
    name: Freifunk KreisGT (Rheda-Wiedenbrück)
    community: Freifunk KreisGT
    site_code: "rhw"
    ffv4_network: 10.234.144.0/20
    ffv6_network: 2001:bf7:1310:144::/64
…
  "00":
    name: Freifunk by 4830.org
    community: Freifunk by 4830.org
    site_code: "zzz"
    ffv4_network: 10.255.128.0/20
    ffv6_network: 2001:bf7:1310:666::/64
…

Sprich: da stimmt die Firmware (-Planung) nicht mehr mit der (geänderten) Gateway-Planung überein. Oops :wink:

Also auf neu Firmware warten, korrekt?

Yepp, die baut gerade …

Kann es sein das sie kaputt ist? Auf jeden Fall waren heute morgen um fünf die Knoten zu Hause offline und in Druffel aktuell auch. Man ändert heute Abend spät erst schauen wo es genau hängt

Möglich — oder nun im richtigen Mesh, aber das ist noch ohne Kartenanbindung? Guck’ ich mir heute abend mal an!

Ne strahlt Offline aus.

Ack, hier Zuhause auch, dito in der 4ma — da hab’ ich’s wohl hingerichtet das l2tp-Netz … Sorry for that.

config broker 'mesh_vpn'
        option uuid 'f8d111bd5e24'
        option group 'gluon-mesh-vpn'
        option broker_selection 'usage'
        option bind_interface 'br-wan'
        option interface 'mesh-vpn'
        option enabled '1'
        list address 'gut.l2tp-gut01.4830.org:10001'
        list address 'gut.l2tp-gut02.4830.org:10001'
        list address 'gut.l2tp-ham01.4830.org:10001'
        list address 'gut.l2tp-ham02.4830.org:10001'
        list address 'gut.l2tp-fra01.4830.org:10001'
        list address 'gut.l2tp-ams01.4830.org:10001'

Soweit, so schick …

root@33332-Schalueckstr-Garten1:~# logread -f
Mon May  6 13:59:16 2019 daemon.err td-client: No suitable brokers found. Retrying in 5 seconds.
Mon May  6 13:59:21 2019 daemon.notice netifd: wan (27729): udhcpc: sending renew to 0.0.0.0
Mon May  6 13:59:21 2019 daemon.notice netifd: wan (27729): udhcpc: lease of 192.168.5.202 obtained, lease time 30
Mon May  6 13:59:21 2019 daemon.err td-client: Resetting status of brokers and starting from scratch.
Mon May  6 13:59:21 2019 daemon.info td-client: Performing broker selection...
Mon May  6 13:59:32 2019 daemon.err td-client: No suitable brokers found. Retrying in 5 seconds.
Mon May  6 13:59:36 2019 daemon.notice netifd: wan (27729): udhcpc: sending renew to 0.0.0.0
Mon May  6 13:59:36 2019 daemon.notice netifd: wan (27729): udhcpc: lease of 192.168.5.202 obtained, lease time 30
Mon May  6 13:59:37 2019 daemon.err td-client: Resetting status of brokers and starting from scratch.
Mon May  6 13:59:38 2019 daemon.info td-client: Performing broker selection...

*Kopfkratz*

root@33332-Schalueckstr-Garten1:~# nslookup gut.l2tp-gut01.4830.org
;; connection timed out; no servers could be reached
root@33332-Schalueckstr-Garten1:~# cat /tmp/resolv.conf.auto 
# Interface wan
# Interface wan6

Hmm? Keinen DNS-Server per DHCP bekommen?! Dürfte aber lokales Problem sein, renovierungsbedingt ist das Netz hier grade komisch …

root@33332-Schalueckstr-Garten1:~# echo "nameserver 1.1.1.1" >> /tmp/resolv.conf.auto
root@33332-Schalueckstr-Garten1:~# cat /tmp/resolv.conf.auto 
# Interface wan
# Interface wan6
nameserver 1.1.1.1
root@33332-Schalueckstr-Garten1:~# nslookup gut.l2tp-gut01.4830.org
Server:         127.0.0.1
Address:        127.0.0.1#53

Name:      gut.l2tp-gut01.4830.org
gut.l2tp-gut01.4830.org canonical name = l2tp-gut01.4830.org
Name:      l2tp-gut01.4830.org
Address 1: 192.251.226.126
gut.l2tp-gut01.4830.org canonical name = l2tp-gut01.4830.org
Address 2: 2a06:e881:1700:1:400:c0ff:fefb:e27e
root@33332-Schalueckstr-Garten1:~# logread -f
Mon May  6 14:04:12 2019 daemon.err td-client: Resetting status of brokers and starting from scratch.
Mon May  6 14:04:12 2019 daemon.info td-client: Performing broker selection...
Mon May  6 14:04:21 2019 daemon.notice netifd: wan (27729): udhcpc: sending renew to 0.0.0.0
Mon May  6 14:04:21 2019 daemon.notice netifd: wan (27729): udhcpc: lease of 192.168.5.202 obtained, lease time 30
Mon May  6 14:04:23 2019 daemon.err td-client: No suitable brokers found. Retrying in 5 seconds.

Hrmpft.

root@33332-Schalueckstr-Garten1:~# for i in gut01 gut02 ham01 ham02 fra01 ams01 ; do echo $i ; echo ; nslookup gut.l2tp-$i.4830.or
g 1.1.1.1 ; echo ; done
gut01

Server:         1.1.1.1
Address:        1.1.1.1#53

Name:      gut.l2tp-gut01.4830.org
gut.l2tp-gut01.4830.org canonical name = l2tp-gut01.4830.org
Name:      l2tp-gut01.4830.org
Address 1: 192.251.226.126
gut.l2tp-gut01.4830.org canonical name = l2tp-gut01.4830.org
Address 2: 2a06:e881:1700:1:400:c0ff:fefb:e27e

gut02

Server:         1.1.1.1
Address:        1.1.1.1#53

Name:      gut.l2tp-gut02.4830.org
gut.l2tp-gut02.4830.org canonical name = l2tp-gut02.4830.org
Name:      l2tp-gut02.4830.org
Address 1: 192.251.226.125
gut.l2tp-gut02.4830.org canonical name = l2tp-gut02.4830.org
Address 2: 2a06:e881:1700:1:400:c0ff:fefb:e27d

ham01

Server:         1.1.1.1
Address:        1.1.1.1#53

Name:      gut.l2tp-ham01.4830.org
Address 1: 127.6.6.6
*** Can't find gut.l2tp-ham01.4830.org: No answer

ham02

Server:         1.1.1.1
Address:        1.1.1.1#53

Name:      gut.l2tp-ham02.4830.org
Address 1: 127.6.6.6
*** Can't find gut.l2tp-ham02.4830.org: No answer

fra01

Server:         1.1.1.1
Address:        1.1.1.1#53

Name:      gut.l2tp-fra01.4830.org
Address 1: 127.6.6.6
*** Can't find gut.l2tp-fra01.4830.org: No answer

ams01

Server:         1.1.1.1
Address:        1.1.1.1#53

Name:      gut.l2tp-ams01.4830.org
Address 1: 127.6.6.6
*** Can't find gut.l2tp-ams01.4830.org: No answer

Hmmm …

wusel@ysabell:~$ ssh root@l2tp-gut01.4830.org netstat -anup \| grep pyth
wusel@ysabell:~$ ssh root@l2tp-gut02.4830.org netstat -anup \| grep pyth
udp        0      0 192.251.226.125:10000   0.0.0.0:*                           4173/python     
wusel@ysabell:~$ ssh root@l2tp-ham01.4830.org netstat -anup \| grep pyth
udp    13056      0 193.26.120.125:10000    0.0.0.0:*                           680/python          
udp    33792      0 193.26.120.125:10001    0.0.0.0:*                           692/python          
udp        0      0 193.26.120.125:10002    0.0.0.0:*                           628/python          
udp        0      0 193.26.120.125:10004    0.0.0.0:*                           685/python          
udp        0      0 193.26.120.125:10005    0.0.0.0:*                           632/python          
udp        0      0 193.26.120.125:10006    0.0.0.0:*                           689/python          
udp        0      0 193.26.120.125:20102    91.36.179.65:41555      ESTABLISHED 680/python          
wusel@ysabell:~$ ssh root@l2tp-ber01.4830.org netstat -anup \| grep pyth
udp    52224      0 193.26.120.99:10001     0.0.0.0:*                           646/python          
udp        0      0 193.26.120.99:10002     0.0.0.0:*                           623/python          
udp        0      0 193.26.120.99:10003     0.0.0.0:*                           661/python          
udp        0      0 193.26.120.99:10004     0.0.0.0:*                           613/python          
udp        0      0 193.26.120.99:10005     0.0.0.0:*                           610/python          
udp        0      0 193.26.120.99:10006     0.0.0.0:*                           659/python          

Dann tmp-fixen wir das doch mal eben schnell im DNS …

wusel@ysabell:~$ for i in gut gto gt8 wrz fsl ; do host $i.l2tp-ham01.4830.org dns-gut.4830.org. | grep alias ; done
wrz.l2tp-ham01.4830.org is an alias for l2tp-ham01.4830.org.
fsl.l2tp-ham01.4830.org is an alias for l2tp-ham01.4830.org.
wusel@ysabell:~$ for i in gut gto gt8 wrz fsl ; do grep $i.l2tp-ham01.4830.org /data/wusel/site-ffgt-v2018.1/domains-l2tp/* ; done
/data/wusel/site-ffgt-v2018.1/domains-l2tp/gut.conf:            'gut.l2tp-ham01.4830.org:10001',
/data/wusel/site-ffgt-v2018.1/domains-l2tp/gto.conf:            'gto.l2tp-ham01.4830.org:10002',
/data/wusel/site-ffgt-v2018.1/domains-l2tp/gt8.conf:        'gt8.l2tp-ham01.4830.org:10003',
/data/wusel/site-ffgt-v2018.1/domains-l2tp/wrz.conf:            'wrz.l2tp-ham01.4830.org:10005',
/data/wusel/site-ffgt-v2018.1/domains-l2tp/fsl.conf:            'fsl.l2tp-ham01.4830.org:10006',

DNS geändert, reloaded:

wusel@ysabell:~$ for i in gut gto gt8 wrz fsl ; do host $i.l2tp-ham01.4830.org dns-gut.4830.org. | grep alias ; done
gut.l2tp-ham01.4830.org is an alias for l2tp-ham01.4830.org.
gto.l2tp-ham01.4830.org is an alias for l2tp-ham01.4830.org.
gt8.l2tp-ham01.4830.org is an alias for l2tp-ham01.4830.org.
wrz.l2tp-ham01.4830.org is an alias for l2tp-ham01.4830.org.
fsl.l2tp-ham01.4830.org is an alias for l2tp-ham01.4830.org.

Scheint zu tun:

wusel@ysabell:~$ ssh root@l2tp-ham01.4830.org netstat -anup \| grep pyth
udp    13056      0 193.26.120.125:10000    0.0.0.0:*                           680/python          
udp     3840      0 193.26.120.125:10001    0.0.0.0:*                           692/python          
udp     6912      0 193.26.120.125:10002    0.0.0.0:*                           628/python          
udp        0      0 193.26.120.125:10004    0.0.0.0:*                           685/python          
udp        0      0 193.26.120.125:10005    0.0.0.0:*                           632/python          
udp        0      0 193.26.120.125:10006    0.0.0.0:*                           689/python          
udp    46592      0 193.26.120.125:20101    84.179.119.12:33671     ESTABLISHED 692/python          
udp     3840      0 193.26.120.125:20102    91.36.179.65:41555      ESTABLISHED 680/python          
udp    39168      0 193.26.120.125:20104    88.76.249.207:41145     ESTABLISHED 628/python          
udp    42752      0 193.26.120.125:20105    178.201.41.190:50389    ESTABLISHED 692/python          
udp    16896      0 193.26.120.125:20106    87.142.43.35:45579      ESTABLISHED 692/python          
udp    23808      0 193.26.120.125:20107    91.36.179.65:45601      ESTABLISHED 692/python          
udp    37632      0 193.26.120.125:20108    88.153.161.209:63557    ESTABLISHED 692/python          
udp    37632      0 193.26.120.125:20109    88.153.161.209:58532    ESTABLISHED 692/python          

root@33332-Schalueckstr-Garten1:~# batctl gwl
[B.A.T.M.A.N. adv openwrt-2018.1-5, MainIF/MAC: primary0/b6:49:05:e3:ce:33 (bat0/f8:d1:11:bd:5e:24 BATMAN_IV)]
  Router            ( TQ) Next Hop          [outgoingIf]  Bandwidth
* 02:ca:ff:ee:01:02 ( 93) 02:ca:ff:ee:01:02 [  mesh-vpn]: 1024.0/1024.0 MBit
  02:ca:ff:ee:01:04 ( 80) 02:ca:ff:ee:01:02 [  mesh-vpn]: 1024.0/1024.0 MBit

hopglass.4830.org/tng/ hat nun die 7 Teilnetze zusammengefaßt (Stadt GT, Nordkreis GT, Südkreis GT, Stadt Rheda-Wiedenbrück, Müritz-Region, Feldberger Seenlandschaft sowie “sonstwo”) …

Ipv4 scheint aktuell im L2Tp Netz ein Problem z haben.


Sowohl über die Knoten die über das Gütersloher Netz gehen, als auch über das Wiedenbrücker Netz.

Nach dem Fuckup heute Vormittag hat das L2TP-Testbed niedrige Prio, sorry.