Benutzer:Lars/Blog:2014 September 08 23:21:09 CEST

Technik-Treffen

• am 11.09.2014 treffen wir uns ab 16:30 Uhr in der Frieda
• Themen:
  • Firmware-Release!?
  • DNS-Auflösung durch Gateways analysieren und eventuell korrigieren
    • 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

wilde Ideensammlung

• 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

Aktuelle DNS-Umsetzung

• lokale Domain *.on ist intern verfügbar: Adressierungsschema
• auf den Nutzer-APs werden regelmäßig die IPs aller Gateways gesammelt (siehe /etc/config/on-core - "dns_searchmask")
• einige wenige APs lösen die on-Domain auf
• viele APs lösen die Domain nicht auf:
  • gw_dns ist auf false gesetzt
  • ein manueller Server ist gesetzt
  • ?
• das Problem müsste bearbeitet werden, um DNS-basierte Dienste im Opennet anzubinden:
  • DNS-Server für die on-Domain via nameservice-Plugin announcieren
  • nur diejenigen Nameserver in die Liste aufnehmen, die einen on-Namen auflösen
    • wohl ungeeignet, da die UGW-APs für ihren VPN-Tunnel ach DNS benötigen

Variante I

Interne und externe Dienste unter identischen Namen durch 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 via olsrd-nameservice intern überlagern
• 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
• dieses Konzept verwenden wir bereits für die opkg-Aktualisierungen via downloads.openwrt.org
• Stand 2012: es gab ein paar Policy-Routing-Regeln, die die Lenkung von nicht-Opennet-IPs via HNA verhindert haben

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

• 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)