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

=== Montagsrunde (08.09.2014) ===

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