Erste Tests mit batman v15 und L2TP

(Kai 'wusel' Siering) #1

Moin,

es wird :wink:

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 :wink: (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?

0 Likes

Neuer Firmwarebuild - tng 1.0.2~4 - fertig
(Kai 'wusel' Siering) #2

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.)

0 Likes

(Thomas Hollenbeck) #3

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.

0 Likes

(Kai 'wusel' Siering) #4

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?

0 Likes

(Thomas Hollenbeck) #5

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

0 Likes

(Kai 'wusel' Siering) #6

Genau :wink:

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.

0 Likes

(Kai 'wusel' Siering) #7

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.

0 Likes

(Thomas Hollenbeck) #8

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?

0 Likes

(Kai 'wusel' Siering) #9

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.

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.

0 Likes

(Thomas Hollenbeck) #10

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.

0 Likes

(Thomas Hollenbeck) #11

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)

0 Likes

(Thomas Hollenbeck) #12

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

0 Likes

(Kai 'wusel' Siering) #13

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

0 Likes