 |
Opennet Firmware
|
|
Opennet Firmware
|
Auf jedem AP wird eine Datenbank von Diensten gepflegt. Die typische Quelle fuer diese Datenbank ist der olsrd-Nameservice.
Die Dienste werden mittels eines olsrd-nameservice-Trigger-Skripts aktualisiert (/etc/olsrd/nameservice.d/on_update_services). Dieses Trigger-Skript setzt eine Markierungsdatei, deren Existenz durch einen minütlichen cronjob geprüft wird. Sofern die Datei existiert, wird einmalig die Service-Aktualisierung durchgeführt.
Die Aktion des Trigger-Skripts lässt sich manuell auslösen:
on-function update_olsr_services
Die Ergebnisse der Dienst-Suche werden im Dateisystem gespeichert. Langfristig unveraenderliche Attribute eines Dienstes (z.B. der Host und der Port) werden persistent gespeichert - die übrigen Informationen (z.B. die Routing-Entfernung) liegen lediglich im tmpfs und werden bei jedem Neustart erneut gesammelt.
Die Details zur Datenablage sind unter Datenspeicherung zu finden.
Die menschenfreundliche Zusammenfassung aller Dienst-Informationen ist recht übersichtlich:
on-function print_services
Dienste werden durch einen eindeutigen Namen (zusammengesetzt aus URL, Schema, Hostname, Port, usw.) referenziert. Dieser eindeutige Namen wird von allen Dienst-relevanten Funktionen verwendet.
Wenn mehrere Anbieter eines Dienstes zur Verfügung stehen, dann muss eine automatisierte Entscheidung getroffen werden, welcher davon zu verwenden ist. Derzeit stehen drei Methoden zur Verfügung, von denen eine über die Konfigurationseinstellung on-core.settings.service_sorting ausgewählt wird:
olsrd als Routing-Metrik verwendet wird (dies ist die Standard-Sortierung)Alle DNS-Server verteilen via olsrd-nameservice-Plugin einen Eintrag ähnlich dem folgenden:
dns://192.168.0.247:53|udp|dns
Die folgenden Voraussetzungen müssen von DNS-Servern im Opennet erfüllt werden:
nameservice die URL des DNS-ServersDer entsprechende nameservice-Block in der olsrd.conf des DNS-Servers kann folgendermaßen aussehen:
LoadPlugin "olsrd_nameservice.so.0.3"
{
PlParam "service" "dns://192.168.0.247:53|udp|dns"
}
Wichtig: Die angegebene IP muss unbedingt auf einem der von olsr verwalteten Netzwerk-Interfaces konfiguriert sein. Andernfalls wird das nameservice-Plugin stillschweigend die Verteilung unterlassen. In der /var/run/services_olsr auf dem Host ist sofort zu erkennen, ob der Dienst-Eintrag verteilt wird.
Das Skript /etc/olsrd/nameservice.d/on_update_services wird bei jeder Änderung der olsrd-Nameservice-Announcements aufgerufen und überträgt alle Dienst-Informationen in die lokale Datenbank. Im Anschluss wird apply_changes on-core aufgerufen. Dies löst die Aktualisierung der dnsmasq-Nameserver-Datei (/var/run/dnsmasq.servers) basierend auf der Dienstliste aus.
In diesem Verlauf wird auch sichergestellt, dass die uci-Variable dhcp.@dnsmasq[0].serversfile gesetzt ist. Falls dies nicht der Fall ist, wird die Datei /var/run/dnsmasq.servers eingetragen. Abschließend wird dem dnsmasq-Prozess ein HUP-Signal gesendet, um ein erneutes Einlesen der Konfigurationsdateien auszulösen.
Folgende Voraussetzungen müssen gegeben sein:
dnsmasq läuftnameservice ist aktiviertdnsmasq-init-Skript ist gepatcht, um die servers-file-Option zu beachtenAlle NTP-Server verteilen via olsrd-nameservice-Plugin einen Eintrag ähnlich dem folgenden:
ntp://192.168.0.247:123|udp|ntp
//analog zur Konfiguration der DNS-Anbieter//
Das Skript /etc/olsrd/nameservice.d/on_update_services wird bei jeder Änderung der olsrd-Nameservice-Announcements aufgerufen und überträgt alle Dienst-Informationen in die lokale Datenbank. Im Anschluss wird apply_changes on-core aufgerufen. Dies löst die Aktualisierung der NTP-Server-Liste in der uci-Konfiguration (system.ntp.server) aus.
Im Falle von Änderungen der Server-Liste wird diese in die uci-Variable system.ntp.server übertragen. Anschließend wird der ntp-Dienst neugestartet.
Das Skript /etc/olsrd/nameservice.d/on_update_services wird bei jeder Änderung der olsrd-Nameservice-Announcements aufgerufen und überträgt alle Dienst-Informationen in die lokale Datenbank. Minütlich wird via cronjob die Datei /usr/sbin/on_vpngateway_check ausgeführt. Dieser führt folgende Aktionen aus:
Falls der minütliche cronjob feststellt, dass ein besserer Gateway als der aktuell verwendete vorhanden ist, dann schreibt er das Attribute switch_candidate_timestamp in diesen neuen Dienst. Sobald dieser Zeitstempel im Verlaufe nachfolgender cronjob-Läufe älter als fünf Minuten ist, wird der neue Gateway via select_mig_connection aktiviert und eine Verbindung aufgebaut.
Sollte die Verbindung zum aktuellen Gateway abreissen, muss der Gateway als unbrauchbar markiert werden und ein Wechsel zu einem anderen Gateway ist sinnvoll. Dies wird folgendermaßen erreicht:
keepalive die Regeln ping 10 und pin-restart 120. Somit wird nach ca. zwei Minuten Ausfall ein Neustart der Verbindung von Client-Seite ausgeführt.persist-tun-Option zur Ausführung des down-Skripts, In diesem Skript wird der Status der aktuellen OpenVPN-Verbindung als 'n' gesetzt. Somit wird bei der nächsten Prüfung eines Gateway-Wechsels ohne Verzögerung ein alternativer Gateway gewählt.explicit-exit-notify muss abgeschaltet sein, da andernfalls der Grund des Endes der Verbindung im down-Skript nicht erkennbar ist (die Status-Variable signal wird von explicit-exit-notify überschrieben).Für jeden Gateway werden dauerhafte und wechselhafte Eigenschaften gespeichert.
Die folgenden Attribute sind persistent (siehe on-core/files/usr/lib/opennet/services.sh):
Alle übrigen Attribute unterliegen lediglich der volatilen Speicherung.
Die persistenten Informationen liegen unter /etc/on-services.d.
Die volatilen Informationen liegen unter /tmp/on-services-volatile.d.
Internet-Spender betreiben APs, die im Wesentlichen die beiden folgenden Aufgaben erfüllen:
Die mesh-Verbindung wird mittels einer oder mehrerer openvpn-Verbindungen zu verschiedenen Mesh-Gateways aufgebaut. Die Dienst-Durchleitung erfolgt mittel Portweiterleitungen verbunden mit olsrd-nameservice-Announcements.
Für jeden externen Gateway werden dauerhafte und wechselhafte Eigenschaften gespeichert.
Die Eigenschaften von Gateway-Diensten werden durch die Dienstverwaltung gespeichert. Neben den für alle Dienste persistenten Informationen werden die folgenden UGW-spezifischen Informationen gespeichert:
Zu allen UGWs wird in der UGW-Übersicht eine Abschätzung der Upload- und Download-Bandbreite angezeigt. Diese wird durch den Download von der URL http://UGW_HOSTNAME/.big und den Upload via netcat zu Port 2222 auf dem UGW-Host ermittelt.
Die Geschwindigkeiten werden nach jeder Messung mit den vorherigen Werten gemittelt gespeichert. Änderungen setzen sich also nur langsam durch.
Diese Prüfung wird im Tagestakt innerhalb der ugw-Funktion ugw_doExtraChecks durchgeführt.
Konfiguration des UGW-Servers:
Betrieb eines netcat-Listeners:
iptables -I INPUT -p tcp –dport 22222 -j ACCEPT
(while true; do nc -l -n -p 22222 -q 0 2>&1 >/dev/null; sleep 2; done) &
Die UGW-Server bieten üblicherweise zwei Dienste an:
Beide Dienste sind über ihre öffentlichen IPs erreichbar. Daher ist eine Announcierung via olsrd-nameservice nicht umsetzbar. Somit verwenden wir stattdessen die Veröffentlichung via DNS-SRV (RFC 2782).
Die DNS-Namen für die beiden Dienste sind folgende:
_mesh-openvpn._udp.systemausfall.org_igw-openvpn._udp.systemausfall.orgBeispielhafte Einträge sind folgende:
root@foo:~# dig +short SRV _mesh-openvpn._udp.systemausfall.org 5 0 1602 erina.opennet-initiative.de. 5 0 1602 megumi.opennet-initiative.de. 5 0 1602 subaru.opennet-initiative.de. root@foo:~# dig +short SRV _igw-openvpn._udp.systemausfall.org 5 0 1600 megumi.opennet-initiative.de. 5 0 1600 subaru.opennet-initiative.de. 5 0 1600 erina.opennet-initiative.de.
Dabei wird die Priorität (1. Spalte des Ergebnis) für die Vorauswahl der automatisch zu nutzenden Anbietern beachtet. Diensteanbieter, die eventuell zu Überraschungen beim Nutzenden führen (z.B. ein Exit-Knoten im Ausland), sollten eine nachgelagerte Priorität (höherer Zahlenwert) tragen. Der Nutzer kann durch manuelle Interaktion auch Dienste nachgelagerter Priorität explizit zur Nutzung freigeben.
Die Gewichtung (2. Spalte) wird aktuell nicht für Mesh- oder Internetgateways verwendet.
Sowohl Port als auch Hostname werden für die Nutzung des Diensts verwendet.
Eine Beschreibung des Dienstanbieters (beispielsweise der Hosting-Standort: "Hetzner, Düsseldorf (Deutschland)") wird durch den TXT-Eintrag des dazugehörigen Dienstanbieters (siehe dig TXT erina.opennet-initiative.de) ausgeliefert.
Die ermittelten Dienst-Anbieter werden durch die Dienste-Verwaltung gespeichert. Darin werden alle für den Verbindungsaufbau notwendigen Daten abgelegt.
Jeder weiterzuleitende Dienst stellt eine Belastung für die Internet-Spender dar. Daher dürften diese Announcierungen nicht via olsrd erfolgen, um eine unerwünschte Nutzung der Internetfreigabe durch triviale olsr-Announcements zu verhindern.
Stattdesen erfolgt die Announcierung mittels der unter administrativer Kontrolle stehenden Opennet-Domain in Form von DNS-SRV-Einträgen.
Die DNS-Einträge werden regelmäßig abgefragt und in lokale Dienstbeschreibungen verwandelt. Anhand der Dienst-Einträge werden die Port-Weiterleitungen und die olsr-nameservice-Announcierungen erstellt.
Folgende Dienste werden weitergereicht:
Es werden nur diejenigen Dienste weitergereicht und announciert, die den folgenden Bedingungen genügen:
Das //ondataservice//-Plugin verteilt via //olsrd// detaillierte Informationen über den AP im Netz.
Das Initialisierungsskript /etc/uci-defaults/on-olsr-setup wird bei der Erstinstallation oder beim Firmware-Upgrade ausgeführt. Es aktiviert da ondataservice-Plugin.
Das Plugin versendet standardmäßig im 3-Stunden-Takt olsr-Message-Pakete (Message-ID=222). Diese lassen sich auf dem AP mit tcpdump beobachten:
tcpdump -vvvlnpi wlan0 port 698 | grep -A 5 "(0xde)"
Zur detaillierten Beobachtung kann es hilfreich sein, den Versand-Intervall (kurzzeitig) zu reduzieren (siehe interval in der ondataservice_light-Konfiguration in */etc/config/olsrd*).
Im [https://wiki.opennet-initiative.de/wiki/Firmware_Status](Wiki) findest du einige Stunden später deinen AP aufgeführt. Dort findest du auch APs mit alter Firmware, sofern sie von der Kompatibilitätsschnittstelle unseres Datensammlers geronimo erfasst werden.
Nach einer frischen Installation, sowie im Anschluss an ein Firmware-Upgrade wird eine Reihe von Skripten zur Initialisierung ausgeführt. Openwrt stellt hierfür den //uci-defaults//-Mechanismus bereit:
http://wiki.openwrt.org/doc/uci#defaults
Für alle Aktivitäten, die nach der Installation oder einem Upgrade notwendig sind, existieren in den Opennet-Paketen Dateien unterhalb von /usr/lib/opennet/init/. Diese Skripte werden als Symlink unter /etc/uci-defaults/ bereitgestellt. Nach dem Booten prüft ein openwrt-init-Skript, ob sich Dateien unterhalb von /etc/uci-defaults/ befindet. Jede aufgefundene Datei wird ausgeführt und bei Erfolg anschließend gelöscht.
Die Existenz einer Datei in diesem Verzeichnis deutet also auf ein Konfigurationsproblem hin, das gelöst werden sollte.
Das Skript /etc/uci-defaults/on-configure-network prüft, ob der uci-Wert on-core.settings.default_ip_configured gesetzt ist. Sollte dies nicht der Fall sein, dann wird die IP-Adresse aus der //on-core//-Defaults-Datei ausgelesen und konfiguriert. Anschließend wird das obige uci-Flag gesetzt, um eine erneute Konfiguration anch einem Update zu verhindern.
Relevante Vorgänge (Booten, OLSR-Neustarts) werden im Ereignislog (/etc/banner) festgehalten.
../packages/on-core/files/etc/cron.minutely/on_log_restart_timestamp
Um den korrekten Zeitstempel für das Boot-Ereignis sicherzustellen prüft das obige Skript zuerst, ob es eine Verbindung mit NTP-Servern (siehe #ntp) aufbauen kann. Bei Erfolg wird eine Datei erzeugt (*/var/run/on_boot_time_logged*). Die Existenz dieser Datei sorgt bei allen weiteren Ausführungen für ein sofortiges Ende des Skripts.
Jedes Skript und jede Funktionalität lässt sich folgendermaßen im Detail debuggen:
ON_DEBUG=1 on_usergateway_check
Im Paket on-core befindet sich eine Datei etc/init.d/on_config. Beim Booten wird check_firmware_upgrade durchgeführt und anschließend die Opennet-Erstkonfiguration gesetzt, falls kein Netzwerkinterface mit dem Präfix "on_" existiert.
check_firmware_upgrade:
opkg status on-core ausgelesenOpennet-Erstkonfiguration:
Im Paket on-core befindet sich eine Datei etc/init.d/ntpclient. Beim Start sorgt sie dafür, dass alle konfigurierten NTP-Server (ntpclient.@ntpserver[..]) nacheinander im 3-Sekunden-Takt angefragt werden. Sobald eine eine Verbindung hergestellt wurde, wird der (nur korrekt ermittelte) Boot-Zeitpunkt in die banner-Datei geschrieben.
Als NTP-Server sind derzeit (via */etc/config_presets/ntpclient*) folgende konfiguriert:
Im Paket on-openvpn wird mittels des Skripts on-openvpn/files/usr/bin/on_vpngateway_check mit der Funktion update_dns_from_gws die Liste der DNS-Server in */tmp/resolv.conf.auto* gepflegt.
Im Paket on-core ist die olsrd-Konfiguration enthalten, die zum Laden des ondataservice-Plugin führt. Außerdem ist ein täglicher cronjob (usr/sbin/status_values.sh) enthalten, der bei Bedarf die sqlite-Datenbank anlegt und die Datensatz-Datei aktualisiert.
Im Paket on-core ist ein minütlicher cron-job enthalten, der prüft, ob ein olsrd-Prozess läuft und ihn notfalls neu startet.
Beim Booten kann es dazu kommen, dass das oder die olsrd-Interfaces noch nicht aktiviert sind. In diesem Fall beendet sich olsrd mit der Fehlermeldung "Warning: Interface 'on_wifi_0' not found, skipped". Aufgrund des minütlichen cronjobs wird olsrd innerhalb von einer Minute trotzdem gestartet.
Im Paket on-core ist eine Datei etc/crontabs/root enthalten, die im groben folgendem Patch folgt: https://dev.openwrt.org/ticket/1328
Die Zonen-Konfiguration von openwrt wird durch das Paket on-core von uns überschrieben.
Die Datei etc/firewall.opennet fügt anscheinend eine relevante Masquerade-Regel zu den üblichen Regeln hinzu, die mit den normalen uci-Regeln nicht nachgebildet werden kann.
Im Paket on-openvpn ist das config-preset on-openvpn enthalten, das konfigurierbar festlegt, ob alle Gateways als ntp- und DNS-Server verwendet werden sollen. Außerdem sind in diesem config_preset die Vorgaben für Nutzer-Zertifikate eingetragen.
Das config_preset openvpn überschreibt das Original des openvpn-Pakets.
Das lua-Skript /usr/lib/lua/luci/model/opennet/on_vpn_autosearch.lua wird via cron-Job im Minuten-Takt ausgeführt. Außerdem wird es beim Bearbeiten der Gateway-Einstellungen im Web-Interface gestartet. Seine Aufgabe ist die Neuberechnung der Wertigkeit aller erreichbaren Gateways, sowie die Sortierung der Gateway-Liste in den uci-Sektionen on-openvpn.gate_*.
Minütlich läuft ein cronjob (on_vpngateway_check), der folgendes tut:
TODO:
Im Paket on-usergw sind zwei VPN-Konfigurationen (opennet_ugw, opennet_vpntest) enthalten.
Außerdem ist ein Skript (/usr/sbin/on_usergateway_check) für folgende Funktionen in Verwendung:
Cronjob alle 5min:
Cronjob jeden Tag:
Konfiguration:
Die Datei /etc/config_presets/on-usergw enthält default Einstellungen für die SSL UGW Zertifkate, zwei Usergateway-Server (erina und subaru) sowie alle OpenVPN Einstellungen zum Verbinden zu den Servern.
Das allgemeine Wifidog-Konzept wird unter https://wiki.opennet-initiative.de/wiki/Projekt_Wifidog#DHCP-Ablauf_der_Wifidog-Implementierung beschrieben.
1.8.1.2