Pimp my Node: Unterschied zwischen den Versionen
Zeile 16: | Zeile 16: | ||
=== IPv6 ping === | === IPv6 ping === | ||
<pre> | <pre> | ||
ping6 <link local | ping6 <link local Adresse des Nodes>%eth0 | ||
</pre> | </pre> | ||
Zeile 22: | Zeile 22: | ||
Hinter der link local Adresse "%" + "Netzwerk Interface an eurer Kiste" (Hier im Beispiel eth0) | Hinter der link local Adresse "%" + "Netzwerk Interface an eurer Kiste" (Hier im Beispiel eth0) | ||
<pre> | <pre> | ||
ssh root@<link local | ssh root@<link local Adresse des Nodes>%eth0 | ||
</pre> | </pre> | ||
Zeile 46: | Zeile 46: | ||
Möchte man sich nicht immer per Paßwort auf den eigenen Node verbinden, so kann man das auch mit einem Schlüsselpaar realisieren. Falls man danach noch die Authentifizierung per Paßwort abschaltet (s. nächster Punkt), dann hat man einen sicheren Zugriff auf seinen Node realisiert. | Möchte man sich nicht immer per Paßwort auf den eigenen Node verbinden, so kann man das auch mit einem Schlüsselpaar realisieren. Falls man danach noch die Authentifizierung per Paßwort abschaltet (s. nächster Punkt), dann hat man einen sicheren Zugriff auf seinen Node realisiert. | ||
Voraussetzung ist natürlich, dass man schon ein gültiges Schlüsselpaar besitzt. Falls dem so ist, so genügt es, den öffentlichen Schlüssel (public key) auf den Node zu übertragen. Das kann mit Hilfe von scp (secure copy) passieren: | Voraussetzung ist natürlich, dass man schon ein gültiges Schlüsselpaar besitzt. Falls dem so ist, so genügt es, den öffentlichen Schlüssel (public key) auf den Node zu übertragen. Das kann mit Hilfe von scp (secure copy) passieren: | ||
<pre>scp | <pre>scp id_rsa.pub root@<link local Adresse des Nodes>%eth0:/etc/dropbear/authorized_keys</pre> | ||
Hierbei steht | Hierbei steht id_rsa.pub für die Datei, die den public key enthält. '''ACHTUNG:''' Obiger Befehl ersetzt die eventuell schon vorhandene Datei authorized_keys auf dem Node. Das ist ok für den ersten Key. Sollen mehrere Keys eingetragen werden (z. B. weil man außer vom Laptop auch vom Tablet auf seinen Node verbinden möchte), muß der zusätzliche Key per vi(m) auf dem Node direkt editiert werden. | ||
Auch hier werden die Änderungen nach einem Neustart des Routers mittels ''reboot'' übernommen. | Auch hier werden die Änderungen nach einem Neustart des Routers mittels ''reboot'' übernommen. | ||
Zeile 64: | Zeile 64: | ||
<pre> | <pre> | ||
ssh root@<link local | ssh root@<link local Adresse des Nodes>%eth0 // SSH Verbindung zum Node aufbauen | ||
cd ../tmp/ // in das Verzeichnis "tmp" wechseln | cd ../tmp/ // in das Verzeichnis "tmp" wechseln | ||
free // Freien Speicher prüfen | free // Freien Speicher prüfen | ||
Zeile 75: | Zeile 75: | ||
==== Node ohne uplink (mesh node) ==== | ==== Node ohne uplink (mesh node) ==== | ||
<pre> | <pre> | ||
scp -6 -v -r firmware.bin root@\[< | scp -6 -v -r firmware.bin root@\[<link local Adresse des Nodes>%eth0\]:../tmp/ // Firmware auf den node schieben (md5 checken!) | ||
ssh root@<link local | ssh root@<link local Adresse des Nodes>%eth0 | ||
cd ../tmp/ | cd ../tmp/ | ||
sysupgrade -v firmware.bin | sysupgrade -v firmware.bin |
Version vom 17. Januar 2015, 10:29 Uhr
Netztheorie/Technik und Entwicklung
Vertiefung
Arbeiten auf der Shell
Vorraussetzung für folgende Befehle sind eine Verbindung mit dem KBU Freifunk Netz sowie ein Terminal / Shell. Vergesst nicht eth0 gegen die Bezeichnung eures Netzwerkinterfaces, welches am Freifunk hängt zu tauschen. Bei Macbooks via Wlan z.B. "en1" statt "eth0"! Die link local Adresse der jeweiligen node findet ihr auf der KBU Register Seite. Um Dateien auf dem Node ändern zu können, steht als einziger Editor vi bzw. vim zur Verfügung.
IPv6 ping
ping6 <link local Adresse des Nodes>%eth0
IPv6 ssh
Hinter der link local Adresse "%" + "Netzwerk Interface an eurer Kiste" (Hier im Beispiel eth0)
ssh root@<link local Adresse des Nodes>%eth0
Hostnamen des Nodes ändern
Standardmäßig ist der Hostname des Nodes gleich der MAC-Adresse des Routers. Möchte man den Hostnamen ändern, so kann man dies in der Datei /etc/config/system. Hier gibt es gleich als ersten Punkt config system und dort findet man den Eintrag
option hostname 'aa:bb:cc:dd:ee:ff'
Hier kann man jetzt aa:bb:cc:dd:ee:ff (diese Adresse sieht bei jedem Node anders aus!) zu dem gewünschten Hostnamen ändern. Eine Änderung wird erst nach dem Kommando reboot (danach startet der Node neu) wirksam.
ntp-Bug in Firmware 1.2.1b beseitigen
Falls sich ein Node-Betreiber wundert, warum sein Node keine Statistiken liefert und es ein Mesh-Only-Node ist (d. h. ohne eigenen Uplink zum Internet), so liegt das an einem Bug in der Firmware. Diesen kann man jedoch mit einfachen Mitteln beheben: Editiert wird die Datei /etc/config/system. Dort findet man einen Eintrag config timeserver 'ntp'. Defaultmäßig stehen hier 4 Zeitserver von openwrt (in der Form x.openwrt.pool.ntp.org). Diese müssen bei Mesh-Only-Nodes in IPv6-Adressen geändert werden, und zwar, dass der komplette Konfigurationspunkt wie folgt aussieht:
config timeserver 'ntp' list server '2a03:4000:2:494::2' list server '2a01:4f8:161:2461:e4::1' list server '2a02:180:1:1::551f:bb4b' option enabled '1' option enable_server '0'
Auch hier werden die Änderungen erst nach einem Neustart des Nodes mittels reboot wirksam. Dieser Bug soll mit dem nächsten Firmware-Release behoben sein. Man kann die Eintragungen auch in den Nodes mit Internet-Uplink ändern ohne die Funktion zu beeinträchtigen.
public key auf Node aufspielen
Möchte man sich nicht immer per Paßwort auf den eigenen Node verbinden, so kann man das auch mit einem Schlüsselpaar realisieren. Falls man danach noch die Authentifizierung per Paßwort abschaltet (s. nächster Punkt), dann hat man einen sicheren Zugriff auf seinen Node realisiert. Voraussetzung ist natürlich, dass man schon ein gültiges Schlüsselpaar besitzt. Falls dem so ist, so genügt es, den öffentlichen Schlüssel (public key) auf den Node zu übertragen. Das kann mit Hilfe von scp (secure copy) passieren:
scp id_rsa.pub root@<link local Adresse des Nodes>%eth0:/etc/dropbear/authorized_keys
Hierbei steht id_rsa.pub für die Datei, die den public key enthält. ACHTUNG: Obiger Befehl ersetzt die eventuell schon vorhandene Datei authorized_keys auf dem Node. Das ist ok für den ersten Key. Sollen mehrere Keys eingetragen werden (z. B. weil man außer vom Laptop auch vom Tablet auf seinen Node verbinden möchte), muß der zusätzliche Key per vi(m) auf dem Node direkt editiert werden. Auch hier werden die Änderungen nach einem Neustart des Routers mittels reboot übernommen.
Paßwort-Authentifizierung abstellen
Wichtig: Als erstes prüfen, ob man sich mit seinem Schlüsselpaar auf den Router einloggen kann. Man sollte jetzt nicht mehr nach dem Paßwort gefragt werden (allerhöchstens nach dem Paßwort, welches den privaten Schlüssel schützt). Falls das erfolgreich funktioniert, kann man die Datei /etc/config/dropbear wie folgt ändern:
config dropbear option PasswordAuth 'off' option RootPasswordAuth 'off' option Port '22' # option BannerFile '/etc/banner'
Nach einem Neustart des Routers mittels reboot sollte es jetzt nur noch möglich sein, sich mit seinem Schlüsselpaar auf den Rotuer einzuloggen.
Firmware aktualisieren
Node mit uplink
ssh root@<link local Adresse des Nodes>%eth0 // SSH Verbindung zum Node aufbauen cd ../tmp/ // in das Verzeichnis "tmp" wechseln free // Freien Speicher prüfen wget http://pfad/zur/firmware.bin // Firmware herunterladen oder sysupgrade -v firmware.bin // Firmwareupgrade durchführen
Achtung: Beim Download der Firmware via wget kann auf dem Router die Integrität der Firmware nicht geprüft werden, da gpg i.d.R. auf den Routern nicht verfügbar ist. Deshalb ist es sicherer, den oben beschriebenen Weg zu wählen, oder die geprüfte Firmware per scp (s.u.) auf den Router zu kopieren.
Node ohne uplink (mesh node)
scp -6 -v -r firmware.bin root@\[<link local Adresse des Nodes>%eth0\]:../tmp/ // Firmware auf den node schieben (md5 checken!) ssh root@<link local Adresse des Nodes>%eth0 cd ../tmp/ sysupgrade -v firmware.bin
LAN Kopplung
Eine LAN Kopplung kann in manchen Fällen sinnvoll sein, besonders wenn man einen VLAN fähigen Switch und eine bestehende Ntzwerkverkabelung hat. Hier werden die Switchports angwiesen auch über LAN zu meshen.
TL-WR841ND
03/2014: Hier wird über die alle 4 LAN Ports gemeshed, Mesh über WLAN kann man optional noch ausschalten! Folgende Config stammt von rampone/FF-KBU und wurde an 2 TL-WR841N v.8 getestet mit KBU-FF-Firmware 1.1.
vim /etc/config/network - Folgende Änderungen wurden an der FF-Firmware 1.0 vorgenommen:
- config interface 'freifunk' -> Hier haben wir eth0 aus "ifname" rausgenommen, damit kein ff aus dem eth0 (switch) rauskommt.
- config interface 'mesh_lan' -> kompl. codeblock hinzugefügt, dieser bewirkt das über eth0 (switch) gemeshed wird.
config interface 'loopback' option ifname 'lo' option proto 'static' option ipaddr '127.0.0.1' option netmask '255.0.0.0' config interface 'wan' option ifname 'eth0' option proto 'dhcp' option type 'bridge' option accept_ra '0' option auto '1' config switch option name 'switch0' option reset '1' option enable_vlan '1' config switch_vlan option device 'switch0' option vlan '1' option ports '0 1 2 3 4' config interface 'freifunk' option ifname 'bat0' #LAN-Kopplung: ifname eth1 entfernt option type 'bridge' option proto 'none' option auto '1' option accept_ra '1' option macaddr '10:fe:ed:f1:53:84' config interface 'mesh' option proto 'batadv' option mtu '1528' option mesh 'bat0' config interface 'mesh_vpn' option ifname 'mesh-vpn' option proto 'batadv' option mesh 'bat0' option macaddr '12:fe:ed:f2:53:84' config interface 'mesh_lan' #LAN-Kopplung: Codeblock mesh-lan hinzugefuegt option ifname 'eth1' option proto 'batadv' option mesh 'bat0'
vim /etc/config/wireless - Hier wird der Codeblock, der für das Mesh über WLAN verantwortlich ist auskommentiert (optional)
#config wifi-iface 'wifi_mesh' # option device 'radio0' # option network 'mesh' # option mode 'adhoc' # option ssid '02:d1:11:37:fc:39' # option bssid '02:d1:11:37:fc:39
TL-WDR4300
Das gleiche nochmal für den 4300er
vim /etc/config/network
config interface 'loopback' option ifname 'lo' option proto 'static' option ipaddr '127.0.0.1' option netmask '255.0.0.0' config interface 'wan' option ifname 'eth0.2' option proto 'dhcp' option type 'bridge' option accept_ra '0' option auto '1' option macaddr 'a2:f3:c1:65:81:cd' config switch option name 'eth0' option reset '1' option enable_vlan '1' config switch_vlan option device 'eth0' option vlan '1' option ports '0t 2 3 4 5' config switch_vlan option device 'eth0' option vlan '2' option ports '0t 1' config interface 'freifunk' option ifname 'bat0' #LAN-Kopplung: ifname eth0.1 entfernt option type 'bridge' option proto 'none' option auto '1' option accept_ra '1' option macaddr 'a0:f3:c1:64:81:cc' config interface 'mesh' option proto 'batadv' option mtu '1528' option mesh 'bat0' config interface 'mesh_vpn' option ifname 'mesh-vpn' option proto 'batadv' option mesh 'bat0' option macaddr 'a2:f3:c1:65:81:cc' config interface 'mesh_lan' #LAN-Kopplung: Codeblock mesh-lan hinzugefuegt option ifname 'eth0.1' option proto 'batadv' option mesh 'bat0'
Einsperren des Freifunk-Routers in eine DMZ
Wer seinen Freifunk-Router einsperren und/oder die Bandbreite begrenzen möchte, kann dies am einfachsten tun, indem er ihn an seiner Firewall an einen eigenen Netzwerkport klemmt und diesen dann als DMZ konfiguriert. Ein KBU-Freifunk-Router muß zur Zeit im LAN DHCP, DNS, im Internet NTP sowie mit den fastd-Knoten reden können. Folgendes Bespiel für eine iptables-Firewall nimmt an, dass der Freifunk-Router über eth2 angeschlossen ist:
# eth2 darf nur dns, ntp, dhcp und ansonsten mit den fastdX reden iptables -i eth2 -A INPUT -p udp --dport 67:68 --sport 67:68 -j ACCEPT iptables -i eth2 -A FORWARD -p udp --dport 67:68 --sport 67:68 -j ACCEPT iptables -i eth2 -A INPUT -p udp --dport 53 -j ACCEPT iptables -i eth2 -A INPUT -p tcp --dport 53 -j ACCEPT iptables -i eth2 -A INPUT -p tcp --dport 123 -j ACCEPT iptables -i eth2 -A FORWARD -p udp --dport 53 -j ACCEPT iptables -i eth2 -A FORWARD -p tcp --dport 53 -j ACCEPT iptables -i eth2 -A FORWARD -p tcp --dport 123 -j ACCEPT iptables -i eth2 -A FORWARD --dst 176.9.41.253 -j ACCEPT iptables -i eth2 -A FORWARD --src 176.9.41.253 -j ACCEPT iptables -i eth2 -A FORWARD --dst 178.63.59.41 -j ACCEPT iptables -i eth2 -A FORWARD --src 178.63.59.41 -j ACCEPT iptables -i eth2 -A FORWARD --dst 37.120.169.214 -j ACCEPT iptables -i eth2 -A FORWARD --src 37.120.169.214 -j ACCEPT iptables -i eth2 -A FORWARD --dst 37.221.195.47 -j ACCEPT iptables -i eth2 -A FORWARD --src 37.221.195.47 -j ACCEPT iptables -i eth2 -A FORWARD --dst 78.46.68.75 -j ACCEPT iptables -i eth2 -A FORWARD --src 78.46.68.75 -j ACCEPT iptables -i eth2 -A FORWARD --dst 84.201.35.206 -j ACCEPT iptables -i eth2 -A FORWARD --src 84.201.35.206 -j ACCEPT iptables -i eth2 -A INPUT -j DROP iptables -i eth2 -A FORWARD -j DROP # eth2 darf maximal 2000 kbit/s ein- und ausgehenden traffic machen wondershaper eth2 2000 2000
Prinzipiell könnte man den Traffic noch weiter einschränken. DHCP und DNS müssen nur zum DHCP- bzw. DNS-Server funktionieren und der Traffic zu den fastd-Servern ließe sich auf TCP Port 80 und UDP Port 10000 begrenzen.