Zeile 1: |
Zeile 1: |
| + | {{Protokoll| |
| + | |Protokollant= |
| + | |Datum=12.12.2013 |
| + | |Ort= |
| + | |Teilnehmer= |
| + | }} |
| | | |
| == Gedankenfesthaltungsprotokoll vom Techniktreffen am 12.12.2013 zur Grundinfrastruktur == | | == Gedankenfesthaltungsprotokoll vom Techniktreffen am 12.12.2013 zur Grundinfrastruktur == |
| | | |
| | | |
− | - Gates vereinen Entry(Tinc)- und Exit(Schweden)-Level in einer Maschine (keine geteilte Entry-/Exit-Node Strategie)
| + | * Gates vereinen Entry(Tinc)* und Exit(Schweden)-Level in einer Maschine (keine geteilte Entry-/Exit-Node Strategie) |
| | | |
− | - Gates verbinden nach Schweden per VPN
| + | * Gates verbinden nach Schweden per VPN |
| | | |
− | - Gates routen+NATen zwischen Freifunk-Wolke und Schweden/Internetz
| + | * Gates routen+NATen zwischen Freifunk-Wolke und Schweden/Internetz |
| | | |
− | - Gates sind DHCP (dhcpd)
| + | * Gates sind DHCP (dhcpd) |
− |
| + | ** DHCP verteilt neue Leases bis zum Erreichen eines Threshold (empirisch ermitteln) |
− | - DHCP verteilt Leases bis Threshold
| + | ** DHCP ermittelt/berechnet seine Last anhand der Anzahl der verteilten Leases und Bandbreitenauslastung |
− | - DHCP ermittelt Last anhand von verteilten Leases und Bandbreitenauslastung
| + | ** DHCP verteilt, wenn Last zu hoch, also über dem Threshold, keine neuen Leases mehr, wohl aber beantwortet/bestätigt er die vorhandenen Leases weiterhin |
− | - DHCP verteilt wenn Last zu hoch keine neuen Leases aber beantwortet/bestätigt die vorhandenen Leases weiterhin
| + | ** DHCP verteilt Leases mit TTL 5 Min. |
− | - DHCP verteilt Leases mit TTL 5min
| + | ** Jedes Gate hat seine eigene Adressrange, disjunkt von denen anderer Gates. |
− | - Jedes Gate hat eigene Adressrange
| |
| | | |
− | - Nodes verbinden sich per Tinc zu Gates
| + | * Nodes verbinden sich per Tinc zu Gates |
| | | |
− | - Nodes bekommen Pool von 20 tinc-server hinterlegt
| + | * Nodes bekommen einen Pool von 20 Tinc-Servern hinterlegt (im Voraus angelegte Schlüsselpaare) als Wachstumspfad |
| | | |
− | - Nodes bekommen DNS Namen der Gates eingetragen
| + | * Nodes bekommen DNS-Namen der Gates eingetragen |
| | | |
− | - Nodes entscheiden bei Boot:
| + | * Nodes entscheiden bei Boot: |
− | - welche Tinc-Server erreichbar sind (Ping check)
| + | ** welche Tinc-Server erreichbar sind (Ping check) |
− | - Nodes kopieren aus den ermittelten lebendigen Servern 2-3 Tinc-Keys in ihren Tinc-Hosts-Ordner
| + | ** Nodes kopieren aus den ermittelten lebendigen Servern 2-3 Tinc-Keys in ihren Tinc-Hosts-Ordner |
− | - jedes Gate hat eigenen Priv/Pub-Key
| + | ** jedes Gate hat eigenes Priv/Pub-Schlüsselpärchen |
| | | |
− | - tinc verschlüsseln ja/nein?
| + | * tinc verschlüsseln ja/nein? |
| + | ** tinc-Compression aus, da gescheite Protokolle sowieso komprimiert sind und der Rest ist nicht komprimierbar ist (JPGs, MPGs) |
| + | ** tinc-Verschlüsselung an |
| + | ** node publickeys werden per GIT verteilt |
| + | ** node publickeys werden von der Technikgruppe eingetragen |
| + | ** es werden 20 tinc schlüssel für die Gates vorab generiert und im node-image hinterlegt |
| + | ** verschlüsselungs-algo wird von sebastian getestet und der für MIPS schnellste ausgewählt (weil starke crypto nicht gebraucht) |
| | | |
− | - tinc compression aus (gescheite Protokolle sind sowieso kompressiert, der Rest ist nicht komprimierbar)
| + | * tinc namensschema: |
− | - tinc verschlüsselung an
| + | ** soll einheitlich vorgegeben werden |
− | - node publickeys werden per GIT verteilt
| + | ** (evtl. hash aus vorgegebener datei) |
− | - node publickeys werden von der technikgruppe eingetragen
| + | *** besser gut menschenlesbar |
− | - es werden 20 tinc schlüssel für die Gates vorab generiert und im node-image hinterlegt
| + | ** evtl. prefix gleich und zweiter teil private und selbst bestimmbar |
− | - verschlüsselungs-algo wird von sebastian getestet und der für MIPS schnellste ausgewählt (weil starke crypto nicht gebraucht)
| + | ** brauchen wir tincnamen? |
| | | |
− | - tinc namensschema:
| + | * batman |
− | - soll einheitlich vorgegeben werden
| + | ** originator Interval auf 10 Sek. |
− | - evtl. hash aus vorgegebener datei
| + | ** network mode und andere Optionen anschauen/testen |
− | - evtl. prefix gleich und zweiter teil private und selbst bestimmbar
| |
− | - brauchen wir tincnamen?
| |
| | | |
− | - batman | + | * wenn tinc-uplink weg dann freifunk SSID aus/verstecken? |
− | - originator interval auf 10 sec
| |
− | - network mode und andere optionen anschauen/testen
| |
| | | |
| + | * mesh verstecken? |
| | | |
− | - wenn tinc-uplink weg dann freifunk SSID aus/verstecken?
| + | ==Anmerkungen== |
| | | |
− | - mesh verstecken? | + | Auf dem 30c3 wurden die Hamburger zur Gateway-Infrastruktur befragt: |
| + | * Sie verwenden fastd, und Tunneln dort batman durch |
| + | ** Es gibt seit kurzem eine neue Version von fastd ('''fastd-f'''), welches angeblich mehr Performance als Tinc liefert. |
| + | * Die Gateway-Server laufen im batman im [http://www.open-mesh.org/projects/batman-adv/wiki/Gateways Gateway-Modus] |
| + | ** Ist der Gatewayserver nicht mehr verwendbar (IPredator-Uplink nicht bezahlt, Traffic voll, etc) wird der Gateway-Modus in Batman abgeschaltet, Batman auf den Nodes macht dann ein Failover auf die anderen Gateways. |