Benutzer:Lars/Blog:2014 September 12 00:35:28 CEST - Versionsgeschichte

Matthias M: cat

2015-01-03T17:15:49Z

cat

← Nächstältere Version		Version vom 3. Januar 2015, 17:15 Uhr
Zeile 76:		Zeile 76:
	Der Proxy soll für so viele Protokolle wie möglich auf Standardports (25, 80, 443, ...) einen Verkehrseingang (öffentlich erreichbar) und die Weiterleitung ins Opennet hinein ermöglichen.		Der Proxy soll für so viele Protokolle wie möglich auf Standardports (25, 80, 443, ...) einen Verkehrseingang (öffentlich erreichbar) und die Weiterleitung ins Opennet hinein ermöglichen.
	Wie kann der Verkehr hier zwischen Proxy und AP verschlüsselt werden? Anwort: Bei Web bspw. HTTPS zwischen Proxy und AP-Web-Server machen.		Wie kann der Verkehr hier zwischen Proxy und AP verschlüsselt werden? Anwort: Bei Web bspw. HTTPS zwischen Proxy und AP-Web-Server machen.

			[[Kategorie:Techniktreffen]]
			[[Kategorie:Firmware]]

Lars: Ergänzungen aus heutigem Nachgespräch

2014-09-14T14:18:01Z

Ergänzungen aus heutigem Nachgespräch

← Nächstältere Version		Version vom 14. September 2014, 14:18 Uhr
Zeile 38:		Zeile 38:
	** Grund1: sonst wird der Upstream-DNS des Spenders befragt (Spendende soll nicht durch DNS Anfragen kompromitiert werden)		** Grund1: sonst wird der Upstream-DNS des Spenders befragt (Spendende soll nicht durch DNS Anfragen kompromitiert werden)
	** Grund2: unglaublich viel Bandbreiten-Verschwendung für kleine DNS-Anschlüsse		** Grund2: unglaublich viel Bandbreiten-Verschwendung für kleine DNS-Anschlüsse
	* alle nicht-UGWs nutzen zukünftig DNS-Server, die sich per nameservice/olsr ankündigen		* alle nicht-UGWs nutzen zukünftig DNS-Server, die sich explizit per nameservice/olsr ankündigen
	** service-Format und Integration in dnsmasq muss definiert werden		** service-Format und Integration in dnsmasq muss definiert werden
	** folgende DNS-Server sind aktuell geplant: titan, erina, subaru (sind bereits dns-Slaves)		** folgende DNS-Server sind aktuell geplant: titan, erina, subaru (sind bereits dns-Slaves)
Zeile 45:		Zeile 45:
	* Zonentransfer für DNS-Ansicht aus dem Opennet heraus (z.B. für die gesamte Zone systemausfall.org)		* Zonentransfer für DNS-Ansicht aus dem Opennet heraus (z.B. für die gesamte Zone systemausfall.org)

	Welche Probleme werden damit nicht gelöst:		Welche Probleme werden damit nicht gelöst ('''Nachtrag: 15.11.2014):
			* alte Nutzer-APs verwenden nach dem Tunnelaufbau explizit und ausschließlich ihre Tunnel-Gegenstelle (den UGW / den Gateway als DNS-Server)
	* keine
			** Lösung: die neuen APs verteilen keine 192.168.0-HNA mehr -> stattdessen explizite Ankündigung der gateway-Fähigkeit durch olsrd-nameservice (alte APs/Firmware können diese neuen APs also nicht verwenden, da sie quasi unsichtbar sind)

Lars: init

2014-09-11T22:35:41Z

init

Neue Seite

=== Techniktreffen (11.09.2014) ===
Wir haben wieder ein gemütliches und produktives Treffen in der Frieda veranstaltet.

=== Taten / Tickets ===
* http://dev.on-i.de/ticket/51
* http://dev.on-i.de/ticket/52
* http://dev.on-i.de/ticket/61

Das wichtigste davon ist der olsrd-Bug, der durch eine race-condition verhindert, dass ein wlan-Client-Interface mit aktivem olsrd bootet.

=== DNS ===
Wir haben uns über den aktuellen Zustand des DNS-Systems im Opennet ausgetauscht.

==== Anforderungen ====
* DNS-Anfragen von Opennet-Nutzenden sollen nicht über UGW-Upstream-DNS-Server (bei der Telekom) erfragt werden
** d.h. nur bei Opennet-Servern erfragen
* optional: konsistente Auslösung von opennet-internen-Domains auf allen APs (inkl. UGWs)

==== Ist-Zustand ====
* es gibt Zeitfenster (nach jeder DHCP-Anfrage eines UGW-AP), während derer DNS-Anfragen aus dem Opennet nach außen dringen (via gespendetem Uplink-DNS)
* Abfragen zirkulieren innerhalb einer Menge von UGWs, die diese Anfragen nicht beantworten können (weil sie dieselbe Menge von UGWs befragen)
** das Verhältnis von fähigen und unfähigen DNS-UGWs ist schlecht geworden :(
* die opennet-DNS-Anfragen werden von titan, aqua, erina und subaru beantwortet

==== DNS-Anfragen von Nutzenden ====
* jede DNS-Anfrage wird an _alle_ DNS-Upstream-Server geschickt
** weitere Verdopplung von Anfragen (an die ursprünglichen Anfrager) findet wohl nicht statt
* die Ergebnisermittlung (Mix aus allen Antworten) ist nicht ganz klar
** auch wenn Anfragen von den drei guten Gateways scheinen beim Nutzer nicht immer korrekt aufgelöst zu werden (auch wenn einzelne "gute" Antworten zurück kamen)
* lediglich drei Gateways kennen die on-Domain (titan, erina, subaru)
** alle anderen liefern NXDOMAIN* alle DNS-Anfragen (auch von Nutzer-APs) laufen unverschlüsselt durchs Opennet
** Anfragen an die on-Domain werden seltsamerweise von allen "schlechten" DNS-Servern durch nicht-Antwort (timeout) beantwortet

==== Maßnahmenplan ====
* UGWs mit existierendem DNS sollen ihren lokalen DNS-Server nicht mehr überschreiben
** grep -q "^nameserver" /tmp/resolv.conf.auto && skip_overwrite
* UGWs dienen nicht mehr als Nameserver
** Grund1: sonst wird der Upstream-DNS des Spenders befragt (Spendende soll nicht durch DNS Anfragen kompromitiert werden)
** Grund2: unglaublich viel Bandbreiten-Verschwendung für kleine DNS-Anschlüsse
* alle nicht-UGWs nutzen zukünftig DNS-Server, die sich per nameservice/olsr ankündigen
** service-Format und Integration in dnsmasq muss definiert werden
** folgende DNS-Server sind aktuell geplant: titan, erina, subaru (sind bereits dns-Slaves)

Optional:
* Zonentransfer für DNS-Ansicht aus dem Opennet heraus (z.B. für die gesamte Zone systemausfall.org)

Welche Probleme werden damit nicht gelöst:
* keine

=== Opennet-Dienste im Opennet ermöglichen ===
* Es sollen Dienste von Opennet auch im Opennet zugreifbar gemacht werden. Der Zugriff soll auch ohne VPN Tunnel möglich sein.
* folgende Dienste: wiki, Karte, IRC, Mail, ...
* kleine Details:
** sind alle Dienste-Server mit opennet-IPs ausgestattet? (ja: wiki, irc, mail)
** NameVirtualHost auf on-i.de muss von spezifischen IPs (olsr-IP ist veraltet) auf Wildcard umgestellt werden
* im Idealfall sind interne und externe URLs gleich
* Bei einer Teilung der Gesamtwolke ist natürlich ein Teil der Leute von den Diensten abgeschnitten und kann sie spontan auch nicht über das Internet erreichen, da die DNS-Informationen noch auf die Opennet-IPs zeigen.

==== Umsetzung ====
* Makefile/Script zur Erzeugung einer internen Zonen-Datei auf dem Nameserver (hog) erstellen (Mapping von öffentlichen IPs zu internen IPs)
* Konfiguration des bind auf hog/erina/subaru/titan für interface-spezifische DNS-Sichten

=== Mitglieder-Dienste im Opennet ermöglichen ===
Um das Opennet als Quelle originärer Dienste/Gemeinschaften zu entwickeln, wäre es super, zusätzliche interne Dienste im Opennet zur Verfügung zu stellen. Diese Dienste sollen bei Bedarf auch von extern erreichbar sein.
Generell muss hier das Thema DNS und Proxy-Weiterleitung (z.B. HTTP) betrachtet werden.

==== DNS ====
* aktuell für "offizielle" Opennet-Server: *.on
* Es besteht Bedarf Nutzerdomains zu registrieren, um Dienste im Opennet anzubieten. Diese Dienste sind idealerweise auch von außen erreichbar.
* aktuell vielleicht schon durch dyn.on-i.de / dyn.on halbwegs abgedeckt (unklarer Zustand)
* Ein Ziel ist die Erreichbarkeit von Domains von außen und innen. Dafür sind unterschiedliche Sichtweisen der DNS-Server notwendig. Die Opennet internen DNS Server sollen bei den Domains nur interne IPs auflösen. Wahrend bei externen Anfragen auch externe IPs geliefert werden sollen. Eine erste fixe Idee (noch weiter diskutieren) wäre das Einrichten der Domains mit internen IPs auf titan&co, wobei für das externe Auflösen auch der externe DNS Server von Opennet genutzt wird.

==== Proxy ====
Der Proxy soll für so viele Protokolle wie möglich auf Standardports (25, 80, 443, ...) einen Verkehrseingang (öffentlich erreichbar) und die Weiterleitung ins Opennet hinein ermöglichen.
Wie kann der Verkehr hier zwischen Proxy und AP verschlüsselt werden? Anwort: Bei Web bspw. HTTPS zwischen Proxy und AP-Web-Server machen.