[Berlin-wireless] Tunnelbroker und VPN-Server

[Alina Friedrichsen]

Hallo Daniel!

> Genau. Ich bezog mich darauf, dass die "einfach" zu Titan gehen. (siehe
> eingefügtes quote) Davon gibts (noch) zu wenig - sprich wenig
> Wahlmöglichkeiten nur ipv6 vom Provider zu verfolgen.

Ja, aber das wird sich ja hoffentlich bald aendern.

> Wie du aber
> richtig geschrieben hast, gibt es da eine Menge an Alternativen.

Ja.

> 6to4 Tunnel hab ich @home am Laufen. Hab da auch schonmal scripte
> angefangen, die das beim WAN-up in openwrt machen könnten. Allerdings
> noch nicht getestet und garade auf x86 am laufen. Denke aber, dass das
> ohne großen Aufwand ein Hacken im plain-openwrt ist. Den kann der
> Benutzer einfach aktivieren (wie beim apple-airport) und gut ists.

Ja, wenn das waere echt super! Kannst Du die in OpenWrt einreichen, oder
mir schicken?

> freifunk-tunnel-broker: siehe unten
> 
> sixxs, freenet, He und andere haben imo ipkg's im openwrt,

HE noch nicht, das IP-Adressen Update-Script von mir wurde nicht
aufgenommen und das 6scripts-Paket fuer das Einrichten von generischen
6in4-Tunneln ist im hohen Masse broken und macht wenn installiert den
ganzen Router instabil.

> welche "nur
> noch" ein WEB-IF brauchen. Das wäre imo eine lohnenswerte Arbeit für
> Freifunk, openWRT und die Benutzer.

Ja, im Bereich von LuCI.

> Ack. Imo gibts schon ipkgs für div. Broker. UCI web-config weiss ich
> gerade nicht, ob die mit dabei ist. Die muss da aber rein, full ack,
> siehe oben.

Noch besser waere es, wenn sie sich auf einen Standard einigen koennten,
das scheinen sie aber durch nicht-veroeffentlichen des
Server-Sourcecodes weiter zu boykottieren.

> > * IPv6-Autoconfig via Duplicate Address Detection im Routing-Daemon
> > koennte in einer Woche stehen.
> Finde ich persönlich nicht so spanndend. In den oben genannten Fällen
> gibts die IPv6 ja per Router Announcement (RA) und ipv6 stack mac algorithm.

Ich spreche von der Autokonfiguration des Mesh-Netzwerks und nicht der
Clients auf der LAN-Seite. Erstere bedarf eines speziellen Handlings.
Wenn Du einen neuen Node in einen Funkloch aufmachst, ist da ja kein
weiterer Node mit dem radvd, der Dir das Prefix ankuendigen kann. Der
neue Node sollte es also selbst wissen, und sich selbst darin eine IP
geben.

> Hier ist mir nicht klar, wie das mit dem eigenen Broker funktioniert.
> CGI-Scripte die ipip tun-devs aufmachen?

Ja, bei einen normalen Tunnel-Broker schon. Ich wuerde sagen eine
SQLite-Datenbank oder XML-File in dem alle Accounts mit Password-Hash
stehen. Ein Programm das beim Booten alle 6in4-Tunnel (sit) aufbaut. Und
ein CGI-Script, das das automatische Updaten der IPv4-Adressen erlaubt.
Spaeter koennte das dann um ein Webinterface ergaenzt werden.

> openvpn die tuns configgen und
> auto-key-signing? Ist mir nicht ganz klar - 

Verschluesselung ist normalerweise nicht noetig, da die Pakete ja
sowieso vom Tunnel-Broker unverschluesselt ins Internet gelassen werden,
so das es nicht viel bringt, wenn sie auf dem Weg vom Uplink zum
Tunnel-Broker verschluesselt sind. Aber eine simple
Challenge-Response-Authentifizierung fuer die Password-Uebergabe waere
schon sinnvoll, um zu verhindern das der Tunnel gekapert wird.

> und wie schon geschrieben,
> habe ich keinerlei OSS gefunden, die Tunnel-Broker ermöglichen (apt-get
> install ;) )

Wenn Du willst, kann ich Dir das in C++ schreiben.

> Wenn wir das mit Freifunk-IPv6 Adressen machen, dann können wir imo
> unsere Netze gleich damit fahren und direkt routen.

Mit normalen Routing, koennten wir ohne sehr komplizierte Erweiterungen
im Routing-Protokoll die auch nicht mit den 2.4er Kernel funktionieren
wuerden oder NAT, nur einen IP-Adressbereich also einen Tunnel-Broker
unterstuetzen. Daher trete ich fuer einen von dem Grundrouting
abgeloesten Tunnel-Daemon ein, der einen Tunnel zum Uplink aufbaut und
sich von diesen auch die Public-IPs holt.

>  Die "Tunnel-Broker"
> können dann auch cloudVPN, n2n, l2gvpn, etc sein. ;)

Das sind keine Tunnel-Broker, sonder Programme. ;)

Liebe Gruesse
Alina