Frank Boehm schrieb: > Das ist moeglich, aber wofuer soll ein weiterer GRE Tunnel aufgebaut > werden, > nachdem es bereits einen IPsec Tunnel gibt, das erscheint bis jetzt nach > der > 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. Im Falle des GRE Tunnels muss IPsec nur die beiden Loopbacks kennen, über den GRE Tunnel kann praktisch wie über eine physikalische Verbindung geroutet werden. Selbst IP basierte Routingprotokolle funktionieren darüber. Der Mehraufwand ist minimal, dafür spart man sich später im Falle von Erweiterungen eine ganze Menge Stress. Das dynamische Routing kann man später immer noch aufsetzen.
> Einen OpenVPN Tunnel zu nehmen, der selbst von einfachen billig Routern > seine Pakete via Portforwarding bekommt, ist auch wesentlich einfacher > einzurichten. Das ist allerdings die Frage. OpenVPN ist zwar sicher, aber wie sieht es mit den Latenzzeiten aus ? Das fällt zwar bei einem DSL Anschluss eines Users nicht so ins Gewicht, aber bei 2 Servern, die sonst 1ms RTT haben, merkt man das schon. Bei meinen Versuchen hat das IPsec besser abgeschnitten, weiterhin sind an diesem VPN-Backbone auch Ciscos beteiligt, die nun einmal kein OpenVPN können. > Die laut laermenden Cisco Router hab ich aus gutem grund meistens > ausgeschaltet, ausser fuer mein Testlab. Musst ja kein Cisco nehmen, kann aber sein, dass auf der anderen Seite ein Cisco steht... > 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. > Das waere kein Problem mehr, sobald ein Routingprotokoll laeuft. Selbst bei > RIP waeren innerhalb kurzer Zeit zumindest jeder wieder erreichbar. 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. > die besten Latenzzeiten und Sprachqualitaet hatte man bei einem full > meshed net, wo es zu jedem anderen Teilnehmer auch einen Tunnel gibt Das macht RTP sowieso, SIP wird eh nur zur Signalisierung verwendet. Der Name Open Shortest Path First ist bei dem gleichnamigen Routingprotokoll auch kein Zufall ;-) Die IP-Pakete werden sich bei richtiger OSPF Konfiguration dann den kürzesten Weg suchen, wobei das dann hoffenlich auch der Weg mit den kürzesten Latenzzeiten ist. > wenn die etwas selbst einstellen aendern muessten, waere IMHO etwas falsch > gelaufen in der Planung, IP-Telephon Hoerer abnehmen und waehlen, um den > Rest sollten die sich nicht kuemmern brauchen. Der User muss irgendwie eine Verbindung zum VPN aufbauen. Das geht wohl nur durch die Installation von OpenVPN. Ich hoffe jetzt nicht, dass hier eine Windows User PPTP verwenden will, ansonsten braucht man erst garnicht zu verschlüsseln - naja, vielleicht etwas hart ausgedrückt. Weiterhin wird sich ein User sicher mit SIP connecten wollen, es gibt bisher nur weige Telefone, die auch IAX2 können. > Wenn das unterm Strich nicht mind. genauso einfach wie Skype laeuft, und > das > wird die Messlatte sein, wird es im Praxistest durchfallen. Warum man > lieber > keinen Skype nehmen sollte, wird jeder der an so einem Versuch teilnimmt > schon wissen, aber ein wichtiges Ziel sollte es sein, dass genauso > einfach zu gestalten. 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. > fuer Anwender -- Hoerer nehmen, waehlen, telephonieren Das geht auch bei ISDN nicht so einfach, jedenfalls bei vielen ISDN Telefonen. > 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 > voip Telephon Software geht auch, selbst fuer Windows gaebe es mit Xen ein > einfaches, oder ekiga (ehemals gnomemeeting) gibt es fuer linux und > windows. Letzlich kann der User da anschließen, was er will. Ob das jetzt ein WLAN VoIP Telefon, eine Fritzbox oder sonst ein IP-Telefon oder Anwendung ist, tut nichts zur Sache. Das Teil muss einfach nur SIP können. Die Besonderheiten beginnen eigentlich erst am Router. OpenWRT ist da sicher eine gute Wahl. Ansonsten eben eine PC Distri. > Die Liste verfolge ich aus Koeln, ein Treffen wird da schwieriger, aber > fuer > koennten uns auch zu verabredeten Zeiten in einem IRC channel treffen. Die Mailingliste ist da sicher eine gute Wahl. IRC wird interessant, wenn es an die Installation geht. Bis zum Wochenende werde ich im Wiki einen Vorschlag zum IP-Adressplan und zum Dialplan machen. Da wohl keine Verbindung zum öffentlichen Netz erfolgen soll, kann man einfach den Dialplan der T-Com übernehmen, d.h. Vorwahlen wie folgt: FFM: 69 CGN: 221 Andere Vorwahlen hängen dann vom Standort des Servers ab. MUC hätte dann die 89. 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 ist natürlich keine endgültige Fassung, sondern nur ein Vorschlag. Ist ja bei einem Wiki kein Problem ein Update zu machen. Grüße Christian -- ---------------------------------------------------------------------------- PUG - Penguin User Group Wiesbaden - http://www.pug.org
