Projekt Dediziertes Gateway fuer Unterkuenfte: Unterschied zwischen den Versionen

Version vom 14. April 2024, 22:33 Uhr

Projekt: Dediziertes Gateway für Gemeinschaftsunterkünfte

Motivation

Wir haben in letzter Zeit (Ende 2023) gemerkt, dass es einige Opennet Knoten gibt, welche einen sehr hohen Bandbreitenbedarf haben. Diese Knoten lasten teilweise ein ganze Gateway aus. Andere Teilnehmer auf dem gleichen Gateway haben als Konsequenz eine sehr schlechte Internetanbindung.

Derzeit haben wir zwei Geflüchtetenunterkünfte, welche verständlicherweise diesen hohen Bandbreitenbedarf haben. Dort sind mehrere hundert Personen untergebracht.

Ziel dieses Projektes:

• Erstellen eines dedizierten Gateway Severs
  • dadurch die Anbindung für zahlende Opennet Mitglieder verbessern
• Ausbau/Optimierung der Anbindung für die Unterkünfte

Involvierte Ressourcen

• Gateway Server itsuki - wird dedizierter Server
• User VPN Knoten
  • Die folgenden zwei Knoten produzieren derzeit (Dez. 2023) sehr viel Traffic auf subaru.
  • AP2.250 - AE22 - bedient SSID hro-gaeste
    • verbindet sich über 192.168.2.190:5101 zu subaru
  • AP2.249 / 2.245 / 2.225 - Satower Str.
    • verbindet sich über 192.168.2.190:5101 zu subaru
• UGWs - itsuki als Mesh Gateway manuell hinzugefügt. Somit ist Opennet Mesh mit itsuki verbunden.
  • AP2.190
  • AP2.189 (sollte immer gleich zu AP2.190 konfiguriert sein)

Schritte

Erledigt:

• itsuki als UGW Server eingerichtet
• itsuki ins Mesh einbinden
  • erstmal auf AP2.189 + AP2.190 das UGW itsuki mit einem Workaround hinzugefügt:
    • zusätzliche CSV-Datei angelegt unter https://services.opennet-initiative.de/ugw-services-tmp-wmartin-ith-itsuki.csv
    • service.sh auf AP2.190 gepatcht und zusätzlichen Link hinzugefügt

  --- a/opennet/packages/on-core/files/usr/lib/opennet/services.sh
  +++ b/opennet/packages/on-core/files/usr/lib/opennet/services.sh
  @@ -25,9 +25,11 @@ SERVICES_LOG_BASE=/var/log/on-services
   RELAYABLE_SERVICE_PREFIX="proxy-"
   UPDATE_TRUSTED_SERVICES_PERIOD_MINUTES=360
   USER_SERVICES_URL=https://services.opennet-initiative.de/user-services.csv
  +# tmp martin test
  +USER_SERVICES_URL_ITSUKI=https://services.opennet-initiative.de/ugw-services-tmp-wmartin-ith-itsuki.csv
   
   # andere Module fügen eventuell weitere URLs hinzu
  -SERVICES_LIST_URLS="${SERVICES_LIST_URLS:-} $USER_SERVICES_URL"
  +SERVICES_LIST_URLS="${SERVICES_LIST_URLS:-} $USER_SERVICES_URL $USER_SERVICES_URL_ITSUKI"
   
   ## @fn get_service_name()
  

• • • Dieser Workaround ist seit der Firmwareversion 0.5.9 nicht mehr notwendig, denn es wurde eine extra Funktion (siehe commit) in die Firmware integriert, mit der weitere Service-Relays hinzugefügt werden können.
• itsuki.on ins DNS aufnehmen
  • named.conf.local.notifies_int
  • zone/on.zone (erledigt)
  • zone/192.168.zone (erledigt)
  • zone/opennet-initiative.de.zone (keine Änderung)
  • zone/10.2.zone (erledigt)
• itsuki ins Munin Logging aufnehmen (munin-conf.d/server.conf). Wir benötigen ein Statistik über die Bandbreitennutzung, um einzuschätzen wie gut oder schlecht itsuki in seiner aktuellen Konfiguration als UGW funktioniert. Wenn die Nutzer umgezogen sind, sollten wir ca. 80 MBit/s tagsüber sehen. Wenn es signifikant weniger ist, muss ggf. der Server vergrößert werden.
• auf User-AP den Server itsuki in die Auswahlliste hinzufügen
• AP2.249 + AP2.225 + AP2.245 (Satower Str): itsuki als aktives Gateway ausgewählt. Somit geht der Traffic jetzt über itsuki.
  • Beobachtung: Der Traffic ist auf subaru um ca. 20Mbit/s zurückgegangen. Entsprechend ging der Traffic auf itsuki hoch. Sieht gut aus.
• AP2.250 (HRO Gäste / Unterkünfte): itsuki als aktives Gateway ausgewählt.
• UGW AP2.189: Dienst-Weiterleitung für itsuki konfiguriert.

Besonderheiten der APs in der Satower Straße

Da die Firmware gelegentlich Uplink-Offsets vergisst (siehe firmware#9), wird auf den APs täglich ein Cron-Job ausgeführt, der die Uplink-Offsets neu setzt (für eine gleichmäßge Verteilung des Verkehrs):

• Cron-Job: /etc/cron.daily/satower_reconfigure_upstream_preference
• Konfigurationsdatei: /etc/satower-upstream-offsets.conf

Die Auswahl des gewünschten Gateways muss auf diesen APs (AP2.225, AP2.245 und AP2.249) als in der obigen Konfigurationsdatei erfolgen. Andernfalls gehen manuelle Anpassungen unweigerlich innerhalb eines Tages verloren.

Offen:

• manuelle Änderung auf AP2.190 für Gatewayauswahl besser lösen als Datei direkt editieren
• Doku aktualisieren
  • Server
  • Gluon Babel Firmware Test
  • Server/itsuki