 |
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 aktiviertUm die Privatsphäre der Nutzenden hinter einem VPN-Nutzertunnel zu schützen, werden DNS-Anfragen ausschließlich an die vom OpenVPN-Server announcierten DNS-Server gerichtet. Typischerweise sollte der OpenVPN-Server also nur seine eigene Tunnel-IP angeben, um sicherzustellen, dass DNS-Anfragen immer durch den Tunnel gesandt werden.
Die Umsetzung dieser DNS-Ausnahmesituation (im Vergleich zur obigen Darstellung) ist folgende:
Alle 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/mig_gateway_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:
Upload: 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 in Form einer csv-Datei, die via HTTP von einem Opennet-Server bereitgestellt wird:
[https://service-discovery.opennet-initiative.de/ugw-services.csv](Auflistung aller Gateway- und Mesh-Server)
Die Spalten werden durch Tabulatoren getrennt (keine Leerzeichen).
Die erste Spalte enthält den Dienst-Typ (z.B. "mesh" oder "dns"). Falls der Dienst-Type mit dem Präfix "proxy-" beginnt, gilt er als weiterleitungsfähig. Er soll also nicht direkt verwendet, sondern lediglich weitergeleitet werden.
Die zweite Spalte enthält das Dienst-Protokoll / die Anwendung (z.B. "openvpn").
Die dritte Spalte enthält den öffentlich erreichbaren DNS-Namen oder die IP des Hosts.
Die vierte Spalte enthält die Port-Nummer des Diensts.
Die fünfte Spalte enthält das Übertragungsprotokoll (udp/tcp - je nach Dienst).
Die sechste Spalte enthält die Priorität dieses Dienste-Anbieters (5 = üblich; kleinere Werte werden bevorzugt). Ungwöhnliche Dienste oder Dienste mit überraschenden Eigenschaften (z.B. Exit-Knoten im Ausland) sollten eine höhrere Zahl verwenden, damit sie nur durch bewusste Auswahl aktiviert werden können.
Die siebente und die folgenden Spalten können zusätliche Dienst-Informationen enthalten (z.B. "location").
Dabei wird die Priorität (1. Spalte des Ergebnis) für die Vorauswahl der automatisch zu nutzenden Anbietern beachtet.
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. Somit verwenden wir stattdessen eine csv-Datei, die via HTTP von einem Opennet-Server bereitgestellt wird (#ugw-server-list).
Es werden nur diejenigen Dienste weitergereicht und announciert, die den folgenden Bedingungen genügen:
Internet-Spender möchten eventuell zeitgleich mit dem Einspeisen auch einen lokalen Nutzer-Tunnel aufbauen (Internetzugang über Opennet-Server). Dies ist insbesondere für folgende Anwendungsfälle sinnvoll:
Beim gleichzeitigen Betrieb ist sicherzustellen, dass die Mesh-VPN-Tunnel (deren Gegenstellen öffentliche IPs haben) nie über den Nutzer-Tunnel hinweg aufgebaut werden. Außerdem dürfen Service-Relay-Portweiterleitungen nicht über den Nutzer-Tunnel verlaufen.
Eine Zuordnung der Verkehrsarten für diese Routing-Ausnahmen ist komplex. Daher wird die Markierung via Firewall-Regeln in Form der Zuweisung von TOS-Markierungen (Type of Service) umgesetzt.
Ein Skript (on-usergw/files/etc/on-firewall.d/mesh-vpn) sorgt für die Erstellung von Firewall-Regeln, die die TOS-Markierungen an allen lokal erzeugten oder via Service-Relay umgeleiteten Paketen anbringen, die die passende IP/Port-Kombination ansprechen wollen. Eine vom Paket on-openvpn erzeugte throw-Route in der Policy-Routing-Tabelle on-tunnel sorgt dafür, dass diese Tabelle für die obigen markierten Pakete nicht verwendbar ist. Das Skript wird auch im Rahmen jedes Firewall-Reloads ausgeführt (
Offene Zugangspunkte stellen ihrer Umgebung Zugang zum Internet zur Verfügung. Verkehr wird dabei erst nach dem ersten Aufbau einer http-Verbindung durchgelassen. Dies ermöglicht uns die einmalige Einblendung einer Portal-Webseite.
Jeder offene Zugangspunkt trägt ein VPN-Zertifikat, mittels dessen er eine Verbindung zum Internet aufbaut.
Verkehr aus dem offenen Interface wird ausschließlich in das VPN-Tunnel-Interface geroutet. Verkehr in das Opennet-Mesh wird blockiert.
Die Funktionalität wird mittels des Pakets on-captive-portal bereitgestellt.
Der hotplug-Trigger */etc/hotplug.d/iface/on-captive-portal-hotplug.sh* reagiert auf die folgenden Ereignisse:
Somit folgt die offene Netzwerk-Schnittstelle dem Status des VPN-Tunnels: bei abgeschaltetem Tunnel-Interface ist das offene Netzwerk-Interface nicht sichtbar.
Die leichtgewichtige captive-portal-Software nodogsplash wird verwendet. Sie erfüllt folgende Aufgaben:
nodogsplash fügt eine Regel zu Beginn der folgenden iptables-Chains ein:
Diese Regel verweist jeweils auf die passende iptables-Chain, die von nodogsplash verwaltet wird. Damit die obigen Regeln bei jeder Neukonfiguration der openwrt-Firewall vorhanden sind, wird bei jedem Reload der Firewall-Konfiguration nodogsplash neugestartet (siehe */usr/lib/opennet/events/on-captive-portal-firewall-reload.sh*). Die Integration dieses Skripts in die openwrt-Firewall-Konfiguration erfolgt mit Hilfe der Funktion configure_captive_portal_firewall_script im Rahmen der uci-defaults-Initialisierung. Bei diesem Vorgang gehen bestehende Client-Authentifikationen verloren - da die Authentifikation aber sehr schmerzfrei ist, dürfte dieses seltene Ereignis kein Problem darstellen.
Falls die nodogsplash-Firewall-Regeln fehlen, dann ist ein direkter Zugang zum VPN-Tunnel möglich (ohne Anzeige der Portal-Seite). Dies ist unerwünscht, aber nicht kritisch.
Der Zugang ins Mesh-Netz ist für Clients aufgrund der Firewall-Policy (unabhängig von nodogsplash) nicht zulässig.
Im Unterschied zur wifidog-basierten Implementierung (bis v0.4-5) ist die nahtlose Übergabe eines Clients an einen anderen offenen Zugangspunkt nicht möglich, da die DHCP-Leases und die Authentifikationszustände nur lokal am AP der Anmeldung vorliegen. Bei einem Netzwechsel wird also erneut die Portal-Seite präsentiert.
Das on-captive-portal-Paket hängt von muninlite ab. Aktuell sind die Installationen offener Zugangspunkte typischerweise keine privaten APs sondern werden vom Verein betrieben - daher dürfte sich aus der statistischen Erfassung (gesamter Netzwerkvehr und Anzahl der Clients am Zugangspunkt im Zeitverlauf) kein Datenschutzproblem ergeben. Der muninlite-Dienst kann bei Bedarf abgeschaltet werden.
Die Speicherung und Visualisierung der munin-Daten erfolgt auf einem separaten munin-Server (z.B. yurika).
Auf dem AP sind folgende Aktionen bei der Fehlersuche eventuell hilfreich:
ndsctl status: Anzeige des nodogsplash-Status (Konfiguration, Clients, Statistik)on-function get_devices_of_interface on_free: Auflistung der Netzwerkschnittstellen, die der Zone on_free zugeordnet sindsync_captive_portal_state_with_mig_connections: zwangsweise Angleichung des Netzwerk-Interface-Zustands (up/down) für on_free an die VPN-Tunnel-Schnittstelle (anschließend sollten beide aktiv oder beide inaktiv sein)iptables -L | grep nds: Vorhandensein von nodogsplash-Firewall-Regeln prüfen (keine Regeln -> freier Zugang ohne Portalseite)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 im Verlauf des nächstes Tages 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.
Die Firmware wird mit einer Original-openwrt-Repository-Datei (*/etc/opkg.conf*) erstellt. Im Zuge der uci-defaults-Initialisierung (nach der Erst-Installation oder nach einem Firmware-Upgrade) wird das Opennet-Repository hinzugefügt, z.B.:
src/gz opennet http://downloads.on/openwrt/stable/0.5.1/ar71xx/packages/opennet
Siehe dazu die Datei */etc/uci-defaults/10-on-core-init* und die Funktion set_opkg_download_version.
Am Ende des Boot-Vorgangs werden alle Skripte, die sich im Verzeichnis */usr/lib/opennet/boot/* befinden, für die Ausführung beim nächsten minütlichen cron-Job angemeldet (siehe schedule_task). Einige dieser Skripte sollen nicht direkt nach dem Booten, sondern etwas verzögert gestartet werden. Diese Skripte sorgen ebenfalls durch schedule_task dafür, dass sie erneut ausgeführt werden, solange ihre Zeit noch nicht gekommen ist.
Relevante Vorgänge (Booten, OLSR-Neustarts) werden im Ereignislog (/etc/banner) festgehalten.
Um den korrekten Zeitstempel für das Boot-Ereignis sicherzustellen prüft das Skript ../packages/on-core/files/etc/cron.minutely/on_log_restart_timestamp "on_log_restart_timestamp" zuerst, ob es eine Verbindung mit NTP-Servern (siehe NTP - Zeitsynchronisation ) 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.
Die Opennet-CA-Zertifikate liegen im Verzeichnis */etc/ssl/certs/opennet-initiative.de*. Dies ist ein Unterverzeichnis des allgemein üblichen */etc/ssl/certs*-Verzeichnis. Die Separierung ermöglicht es bestimmten Anwendungen, ausschließlich Opennet-betriebenen Gegenstellen zu vertrauen (also beispielsweise nicht von der Telekom oder anderen verbreiteten CAs signierten Zertifikaten).
Alle Opennet-CA-Zertifikate liegen als einzelne Datei mit selbsterklärendem Dateinamen in dem obigen Verzeichnis. Die Dateinamen entsprechen dem Muster des CA-Bundles (siehe https://ca.opennet-initiative.de/ca.html) zuzüglich einer angehängten Jahreszahl der Erstellung.
Beim Bauen der Opennet-Pakete werden zusätzlich zu den Zertifikatsdatein in demselben Verzeichnis Symlinks erzeugt, die die effiziente Verfolgung von Vertrauensketten ermöglichen:
c_rehash /etc/ssl/certs/opennet-initiative.de
Somit entspricht das Verzeichnis den üblichen Konventionen, die von SSL-tauglichen Clients verwendet werden (typischerweise: capath-Parameter). OpenVPN ist bei Verwendung des capath-Parameters darauf angewiesen, dass aktuell gültige CRLs für alle notwendigen Zertifikate vorliegen. Andernfalls werden die dazugehörigen Zertifikate ignoriert und die Verbindung zur Gegenstelle abgelehnt.
Die OpenVPN-Clients auf den APs verwenden ein von der User-CA (bzw. von der UGW-CA) unterschriebenes Zertifikat. Die Clients nutzen die folgenden ssl-relevanten Optionen:
ca /etc/ssl/certs/opennet-initiative.de/opennet-server_bundle.pem ns-cert-type server
Es werden also alle Opennet-Server-Zertifikate akzeptiert, die von der Server-CA (oder der älteren root-CA) unterschrieben wurden.
Zur vereinfachten Übermittlung der Zertifikatsanfragen von Nutzern überträgt die AP-Firmware via curl das CSR zu https://ca.on/.
Curl wird dabei mit dem Parameter *–cacert=/etc/ssl/certs/opennet-initiative.de/opennet-server_bundle.pem* ausgeführt. Somit akzeptiert curl ausschließlich Gegenstellen, die von unserer Server-CA unterschrieben wurden. Verwendeten wir an dieser Stelle capath anstelle von cacert, dann würde curl auch unerwünschte Zertifikate (z.B. Nutzer-Zertifikate) akzeptieren.
Seit Version 0.5.2 sind alle CA-Zertifikate in dem separaten Paket on-certificates zusammengefasst. Teil dieses Pakets ist außerdem ein Skript, das für die tägliche Aktualisierung dieses Pakets sorgt. Diese häufige Aktualisierung ist erforderlich, da andernfalls die Widerrufslisten (CRL) veralten und die dazugehörigen CA-Zertifikate nicht mehr verwendbar sind (im Falle des capath-Modus).
Dieses Skript wird zu den folgenden Zeitpunkten ausgeführt:
Der stündliche cronjob, der nur kurz nach dem Booten wirksam ist, stellt sicher, dass unregelmäßig angeschaltete (bzw. verbundene) APs eine gute Chance haben, auch innerhalb einer kurzen Laufzeit ihre Zertifikate zu aktualisieren. Sollte dies mehr als 30 Tage lang nicht gelingen, dann verzögert sich anschließend die VPN-Verbindung, bis eine Zertifikatsaktualisierung erfolgreich abgeschlossen wird.
Die Aktualisierung wird über den opennet-internen Domainnamen (downloads.on), sowie den öffentlich nutzbaren Namen (downloads.opennet-initiative.de) versucht. Dies ermöglicht sowohl den direkten Teilnehmern des Mesh-Netzes, als auch den UGW-Hosts die Durchführung der CA-Aktualisierung.
Bei der Installation neuer Versionen des Opennet-Zertifikat-Pakets werden von opkg leider keine Signaturen und auch keine https-Verbindungen unterstützt. Somit ist auf diesem Weg das Unterschieben eines manipulierten CA-Zertifikats durch einen Dritten möglich.
Das on-core-Paket fügt bei der Erstinitialisierung einen Eintrag zur Firewall-Konfiguration hinzu, der dafür sorgt, dass bei jedem Reload der Firewall-Konfiguration alle Skripte im Verzeichnis /etc/on-firewall.d/ ausgeführt werden.
Skripte die sich in diesem Verzeichnis befinden, sollten auf eine idempotente Ausführung achten: sie dürfen also nicht die Löchung aller zuvor erzeugten Regeln voraussetzen, sondern müssen selbst dafür sorgen (falls erforderlich).
Ein typisches Ablauf-Schema solcher Skripte ist:
-I) falls nicht vorhanden, die auf diese separate Chain verweist-F)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.8