[Berlin-wireless] Tunnelbroker und VPN-Server

[Daniel Paufler]

Hallo Alina

Alina Friedrichsen wrote:
> 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.
Das wäre ja eine Baustelle.

> 
>> 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.
Ok. Noch eine Baustelle.

>> 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.
Wir werden wohl damit leben müssen, dass die verschiedenen Tunnelbroker
verschiedene Clients haben werden. Die Arbeit liegt also in der
Portierung der Clients auf openWRT und die Erstellung der LUCI-Webif +
scripte.

>>> * 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.
Nun - z.b. kann RA auch auf openvpn-tap, tinc, etc interfaces gemacht
werden. OK - aber das ist imo die Frage nach der mesh-ipv6 autoconfig.
Für die Verteilung der public-IPs (ipv4 + ipv6) denke ich in die
Richtung Tunnel-Foo + autoconfig (DHCP + RA).

>> 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.
Openvpn geht auch ohne chiper. Das ist eine Möglichkeit, neben ipip6,
ipv6 über ipv4 zu tunneln. Allerdings finde ich das Setup recht "teuer"
und kam so auf SIIT/NIIT.

>> 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. ;)
Schon klar, darum auch "". Aber damit kann ich die Funktionalität eines
Tunnelbrokers herstellen. Imo machen die "richtigen" Broker auch nix
anders - halt nur in ihrem eigenen Client / RFC.

siehe auch https://www.sixxs.net/tools/tic/ bzw.
https://www.sixxs.net/tools/ayiya/ bzw. https://www.sixxs.net/tools/aiccu/

Grüße

Daniel

-- 
Dipl. Inf. (FH) Daniel Paufler
Angewandte Informatik - Computer Aided Facility Management

-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 261 bytes
Beschreibung: OpenPGP digital signature
URL         : <http://lists.berlin.freifunk.net/pipermail/berlin/attachments/20091202/9c1671af/attachment.pgp>