Benutzer:Lars/Blog:2014 September 08 23:21:09 CEST: Unterschied zwischen den Versionen

Version vom 9. September 2014, 01:03 Uhr

Montagsrunde (08.09.2014)

Technik-Treffen

• am 11.09.2014 treffen wir uns ab 16:30 Uhr in der Frieda
• Themen:
  • Firmware-Release!?
  • DNS im Opennet reparieren
    • man dnsmasq
    • less /usr/share/doc/olsrd-plugins/README_NAMESERVICE (Announcierung von Toplevel-Domains und dazugehörigen DNS-Servern)
  • Wiki/Karte/CA im Opennet zugänglich machen
  • Server-Ein/aufbau im Serverschrank der Etage

Server in der Frieda

• der Server ist angekommen!
• Aufbau beim nächsten Technik-Treffen

Oldendorp-Straße

• zweiter Installationsversuch fand statt
• der neue Aufbau ist nahezu unsichtbar
• Verbindung mit der Fakultät in der Ulmenstraße
• Etagenübergreifende Verbindung via Hauswandreflektion mit ca. 50 MBit/s
• Verbindung in Richtung Ulmenstraße mit ca. 26 MBit/s
• Robert prüft, ob eine Verbindung in Richtung Strempelstraße möglich ist

Dienste im Opennet (Ideen)

• Dateiserver
• Backup
• Opennet-Wiki
• Opennet-Karte
• Chat (eventuell für Opennet-Support)
• VOIP / Telefon
• lokale Dienstanbieter: z.B. systemausfall.org
• ein kleiner offline-Internetspiegel
• Infrastruktur lokaler Vereine (Food-Soft)
• lokale Radio-Streams
• Katzen-Webcams
• Rostocker Podcast-Plattform
• Paket-Proxies
• git / Entwicklung
• Zeitserver
• private Webseiten
• interne Dienste nach außen sichtbar machen (Port-Forwarding)
• Kalender, private Datenablage
• öffentlicher eingeschränkter Zugriff auf eigene Dienste zuhause (VPN)

Geräte als Diensteanbieter

• Konzepte: Freedombox / ArkOS
  • Befreiung der eigenen Daten aus fremden Händen

DNS-Gedanken

• lokale Domain definieren?
• z.B.: lohro.oni
• aktuelle DNS-Auflösung:
  • auf den Nutzer-APs werden die IPs aller Gateways gesammelt (siehe /etc/config/on-core - "dns_searchmask")
  • einige wenige APs lösen auch die on-Domain auf
  • das Problem müsste bearbeitet werden, um DNS-basierte Dienste im Opennet anzubinden

Variante I

• verschiedene DNS-Perspektiven
• Abfrage nach x.y.users.on-i.de liefert bei einer Anfrage aus dem Opennet heraus eine Opennet-IP
  • von außen wird eine öffentliche IP zurückgeliefert
• Nutzer melden ihre Namenswünsche bei den Admins an
• bei Ausfall der Opennet-Verbindung zu dem Server funktioniert der ZUgriff von innen nicht mehr
• wir bräuchten dafür auf einem oder mehreren extern erreichbaren Opennet-Servern Protokoll-Proxies (z.B. nginx) für ausgewählte Ports (80, 443, 25, ...)

Variante II

• DNS intern verfügbar machen
• olsrd-nameservice: Verkündung von Namens- und IP-Zuordnungen via nameservice-Plugin
• bei den willigen Clients muss derzeit explizit konfiguriert werden, dass diese verteilten Hosts akzeptiert werden

Variante III

• HNA: Announcierung öffentlicher IPs im Opennet
• Stand 2012: es gab ein paar Policy-Routing-Regeln, die die Lenkung von nicht-Opennet-IPs via HNA verhindert haben

Zugriff auf externe Dienste ohne Tunnel

• Zugriff von den APs aus auf die downloads.openwrt.org-Server ist via HNA und FORWARD-Erlaubnissen auf den Gateway-Servern möglich
• wird schwer zu verwalten sein (Synchronität der Gateways)

Anwendungsfall: Dienst von innen und außen unter verschiedenen IPs zugänglich

• Vorschlag: wir geben die "*.on" frei für Namen, die von Nutzern erwählt wurden
• diese könnte dann auch in den *.on-i.de-Raum gespiegelt werden
  • Verwender dieser Domainnamen müssen natürlich auf ein klar abgegrenztes Impressum achten
• Upstream-DNS-Konfiguration auf den Routern muss analysiert und eventuell repariert werden (beim nächsten Technik-Treffen)