Projekt Dediziertes Gateway fuer Unterkuenfte: Unterschied zwischen den Versionen

Version vom 4. Januar 2024, 21:13 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 Resourcen

• 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 als zusätzliches UGW manuell eingetragen.
• 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
  • zusätzliche CSV-Datei angelegt unter https://services.opennet-initiative.de/ugw-services-tmp-wmartin-ith-itsuki.csv
  • service.sh aif AP2.190 gepatch 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()

• AP2.249 + AP2.225 (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.

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