Gluon Babel Firmware Test: Unterschied zwischen den Versionen

Aus Opennet
Wechseln zu: Navigation, Suche
(Laborbuch angefangen)
(→‎24.02.2021)
Zeile 141: Zeile 141:
  
 
* Firmware auf WDR4300 Router installiert.  
 
* Firmware auf WDR4300 Router installiert.  
−
* Client am Router bekommt fd02::2 IP. Warum diese IP? Es gibt aber keinerlei IP aus dem Adressbereich der site.conf. Warum nicht?
+
* Client am Router bekommt fd02::2/64 als IP. Warum diese IP? Es gibt aber keinerlei IP aus dem Adressbereich der site.conf. Warum nicht?
−
* VPN Verbindung mit fastd:  ...
+
* SSH zum AP nur über Link Local möglich:
−
* Babel: ...
+
 
 +
  ssh fe80::1441:95ff:fe40:f7dc%enp53s0 -l root
 +
 
 +
* Das fd02::/64 ist auf AP (fd02::1) und Client (fd02::2) konfiguriert, jedoch erreich der Client den AP hierüber nicht (AP antwortet nicht auf ping oder ssh). Ist vielleicht so gewollt?
 +
* VPN Verbindung mit fastd erfolgreich aufgebaut
 +
* Babel: auf AP ist route zu itsuki zu sehen und damit funktioniert auch Babel:
 +
  root@c4e9847de44a:~# ip -6 route show table all | grep 244
 +
  fd32:d8d3:87da:bab1::244 via fe80::14d5:80ff:fe2b:3606 dev mesh-vpn src fd32:d8d3:87da:bab1:c6e9:84ff:fe7d:e44a  metric 96
 +
* Ping vom AP zu itsuki läuft hat(te) komisches Verhalten. Erst nach 160 Pings ohne Antwort, kam dann plötzlich eine Antwort zurück und dann auch dauerhaft. Ich hatte kurz vorher ein tcpdump auf itsuki gemacht, um das Problem zu untersuchen. Ob beides zusammenhängt? Jedenfalls scheint jetzt der Ping zu funktionieren:
 +
  10:32:18.500191 IP6 fd32:d8d3:87da:bab1:c6e9:84ff:fe7d:e44a > fd32:d8d3:87da:bab1::244: ICMP6, echo request, seq 213, length 64
 +
  10:32:18.500254 IP6 fd32:d8d3:87da:bab1::244 > fd32:d8d3:87da:bab1:c6e9:84ff:fe7d:e44a: ICMP6, echo reply, seq 213, length 64
 +
* Alle erreichbaren Babel Clients sind bspw. zu finden via:
 +
  root@itsuki:~# ip -6 route show table 10
 +
  fd32:d8d3:87da:bab1:c6e9:84ff:fe7d:e44a via fe80::dcc6:50ff:fef2:2f3f dev babel-vpn proto babel metric 96 onlink pref medium
 +
  fd32:d8d3:87da:bab2:82fa:5bff:fe8a:7eac via fe80::dcc6:50ff:fef2:2f3f dev babel-vpn proto babel metric 96 onlink pref medium
 +
  fd32:d8d3:87da:bab2::/64 dev l3roam0 metric 1024 pref medium

Version vom 25. Februar 2021, 11:46 Uhr

Inhaltsverzeichnis

ONI Babel Gluon Test-Firmware

Motivation

Wir sind interessiert an der Gluon Firmware. Würde wir diese Firmware bei uns einsetzen, könnten wir an deren Weiterentwicklung partizipieren.

Aktuell (2020) gibt es eine Entwicklung, um das Babel Routing in Gluon anstatt batman zu nutzen.

Doku:

Babel Firmware von Klaus_Dieter:

Site Config - Magdeburg:

Gluon Originial:


Test1: Firmware mit (Gluon + Babel + Fastd)

Um die Gluon Config zu verstehen haben wir das Original Gluon (inkl. Babel) installiert und getestet.

Ziel ist hier ein IPv6-only Backbone Netz zu haben.

Firmware Entwicklung
  • Bauen der Firmware: 
sudo apt install build-essential gawk unzip libncurses-dev libz-dev libssl-dev time
git clone git@git.hack-hro.de:opennet-initiative/gluon.git -b v2020.2.2
cd gluon/
git clone git@dev.on-i.de:on_site_babel_test site
make update
make GLUON_TARGET=ar71xx-generic
  • Unser Gluon Repo updaten (Sync mit original Gluon Repo): 
git clone git@git.hack-hro.de:opennet-initiative/gluon.git
cd gluon
#sync Opennet Gluon repo with remote (Gluon) respository
git remote add upstream https://github.com/freifunk-gluon/gluon.git
git remote -v
git fetch upstream
git checkout master
git merge upstream/master
git push


IP Adressen (evtl. veraltet)
2001:67c:1400:2430::1/60 (von IN-BERLIN) - für Server gai
fd32:d8d3:87da::/48 - ONI ULA

/home/christoph/babeld.conf
redistribute local ip fd32:d8d3:87da::245/128 allow
redistribute ip 2001:67c:1400:243f::1/128 deny
redistribute ip 2001:67c:1400:243f::/64 eq 128 allow
redistribute ip fd32:d8d3:87da:bab1::/64 eq 128 allow

Client:  2001:67c:1400:243f:3e97:eff:fe6c:42b3/64

Martin:  2001:67c:1400:243f:3e97:eff:fe6c:42b3/64
DNS64/NAT64
  • DNS64 Docker Container auf gai
  • NAT64 (tayga) Container auf gai (siehe für Config User:leo/tayga)
    • MTU Probleme beim NAT64. Aus dem Internet werden große IPv4 Pakete (>1380) geschickt. Nach der IPv4-zu-IPv6 Übersetzung müssen sie durch den fastd VPN Tunnel geschickt werden. Der VPN Tunnel hat aber nur eine MTU von 1380. Ein größeres Paket wird mit ICMP frag-needed abgewiesen. Diese ICMP Meldung wird zum NAT64 GW geschickt. Leider kommt diese ICMP Meldung nicht bis in Internet. Man sieht das ICMP Paket noch auf dem tayga nat64 Interface aber danach "verschwindet" es.

TODO:

Nächsten Schritte

Folgende Features sollten wir auch Testen um uns im klaren über die weitere Entwicklung zu sein.

Hauptunterschiede zwischen Opennet Firmware (2020) und Gluon+Babel

Konzeptionell:

  • User-VPN Tunnel
    • Opennet: Mesh Knoten von Entnutzern bauen einen VPN Tunnel (mit Zertifikat) zum Internet Gateway auf. Abhängig davon, erhält der Knoten (und Endgeräte) Internetzugriff. Opennet bietet hier mehr Sicherheit/Privatheit auf dem Transportweg durch das Mesh.
    • Gluon: In Gluon ist dieses Konzept nicht vorgesehen. Alle Clients haben vollen Zugriff auf das Internet.
  • Roaming
    • Opennet: Feature ist nicht vorgesehen by Design
    • Gluon: mittels l3roamd realisiert. Als Nebeneffekt sind die IPs aller Endgeräte jedem Knoten bekannt. Es gibt nur einen Address-Pool.
  • Weboberfläche
    • Opennet: Umfangreiche Konfigurationsmöglichkeiten für Opennet spezifische Funktionen. Die OpenWRT Oberfläche ist auch weiterhin verfügbar.
    • Gluon: Sehr stark reduziert auf sehr wenige Funktionen.
  • Wifi Konfiguration
    • Opennet: ...
    • Babel: ...

Technisch:

  • L3 Routing Protokoll
    • Opennet: OLSR1 (IPv4), OLSR2 (IPv6)
    • Gluon: Babel
  • VPN Software
    • Opennet: OpenVPN mit tap und tun interfaces
    • Gluon: fastd, tunneldigger, wireguard (in Arbeit), ...

Mögliche Migrationsszenarien

  • L3 Routingprotokoll
    • hier muss von OLSR2 nach Babel gewechselt werden. Das beiden IPv6 only sind, könnte man diese 1:1 austauschen. Es wäre denkbar eine "alte" Opennet Firmware zu bauen, welche anstatt OLSR2 dann Babel unterstützt. Diese Firmware könnte man dann auf den Backbone APs einspielen. Somit wäre im Backbone Babel unterstützt.
  • VPN?

Laborbuch - Fortschritte und Erkenntnisse

24.02.2021

Server:

  • auf Server itsuki wurde diese Woche fastd,babeld,l3roamd,mmfd installiert und konfiguriert (siehe Doku in /root/*). Bisher wurde die Babel-Tests auf dem Server gai durchgeführt. Hier soll aber saubergetrennt werden. Der Server itsuki ist ausschließlich für diese Tests nur verfügbar.

Firmware:

Tests:

  • Firmware auf WDR4300 Router installiert.
  • Client am Router bekommt fd02::2/64 als IP. Warum diese IP? Es gibt aber keinerlei IP aus dem Adressbereich der site.conf. Warum nicht?
  • SSH zum AP nur über Link Local möglich: 
 ssh fe80::1441:95ff:fe40:f7dc%enp53s0 -l root
  • Das fd02::/64 ist auf AP (fd02::1) und Client (fd02::2) konfiguriert, jedoch erreich der Client den AP hierüber nicht (AP antwortet nicht auf ping oder ssh). Ist vielleicht so gewollt?
  • VPN Verbindung mit fastd erfolgreich aufgebaut
  • Babel: auf AP ist route zu itsuki zu sehen und damit funktioniert auch Babel: 
 root@c4e9847de44a:~# ip -6 route show table all | grep 244
 fd32:d8d3:87da:bab1::244 via fe80::14d5:80ff:fe2b:3606 dev mesh-vpn  src fd32:d8d3:87da:bab1:c6e9:84ff:fe7d:e44a  metric 96
  • Ping vom AP zu itsuki läuft hat(te) komisches Verhalten. Erst nach 160 Pings ohne Antwort, kam dann plötzlich eine Antwort zurück und dann auch dauerhaft. Ich hatte kurz vorher ein tcpdump auf itsuki gemacht, um das Problem zu untersuchen. Ob beides zusammenhängt? Jedenfalls scheint jetzt der Ping zu funktionieren: 
 10:32:18.500191 IP6 fd32:d8d3:87da:bab1:c6e9:84ff:fe7d:e44a > fd32:d8d3:87da:bab1::244: ICMP6, echo request, seq 213, length 64
 10:32:18.500254 IP6 fd32:d8d3:87da:bab1::244 > fd32:d8d3:87da:bab1:c6e9:84ff:fe7d:e44a: ICMP6, echo reply, seq 213, length 64
  • Alle erreichbaren Babel Clients sind bspw. zu finden via: 
 root@itsuki:~# ip -6 route show table 10
 fd32:d8d3:87da:bab1:c6e9:84ff:fe7d:e44a via fe80::dcc6:50ff:fef2:2f3f dev babel-vpn proto babel metric 96 onlink pref medium
 fd32:d8d3:87da:bab2:82fa:5bff:fe8a:7eac via fe80::dcc6:50ff:fef2:2f3f dev babel-vpn proto babel metric 96 onlink pref medium
 fd32:d8d3:87da:bab2::/64 dev l3roam0 metric 1024 pref medium
Von „http://wiki.opennet-initiative.de/w/index.php?title=Gluon_Babel_Firmware_Test&oldid=36695“
Meine Werkzeuge
Namensräume

Varianten
Aktionen
Start
Opennet
Kommunikation
Karten
Werkzeuge