Benutzer:Lars/Blog:2014 September 08 23:21:09 CEST: Unterschied zwischen den Versionen
Aus Opennet
Lars (Diskussion | Beiträge) (Termin war falsch) |
Lars (Diskussion | Beiträge) (Nachträge) |
||
Zeile 5: | Zeile 5: | ||
* Themen: | * Themen: | ||
** Firmware-Release!? | ** Firmware-Release!? | ||
− | ** DNS | + | ** DNS-Auflösung durch Gateways analysieren und eventuell korrigieren |
*** man dnsmasq | *** man dnsmasq | ||
*** less /usr/share/doc/olsrd-plugins/README_NAMESERVICE (Announcierung von Toplevel-Domains und dazugehörigen DNS-Servern) | *** less /usr/share/doc/olsrd-plugins/README_NAMESERVICE (Announcierung von Toplevel-Domains und dazugehörigen DNS-Servern) | ||
Zeile 24: | Zeile 24: | ||
* Robert prüft, ob eine Verbindung in Richtung Strempelstraße möglich ist | * Robert prüft, ob eine Verbindung in Richtung Strempelstraße möglich ist | ||
− | === Dienste im Opennet | + | === Dienste im Opennet === |
+ | ==== wilde Ideensammlung ==== | ||
* Dateiserver | * Dateiserver | ||
* Backup | * Backup | ||
Zeile 49: | Zeile 50: | ||
** Befreiung der eigenen Daten aus fremden Händen | ** Befreiung der eigenen Daten aus fremden Händen | ||
− | === DNS- | + | ==== Aktuelle DNS-Umsetzung ==== |
− | * lokale Domain | + | * 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 | |
− | ** das Problem müsste bearbeitet werden, um DNS-basierte Dienste im Opennet anzubinden | + | ** 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 ==== | ==== 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 | * 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 | ** von außen wird eine öffentliche IP zurückgeliefert | ||
Zeile 66: | Zeile 72: | ||
==== Variante II ==== | ==== Variante II ==== | ||
− | * DNS intern | + | * DNS via olsrd-nameservice intern überlagern |
* olsrd-nameservice: Verkündung von Namens- und IP-Zuordnungen via nameservice-Plugin | * 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 | * bei den willigen Clients muss derzeit explizit konfiguriert werden, dass diese verteilten Hosts akzeptiert werden | ||
Zeile 72: | Zeile 78: | ||
==== Variante III ==== | ==== Variante III ==== | ||
* HNA: Announcierung öffentlicher IPs im Opennet | * 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 | * 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 ==== | |
− | + | ||
− | + | ||
− | + | ||
− | ==== 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 | * 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 | * 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 | ** 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) | * Upstream-DNS-Konfiguration auf den Routern muss analysiert und eventuell repariert werden (beim nächsten Technik-Treffen) |
Aktuelle Version vom 9. September 2014, 03:09 Uhr
Inhaltsverzeichnis |
[Bearbeiten] Montagsrunde (08.09.2014)
[Bearbeiten] 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
[Bearbeiten] Server in der Frieda
- der Server ist angekommen!
- Aufbau beim nächsten Technik-Treffen
[Bearbeiten] 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
[Bearbeiten] Dienste im Opennet
[Bearbeiten] 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)
[Bearbeiten] Geräte als Diensteanbieter
- Konzepte: Freedombox / ArkOS
- Befreiung der eigenen Daten aus fremden Händen
[Bearbeiten] 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
[Bearbeiten] 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, ...)
[Bearbeiten] 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
[Bearbeiten] 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
[Bearbeiten] 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)