[WLANware] Tinc - aktuellere Version

[Alexander Morlang]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Adrian Reyer schrieb:
> On Fri, Aug 17, 2007 at 03:34:12PM +0200, Alexander Morlang wrote:
>> zum frickel wirklich nice, aber zum vernetzen von wolken eine massive
>> bandbreitenverschwendung, da alles über den zentralen server geleitet
>> wird, waehren bei tinc die zentralen server meist nur koordinieren und
>> nur dann traffic durchleiten müssen, wenn sich 2 nodes (dank nat) nicht
>> direkt sehen können.
> 
> Der zentrale VPN-Server Ansatz hat natuerlich noch den Vorteil, dass
> die Clients hier nicht noch eine Meshrouting Tabelle halten muessen.
> Speziell OpenVPN kann auch mehrere Server, die roundRobin-maessig
> kontaktiert werden, wenn sich also jemand einen zweiten Server
> hinstellt, OpenVPN darauf konfiguriert, aber nicht startet, den
> anderen VPN-Server auf Verfuegbarkeit ueberwacht und im Fehlerfall
> einfach den eigenen hochfaehrt, hat man sogar noch eine Redundanz auf
> einfachste Art und Weise.
> Der Traffic ins VPN muss eh ins Netz und so wirr wie Traffic durch
> Deutschland geroutet wird, denke ich nicht, dass das Routing ueber
> einen zentralen Server ein wirklicher Mehrtraffic ist. Und in Zeiten
> von Flatrate Rootservern sollte das ja auch finanziell keinen
> Unterschied mehr machen.

ja, man kann sich so ein "zentral" konzept mittels backups absichern,
aber das macht es nicht besser, im falle des IC-vpn, bei dem städte per
tinc peeren, wird es "auf zuruf" gemacht und die netze per BGP
announced. Per default wird von den peers fast alles angenommen. Hier
ist die zentrale instanz eine wiki.

Bei den innerstaedtischen vpns ist "auf zuruf" natürlich nicht möglich,
hier stellt sich die frage nach einem effizienten verteilungsmechanismus
und der möglichkeit, schlüssel wieder zurückzuziehen. Mit dem openssl
utility kann man signaturen von dateien prüfen, allerdings hätte man
hier wieder die zentrale instanz (und eine weites "fettes" paket).
Ausserdem währe es denkbar, die information, das ein schlüsselupdate
vorliegt, über einen meshspezifischen mechanismus zu verteilen (bmf, etc).

Ich denke, das sich der aufbau zentralistischer strukturen nicht mit dem
hinweis auf traffic-flatrates rechtfertigen lässt, speziell, wenn sich
die redundanz auf ein hot-standby reduziert.

schwerer wiegt hier sven-olas argument, das tinc (+openssl-util) einfach
mal richtig fett ist, allerdings sprechen wir im regelfall von 16Mbit
ADSL2+ leitungen, da kommen die üblichen verdächtigen, die zu wenig
ram/flash haben, bei dem tempo eh nicht mit. Zumindest wenn man davon
ausgeht, das langfristig der gesamte traffic über tunnel geht, um
PI-Netze ins mesh zu routen.

> 
> Tschoe,
> 	Adrian
> 

Gruss, Alex
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGxelHhx2RbV7T5aERAm2EAKDE5vfTSkPykTo0yOG1rKT6nQJkXQCgr4bW
oZe7pVOkqqkT7PkrJd+DROY=
=DCsY
-----END PGP SIGNATURE-----