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

Aus Opennet
Wechseln zu: Navigation, Suche
(init)
 
(Nachträge)
 
(Eine dazwischenliegende Version von einem Benutzer wird nicht angezeigt)
Zeile 2: Zeile 2:
  
 
=== Technik-Treffen ===
 
=== Technik-Treffen ===
−
* am 18.09.2014 treffen wir uns in der Frieda
+
* am 11.09.2014 treffen wir uns ab 16:30 Uhr in der Frieda
 
* Themen:
 
* Themen:
 
** Firmware-Release!?
 
** Firmware-Release!?
−
** DNS im Opennet reparieren
+
** 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 (Ideen) ===
+
=== 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-Gedanken ===
+
==== Aktuelle DNS-Umsetzung ====
−
* lokale Domain definieren?
+
* lokale Domain *.on ist intern verfügbar: [[Adressierungsschema]]
−
* z.B.: lohro.oni
+
* auf den Nutzer-APs werden regelmäßig die IPs aller Gateways gesammelt (siehe /etc/config/on-core - "dns_searchmask")
−
* aktuelle DNS-Auflösung:
+
* einige wenige APs lösen die on-Domain auf
−
** auf den Nutzer-APs werden die IPs aller Gateways gesammelt (siehe /etc/config/on-core - "dns_searchmask")
+
* viele APs lösen die Domain nicht auf:
−
** einige wenige APs lösen auch die on-Domain 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 ====
−
* verschiedene DNS-Perspektiven
+
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 verfügbar machen
+
* 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
  
−
==== Zugriff auf externe Dienste ohne Tunnel ====
+
==== Anwendungsfall: Dienst von innen und außen unter verschiedenen Namen und IPs zugänglich machen ====
−
* 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
 
* 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)
Von „http://wiki.opennet-initiative.de/w/index.php?title=Benutzer:Lars/Blog:2014_September_08_23:21:09_CEST&oldid=26222“
Meine Werkzeuge
Namensräume

Varianten
Aktionen
Start
Opennet
Kommunikation
Karten
Werkzeuge