Erste Tests mit batman v15 und L2TP

[wusel]

Moin,

es wird

root@luggage:~# traceroute -T -4 heise.de
traceroute to heise.de (193.99.144.80), 30 hops max, 60 byte packets
 1  10.255.0.2 (10.255.0.2)  62.402 ms  62.564 ms  70.780 ms
 2  bgp-fra01.4830.org (193.26.120.81)  73.514 ms  73.517 ms  73.504 ms
 3  bgp-ham02.4830.org (193.26.120.85)  84.281 ms  84.174 ms  84.235 ms
 4  te0-0-2-3.c350.f.de.plusline.net (80.81.193.132)  93.491 ms  93.498 ms  97.707 ms
 5  * * *
 6  * * *
 7  * * *
 8  212.19.61.13 (212.19.61.13)  82.512 ms  82.688 ms  82.678 ms
 9  redirector.heise.de (193.99.144.80)  82.645 ms  82.423 ms  82.637 ms
root@luggage:~# traceroute -T -6 heise.de
traceroute to heise.de (2a02:2e0:3fe:1001:302::), 30 hops max, 80 byte packets
 1  2001:bf7:1316:666::1 (2001:bf7:1316:666::1)  71.047 ms  97.667 ms  97.677 ms
 2  bgp-fra01.4830.org (2a06:e881:1707:1::1)  101.051 ms  101.055 ms  104.286 ms
 3  2001:868:100:6b00::4 (2001:868:100:6b00::4)  108.586 ms  108.536 ms  108.571 ms
 4  10ge15-8.core1.ham1.he.net (2001:7f8:3d::1b1b:0:1)  108.414 ms  108.437 ms  108.427 ms
 5  * * *
 6  ams-ix-v6.nl.plusline.net (2001:7f8:1::a501:2306:1)  119.757 ms  94.261 ms  387.496 ms
 7  2a02:2e0:14:6::1 (2a02:2e0:14:6::1)  387.443 ms * *
 8  2a02:2e0:12:31::2 (2a02:2e0:12:31::2)  387.341 ms  390.090 ms  389.489 ms
 9  2a02:2e0:3fe:0:c::1 (2a02:2e0:3fe:0:c::1)  390.084 ms  390.069 ms  390.123 ms
10  redirector.heise.de (2a02:2e0:3fe:1001:302::)  390.020 ms  390.050 ms *

Das ist mit einem TL-WA860RE v1 mit 1.0.2~5 in “zzz” — als Test für den Puppet-Code für L2TP-GWs. Dabei fällt mir dann spontan ein, daß ich noch 'ne Lösung für die verschiedenen Karten brauche, hrmpft (Zugang erfolgt derzeit über Vodafone LTE, Durchsatzmessung also weniger zweckmäßig. Daher auch die hohe RTT.)

Ich sehe keine Notwendigkeit für IPv4-basierte Kommunikation zwischen Endgeräten in den Meshes — Freifunk-Dienste können über IPv6 angeboten werden und damit innerhalb und außerhalb des Freifunks genutzt:

root@luggage:~# traceroute -T -6 forum.freifunk.net
traceroute to forum.freifunk.net (2a03:2260:2000:1::2), 30 hops max, 80 byte packets
 1  2001:bf7:1316:666::1 (2001:bf7:1316:666::1)  68.887 ms  69.322 ms  79.447 ms
 2  bgp-fra01.4830.org (2a06:e881:1707:1::1)  79.609 ms  79.604 ms  81.250 ms
 3  de5.as206946.net (2a06:e881:2603:42::1)  79.571 ms  81.115 ms  81.183 ms
 4  de2.as206946.net (2a06:e881:2604:42::1)  104.859 ms  104.876 ms  104.868 ms
 5  p0.irz42NET.transit.wusel.uu.org (2a00:14b0:4200:3500::136:137)  104.878 ms  104.838 ms  104.828 ms
 6  2a03:2260::3 (2a03:2260::3)  91.796 ms  74.767 ms  103.290 ms
 7  forum.freifunk.net (2a03:2260:2000:1::2)  103.259 ms  103.324 ms  103.334 ms

root@luggage:~# traceroute -T -6 2001:bf7:1310:11:fad1:11ff:febd:5e24
traceroute to 2001:bf7:1310:11:fad1:11ff:febd:5e24 (2001:bf7:1310:11:fad1:11ff:febd:5e24), 30 hops max, 80 byte packets
 1  2001:bf7:1316:666::1 (2001:bf7:1316:666::1)  83.908 ms  83.881 ms  94.774 ms
 2  bgp-fra01.4830.org (2a06:e881:1707:1::1)  94.755 ms  94.724 ms  94.692 ms
 3  bgp-gut01.4830.org (2a06:e881:1700:1:400:c0ff:fefb:e277)  94.667 ms  94.653 ms  94.655 ms
 4  2a06:e881:1700:1:400:c0ff:fefb:e251 (2a06:e881:1700:1:400:c0ff:fefb:e251)  94.615 ms  94.598 ms  94.590 ms
 5  2001:bf7:1310:11:fad1:11ff:febd:5e24 (2001:bf7:1310:11:fad1:11ff:febd:5e24)  128.209 ms  131.153 ms  131.205 ms

Wenn man v4 als reinen “Internet-Zugringerdienst” sieht – für mehr taugt es auch nicht mehr –, wird sowohl das Netzdesign als auch die Firmwareverwaltung deutlich weniger komplex. Comments?

[wusel]

Ich sehe keine Notwendigkeit für IPv4-basierte Kommunikation zwischen Endgeräten in den Meshes

Weil das vielleicht etwas zu technisch-abgekürzt war: es geht darum, ob ein Endgerät z. B. im “zzz”-Mesh ein Endgerät z. B. im “gut”-Mesh über das veraltete Internetprotokoll Version 4 (IPv4) erreichen können soll. In dem Falle brauchen wir für jedes Mesh disjunkte IPv4-Netzbereiche – also z. B. 10.255.0.0 bis 10.255.15.255 für “gut”, 10.255.16.0 bis 10.255.31.255 für “zzz”, … – und müßten diese sogenannten “privaten” Adressen in unserem Backbone routen, die anderen Netzbereiche jeweils in der Firmwares hinterlegen, …

Relevant würde das einzig, wenn ein Nutzer mit seinem Smartphone im “zzz”-Mesh z. B. einen Feinstaubsensor im “gut”-Mesh direkt ansprechen wollen würde — letztere können nämlich leider auch noch nicht mit dem heute aktuellen Adressformat, IPv6, umgehen. (Über IPv6 ist das alles kein Problem, da dort für wirklich jedes Endgerät auf diesem Planeten ein paar Adressen verfügbar sind.)

[Thomas]

Wenn man v4 als reinen “Internet-Zugringerdienst” sieht – für mehr taugt es auch nicht mehr –, wird sowohl das Netzdesign als auch die Firmwareverwaltung deutlich weniger komplex. Comments?

Hmm, evtl. könnte man auch Proxys einsetzen, die über v4 erreichbar sind und dann Traffic von v6 Adressen an v4 weiterleiten. Könnte nur mit der DNS Auflösung dann etwas harig werden. Würde aber das Augenmerks auch eher auch funktionierendes v6 Routing in beiden Richtungen setzen.

[wusel]

Du kannst auch heute keine Dienste auf v4 hosten, die außerhalb des Meshes erreichbar sind (Theorie, ICVPN funktioniert und es gibt dort ‘Dienste’, mal außen vor).
Was beim Netsplit bedeutet, je nach Entscheidung, daß nachher jemand z. B. aus Gütersloh nicht mehr auf z. B. Feinstaubsensoren in Halle direkt zugreifen kann — diskussionswert: war das vom ‘Feinstaubsammler’ überhaupt gewünscht?

(Aber Du kannst natürlich jetzt oder später z. B. auf 'nem RPi einen Proxy laufen lassen und damit Deinen Feinstaubsensor öffentlich, über IPv6, zugänglich machen.)

Vorteil, v4 auf das jeweilige Mesh zu begrenzen: ‘thisnode’, also die spezielle IP die auf jedem Knoten lokal bleibt (und aus technischen Gründen im IP-Nummernkreis des lokalen Meshs liegen muß), wäre überall im Kreis GT 10.255.0.1 (Müritz/Feldberg: 10.169.0.1).

Nachteil: über IPv4 kann man nur mit öffentlichen Adressen, kommunizieren (und im eigenen Mesh). Frage: Wie oft hat jemand einen anderen Client im Freifunk über IPv4 kontaktiert?

[Thomas]

Frage: Wie oft hat jemand einen anderen Client im Freifunk über IPv4 kontaktiert?

Nur wenn v6 aus welchen Gründen auch immer gerade nicht funktioniert hat. Und dann war es schon aus Wiedenbrück nach Langenberg oder Rietberg. Deshalb sage ich ja funktionierendes v6.
Wenn v4 von jemandem gebraucht wird muss er/sie halt über einen Proxy gehen. Hmm, wobei dann müssten zumindestens die vom DHCP vergebenen in verschiedenen Ranges liegen.
…

Das Problem besteht doch hauptsächlich bei der 10.255.0.1, oder? Kann der Knoten die nicht selber per iptables umbiegen auf sich? Egal in welchen Subnetz der Client ist

[wusel]

Hmm, wobei dann müssten zumindestens die vom DHCP vergebenen in verschiedenen Ranges liegen.

Genau

Das Problem besteht doch hauptsächlich bei der 10.255.0.1, oder? Kann der Knoten die nicht selber per iptables umbiegen auf sich? Egal in welchen Subnetz der Client ist

Ich meine nicht; der Trick an der IP ist, daß sie im LAN gesucht wird (da im IP-Bereich der Client-IPs), über ebtables die Weiterleitung in der br-client blockiert wird und somit der Knoten antworten kann. Ich bin mir nicht sicher, ob man das mit beispielsweise 6.6.6.6 auch hinbekäme.

[wusel]

Hmm, aber das Problem läßt sich ja auch anders angehen: statt v4 gleich zu halten, kann man das ja mit den “privaten” v6-Adressen (ULA) machen.

Die werden in verbundenen Meshes weder geroutet noch verwendet (dafür gibt’s den öffentlichen Prefix), in nicht verbundenen ist es auch egal, daß diese nicht eindeutig sind — das lokale Mesh ist ja isoliert. Damit könnte man z. B. http://[fd10:ca1::1] zur neuen generischen Knoten-URL machen (und das für v4 kompett entfallen lassen, da Knoten eigentlich eh’ kein v4 machen), bißchen doof einzugeben, aber machbar. »master«, »rawhide« und »tng« wurde heute vormittag entsprechend gebaut. mal gucken, ob das so klappt.

[Thomas]

Das Problem besteht doch hauptsächlich bei der 10.255.0.1, oder? Kann der Knoten die nicht selber per iptables umbiegen auf sich? Egal in welchen Subnetz der Client ist

Ich meine nicht; der Trick an der IP ist, daß sie im LAN gesucht wird (da im IP-Bereich der Client-IPs), über ebtables die Weiterleitung in der br-client blockiert wird und somit der Knoten antworten kann. Ich bin mir nicht sicher, ob man das mit beispielsweise 6.6.6.6 auch hinbekäme.

Dann würde IPv6 aber auch nicht weiter helfen.
Mit http://[fd10:ca1::1] hätte man doch das selbe Problem, mit den unterschiedlichen Subnetzen.
Oder sehe ich das jetzt verkehrt?

Gibt es noch einen andere Funktion dieser IP als das einloggen bei Debugen falls der Knoten Offline ist?

[wusel]

Dann würde IPv6 aber auch nicht weiter helfen.
Mit http://[fd10:ca1::1] hätte man doch das selbe Problem, mit den unterschiedlichen Subnetzen.
Oder sehe ich das jetzt verkehrt?

Jein: bei IPv4 wird je Mesh ein Netz 10.x.y.0/z verwendet, um die Clients zu den (NAT-) Gateways zu routen. 10.x.y.1/z (strenggenommen w.x.y.1/z) wird dabei auf dem jeweiligen Knoten terminiert (ein Knoten hat im Freifunk-Mesh keine eigene IPv4-Adresse), liegt also auf jedem Knoten (und ist von den Gateways aus nicht erreichbar, da der Datenverkehr zu der IPv4-Adresse in Gluon nur zwischen WLAN & Knoten erlaubt wird (ebtables)).

Anders als bei IPv4, haben (in unserem Setup) bei IPv6 alle Geräte im Netz, also Knoten als auch Endgeräte, (mindestens) eine eindeutige, öffentliche IPv6-Adresse.

Parallel dazu sind die Knoten auch noch im sog. ULA-Netz präsent und jeder Knoten teilt aktiv diesen Präfix mit. Da das Netz und alle relevanten Netzkomponenten – z. B. Clients – IPv6-fähig sind, kann man den Fakt, daß wir bei IPv6 mehrere Adressierungsbereiche haben – das öffentliche Internet sowie das lokale Mesh – auch nutzen. Die ULA-Netzbereiche müssen nicht miteinander verbunden werden, da diese per Definition »lokal« sind. Zwischen Meshes kann man über die öffentliche IPv6-Adressen sich verbinden.
Aber bei IPv4 haben wir nur den lokalen Adressebereich, hier muß man, um Datenverkehr zwischen dem Meshes ohne NAT zu ermöglichen, unterschiedliche private IPv4-Adressebereiche nutzen.

Gibt es noch einen andere Funktion dieser IP als das einloggen bei Debugen falls der Knoten Offline ist?

Die ULA-Adressen “vergibt” jeder Knoten (SLAAC “vergibt” keine konkreten IPv6-Adressen an Endgeräte, sondern teilt diesen vielmehr mit, aus welchem Adressbereich – Präfix – sie sich bedienen sollen), damit ist das Netz/Mesh auch noch funktional, wenn keine Internetverbindung mehr besteht. Die Info über den öffentlichen Präfix als auch die Zuweisung einer IPv4-Adresse je Client kommt aus dem Rechenzentrum — kurz: über ULA kann auch im lokalen Netz/Mesh Datenverkehr stattfinden. That said: ja, faktisch eine Bedeutung hat ULA heute nur für’s Debugging.

[Thomas]

http://[fd10:ca1::1] … »master«, »rawhide« und »tng« wurde heute vormittag entsprechend gebaut. mal gucken, ob das so klappt.

Mit der Adresse http://[fd10:ca1::1] klappt soweit auf allen APs, (außer wenn aus welchen gründen auch immer das IPv6 Autoconfig versagt. DHCPv4 scheint einfach noch stabiler zu laufen)
Aber gut die Seite 10.255.0.1 wird eigentlich ja sowiso nur für technisch versierte Personen gebraucht. Also, sollte das kein Problem darstellen.

[Thomas]

War gerade auf meinen 841v9 Test Knoten für L2TP per SSH drauf. Er hatte 99% Sys Last. Siehe Screenshot.

Per Befehl war ein neustart nicht möglich. Der Reboot Befehl wurde nicht mehr ausgeführt. Habe den Stecker gezogen. Danach war wieder alles OK. Werde das mal beobachten.

(Trotz der Last hatte ich aber immer noch einen Durchsatz von 30 Mbit/s)

[Thomas]

@wusel
ist der v15/L2TP Server aktuell Offline? Oder habe ich meinen Knoten kaputt gemacht?

[wusel]

ist der v15/L2TP Server aktuell Offline

Jein; ich habe den offensichtlich kaputt gemacht – IPv6-Adressen geändert, aktualisiert, rebootet –, verstehe aber noch nicht, wie