On Thu, 4 Oct 2007, Christian Felsing wrote:
Frank Boehm schrieb:
kurzen Beschreibung ein unnoetiger Aufwand zu sein.
Ein IPsec Tunnel kann nur eine Verbindung zwischen genau 2 vorgegebenen
Netzen aufbauen. Es ist nicht möglich, andere (remote) Netze über einen
IPsec Tunnel zu routen.
Diesen Punkt erklaer bitte genauer, weshalb sollte das nicht gehen?
Gerne mit Link zu den Cisco Webseiten. Grundsaetzlich kann ich meine Routen
doch setzen wie ich will, und wenn die durch einen IPsec Tunnel gehen ist
das auch egal.
Bei meinen Versuchen hat das IPsec besser
abgeschnitten, weiterhin sind an diesem VPN-Backbone auch Ciscos
beteiligt, die nun einmal kein OpenVPN können.
OpenVPN auf demselben Rechner, auf dem auch Asterisk laeuft?
Solange die beteiligten Router ein gemeinsames Routingprotokoll beherschen,
aendert sich fuer die Clients ja nichts.
Naja, es macht für den User schon einen Unterschied, ob er sich via
OpenVPN oder IPsec zu Asterisk verbindet. Die User brauchen auch kein
Routingprotokoll, das geht hier über statische Routen bzw. Remote Config
von OpenVPN.
Hier haben wir wohl aneinander vorbei geredet. Ein User hat sich nach meiner
Definition um nichts zu kuemmern, schon gar nicht ob/wie geroutet wird. Der
kriegt in sein Netz ein fertig konfigurierten Router, der das gefaelligst zu
erledigen hat. Ob der sich dann it OpenVPN oder IPsec zu Asterisk verbindet
spielt dann keine Rolle fuer einen Enduser.
IP technisch ist das sicher kein Problem, es geht hier vielmehr um IAX2,
das dann irgendwie damit zurecht kommen muss, dass eine bestimmte
Telefonnummer auf 2 Wegen erreichbar ist. Im Notfall kann man das
allerdings über Anycast regeln.
? IAX2 als IP Protokoll muss sich da ueberhaupt nicht drum kuemmern. Sollen
denn dieselben SIP-Adressen nicht nur innerhalb des gemeinsames Testnetzes
mit einer IP aus einem privaten Bereich sondern auch parallel mit einer
public IP versehen sein? Das waere wirklich ungeschickt geloest.
Von Anycast Versuchen und Fehlersuche wuerde ich gerade am Anfang lieber die
Finger lassen.
Nur zu wissen, was fuer Adressen das Netz eines Clients hat, reicht ja leider
nicht aus. Bei Konflikten muss man immer noch manuell eingreifen.
Wo sollen denn die OpenVPN Tunnel fuer die Client Netze enden? Zwei Faelle
als Beispiel:
1. Bei einem stubbed net, indem der einzige Router in einem LAN ein Linux
Router ist, der fuer sein LAN DHCP+DNS spielt und auch default gateway, brauchen
sich Rechner im Client LAN um nichts kuemmern.
2. Gibt es einen einfachen normalen WLAN-Router (KEIN openwert) und einen
OpenVPN Linux Server der per Port Forwarding die Pakete vom WLAN-Router
weitergereicht bekommt im Netz. Dann brauchen ja auch alle beteiligten Clients
die Routen aller teilnehmenden Netze.
Alle Teilnehmer in diesem Versuch sollten ihre LAN in verschiedenen Subnets
haben. Das wird bestimmt einiges an Umbauaktionen bei den Teilnehmern
bedeuten.
Im Wiki hab ich mal nach einem IP-Adressplan geschaut, aber wohl an der
falschen Stelle? Unter http://www.pug.org/index.php/Asterisk fand ich noch
keinen Hinweis auf diesen Feldversuch.
Für Windows User könnte man da ein angepasstes OpenVPN Paket bauen. Auf
der Downloadseite wird dann on the Fly ein X.509 Zertifikat generiert
und dann das komplette fertig konfigurierte MSI Paket gebaut.
Installation erfolgt dann wie üblich per Doppelklick. Damit es keine
Kollisionen zwischen User LAN und OpenVPN Transfernetz gibt, kann man
über ein ActiveX Control die Daten des LAN abfragen. Linux/*BSD kann man
bitten, ein kleines Shellskript auszuführen, denn die wissen ja ohnehin,
was ifconfig macht und was dessen Output zu bedeuten hat ;-) Über ein
Eingabefeld des Webformulars muss dann eben eine Angabe zum LAN gemacht
werden. Da kann man dann genauso ein .deb oder .rpm Paket erzeugen.
Theoretisch könnte man auf diesem Wege gleich noch die VoIP Anwendung
mitliefern.
Bei einer kleinen ueberschaubaren Installation mit 20 Teilnehmern kann man
sich da noch leicht absprechen. Ein leichter einfacher Start, das ist auch
gut. Fuer sicher genug halte ich openVPN auch.
Langfristig halte ich es nicht sinnvoll einen eigenen Tunnel nur fuer
Sprachvermittlung aufbauen zu muessen, aber das hat jetzt hier mit diesem
Test nichts zu tun.
fuer Anwender -- Hoerer nehmen, waehlen, telephonieren
Das geht auch bei ISDN nicht so einfach, jedenfalls bei vielen ISDN
Telefonen.
sollte es aber
fuer Admins -- ein Alptraum, das wird nicht einfach, das umzusetzen macht
mehr Spass als es zu dokumentieren
Das ist schon ein eigenes Projekt, das ist allerdings auch nicht
Gegenstand des Experiments. Das Projekt soll weder Skype noch der T-Com
Konkurrenz machen - lol. Es geht doch nur um ein Proof-of-Concept, dass
ein kleines, verschlüsseltes Telefonnetz machbar ist. In Zahlen:
3-4 Asterisk Server
ca. 20 User
Im Wiki werden folgende Themen behandelt:
* Konfiguration von OpenSwan
* Anleitung zum Erstellen von X.509 Certs
* Link zum CA Server, da kann man das dann signieren lassen
* IP-Adressplan
* Dialplan
Das wird interessant.
cu Frank
--
Experience is the worst teacher. It always gives the test first and
the instruction afterward.
--
----------------------------------------------------------------------------
PUG - Penguin User Group Wiesbaden - http://www.pug.org
