OpenVPN - kein Zugriff

Hallo Tobias,
du kannst auf vServern (mit OpenVCP) keine IP-Adressen oder Routen setzen. Somit funktioniert das von dir angedachte vorhaben nicht. Was du machen kannst, ist vom Support ein fixes tun-Device mit einer festen IP-Adresse einrichten lassen. Damit kannst du dann immerhin eine P2P-Verbindung über OpenVPN aufbauen. Details dazu findest du in älteren Threads hier im Forum.

Normal wäre ein "client-to-client" beim Server fällig, damit sich die Clients gegenseitig fnden.

Aber wie gesagt: Es geht nicht auf netcup-servern.

Generell sollte man bei der Virtualisierung, die Netcup nutzt, auf openVPN verzichten. Es kostet nur Geld, das tun-Device anlegen zu lassen und die typischen Anwendungen funzen doch nicht.

Kommt drauf an. Einen OpenVPN-Server kann man wie gesagt nicht einrichten, für manche Anwendungszwecke tut aber auch eine P2P-Verbindung ihren Dienst. Wenn ich z.B. lediglich eine P2P-Verbindung zu einem anderen Master-Server benötige, um verschlüsselt auf SQL-DB, Syslog etc. des Hauptservers zuzugreifen, ist so ein P2P-VPN schon ganz praktisch.

Wenn man einzelne TCP-Verbindungen verschlüsseln möchte haben sich auch die guten alten SSH-Tunnel bewährt.
http://www.wh-netz.de/knowledgebase/SSH-Tunnel
Zusammen mit Tools wie z.B. AutoSSH lässt sich damit auch auf höheren Schichten ein zuverlässiger Tunnel aufbauen. Kommt eben immer auf den konkreten Anwendungsfall an. SSH ist schnell und einfach, tunnelt jedoch nur gezielte TCP-Verbindungen, keine kompletten IP-Adressen. Für UDP-Traffic ist OpenVPN Pflicht.

Zitat

lediglich eine P2P-Verbindung zu einem anderen Master-Server benötige, um verschlüsselt auf SQL-DB, Syslog etc. des Hauptservers zuzugreifen

SSH-Tunnel: kostenlos
tun-Device: 20€

Wie du schon sagtest, dafür gibt es SSH-Tunnel.

Was es an UDP-Traffic gibt, den man verschlüsseln muss, weiß ich jetzt aus dem Stegreif nicht. Aber für den Fall: "netcat" heißt das Stichwort.

Szenario: Man möchte aus unerfindlichem grund unbedingt UDP für DNS verwenden:

# Server A:
netcat -u -L 
[Listen-IP]:53 -t -p 65453
ggf. ssh -L 65453:localhost:65453 [user]@[Server B]




# Server B:
netcat -t -L 127.0.0.1:65453 -u -p 53
ggf. ssh -R 65453:localhost:65453 [user]@[Server A]

Was mich zu dem Thema mal interessieren würde, wären genauere Studien bezüglich des Overheads.
Eine weitere Möglichkeit zum Tunneln von TCP-Verbindungen wäre über SSL mittels stunnel. Bei dieser Lösung fand ich es jedoch äußerst unschön, dass bei jeder neuen TCP-Verbindung ein kompletter SSL-Handshake mit Zertifikatsaustausch etc. durchgeführt werden muss.
SSH gefällt mir da schonmal deutlich besser, wobei ich immer noch nicht ganz genau sagen kann, wie hoch der Overhead z.B. bei mehreren simultanen TCP-Verbindungen ausfällt, wie es sich mit der Segmentierung verhält (MTU) usw.
OpenVPN ist in dieser Hinsicht am elegantesten, weil es etwas tiefer ansetzt und nach dem einmaligen Verbindungsaufbau nur noch ein marginaler Overhead hinzukommt, sowie sich die entsprechend geringere MTU direkt über das tun-Device einstellen lässt.

Zitat

Was es an UDP-Traffic gibt, den man verschlüsseln muss, weiß ich jetzt aus dem Stegreif nicht.

Spontan fällt mir dazu klassisches Syslog ein. Da verwende ich gerne einen zentralen Syslog-Server. Wobei man auch wieder dazu sagen muss, dass z.B. Rsyslog mittlerweile wahlweise ebenfalls TCP verwenden kann, so dass sich auch das via SSH tunneln lässt. DNS verwende ich zwischen den Servern nur für den Zonentransfer, und das geschieht ja ebenfalls über TCP. In sofern hast du Recht, dass UDP in dieser Hinsicht eine eher unbedeutende Rolle spielt. Multimedia-Anwendungen wie VoIP würde wohl niemand zwischen vServern tunneln wollen.

Bleibt wohl als letzter Punkt: Ein einziger OpenVPN-Daemon sieht schöner aus als zig SSH-Instanzen plus jeweils ein AutoSSH-Daemon.

Zitat

Multimedia-Anwendungen wie VoIP würde wohl niemand zwischen vServern tunneln wollen.

Naja, jetzt, wo du es sagst: Meine SIP-Verbindungen dürften gerne ne Verschlüsselung abbekommen. Schließlich werden user+pw im Plaintext übertragen. Und mit den Daten könnte man schon Mist bauen (z.B. meine telefonrechnung in den 4-stelligen Bereich treiben).

Zitat

Bleibt wohl als letzter Punkt: Ein einziger OpenVPN-Daemon sieht schöner aus als zig SSH-Instanzen plus jeweils ein AutoSSH-Daemon

Man kann für eine Instanz mehrere Tunnels erstellen. Sieht man auch bei autossh, wo der benutzte Tunnel und die 2 "Kontroll"-Tunnel in einem Rutsch angelegt werden. Aber dann gilt auch "Alles oder gar nichts".

Naja, ich will openVPN seinen praktischen Nutzen auch in keinster Weise absprechen. Hätte mein netcup-Server ein tun-Device, würde ich es auch gerne nutzen. Hat er aber nicht und 20€ sind 2,5 Monatsmieten des Servers. Das ist etwas unverhältnismäßig... :p

Zum Overhead: Ich meinte mal gehört zu haben, dass da sogar ein "Blindstrom" fließt, damit man an den Intervallen und der Menge der Daten keinen Rückschluss ziehen kann.
Falls du jetzt wegen Traffic meinst...

Zitat

Naja, jetzt, wo du es sagst: Meine SIP-Verbindungen dürften gerne ne Verschlüsselung abbekommen. Schließlich werden user+pw im Plaintext übertragen. Und mit den Daten könnte man schon Mist bauen (z.B. meine telefonrechnung in den 4-stelligen Bereich treiben).

Da helfen auch einfachere Mittel. SIP lässt sich nämlich optional auch von Haus aus TLS verschlüsseln - nennt sich SIP over TLS und besteht prinzipiell aus einem TCP SIP, welches in einem TLS-Tunnel verpackt wird; natürlich sofern es Server und Client unterstützen. Asterisk und OpenSER unterstützen beide SIP over TLS. Da braucht's dann gar keinen extra Tunnel-Daemon. Bleibt nur zu hoffen, dass alle deine Geräte vom Telefon über den vServer bis hin zum SIP-Provider SIP/TLS unterstützen; sonst musst du irgendwo in dieser Kette doch wieder auf Klartext zurück greifen.

Nachtrag: Interessate Lektüre zu dem Thema
http://www.site.uottawa.ca/~bo…tAuthenticationReport.pdf

Darin wird auch auf MD5 Digest Authentification eingegangen. In wie fern MD5 Digest aber in der SIP-Praxis verwendet bzw. unterstützt wird, da muss ich passen.

Naja, gut, MD5 Digest nutze ich antürlich.

Nur ist eine verschlüsselte Verbindung zum einen zwischen Telefonserver und den SIP-Anbietern afaik nicht möglich, von manchen meiner Clients (u.a. das Siemens C475IP) ebenfalls nicht.

Was ich eben auch nicht mag, ist, dass der Media-Stream ebenfalls unverschlüsselt läuft. D.h., dass die PIN-Eingabe per Tonwahlverfahren ebenfalls belauscht werden könnte.

Naja, nützt nichts, es gibt größere Sicherheitslecks. Mein Telefonguthaben ist limitiert und kritische Daten kann man auch nicht per Telefon abfragen, das ist alles beschnitten.

Zu der ganzen Sache mit dem tun-Device in Verbindung mit OpenVPN gibt es hier im Forum schon mehrere Threads. Hätte man u.U. auch vor dem Kauf finden können.

Du hast eben keinen Server mit einer vollwertigen HW/SW-Umgebung, sondern eine virtualisierte Umgebung. Zur Realisierung einer Virtualisierung gibt es nun viele verschiedene Ansätze.

• Linux-vServer/OpenVCP (netcup)

Sämtliche Gastsysteme teilen sich den Kernel des Wirtssystems. Darunter fallen auch Kernel Ressourcen wie z.B. Routen u.v.a. Diese Art der Virtualisierung ist relativ effizient, bringt aber für die Gastsysteme auch die ein oder andere Einschränkung mit.

• Virtuozzo (HostEurope, Server4You, u.v.a. "große" Anbieter)

Kommerzielle Lösung, tun-Device muss explizit vom Admin des Wirtssystems freigegeben sein. Ist dies der Fall, lässt sich OpenVPN wie gewohnt nutzen.

• XEN

Der Kernel des Gastsystems wird mit XEN gepatched, man erhält anschließend eine virtuelle Umgebung, die sich fast wie ein echter Server anfühlt. Das tun-Modul wird per modprobe geladen, das tun-Device angelegt, und mittels ifconfig und route konfiguriert. Der Administrationsaufwand von XEN ist etwas höher, da ein spezieller XEN-Kernel verwendet werden muss.

• KVM

Neuster Sprößling aus der Familie der Virtualisierungstechniken. Wurde mittlerweile in den Mainstream-Kernel aufgenommen und wird daher offiziell vom Linux-Kernel unterstützt. Es wird eine CPU mit Virtualisierungstechnik auf dem Wirtssystem benötigen. KVM kann anschließend beliebige Gast-Betriebssysteme ohne Modifikation virtualisieren. Das Gastsystem sieht einen nahezu "echten" Server, d.h. u.a. eine frei partitionierbare Festplatte, und muss auch einen kompletten Linux-Kernel, Bootloader etc. mitbringen. Dadurch dass jedes Gastsystem seinen eigenen Kernel mitbringen muss entsteht bei vielen gleichen Gastsystemen ein gewisser Overhead. Dafür hat man innerhalb des Gastsystems große Freiheiten.

=> Es gibt nicht die Virtualisierungslösung, sondern viele verschiedene. Jeder Provider hat hier so seine eigenen Vorlieben. Genauso kann man nicht sagen, A wäre generell besser oder schlechter als B. Sie haben alle ihre Vor- und Nachteile. Wenn man spezielle Wünsche hat, lohnt es sich jedoch, sich vor dem Kauf eines vServer über die eingesetzte Virtualisierungstechnik (und deren Grenzen) zu informieren.

Zu deiner Frage mit dem tun-OpenVPN Einsatzzweck: Wie gesagt, P2P-Verbindungen sind möglich. Wenn du also exakt zwei Server hast, du die miteinander verbinden willst, so funktioniert das. Was nicht funktioniert sind mehrere Verbindungen, z.B. über den "server"-Modus von OpenVPN. Also um z.B. einen Netcup-vServer als Slave an einen anderen Master-Server anzukoppeln (z.B. für MySQL-Replikationen, zentrales Logging, uva.) ist die P2P-Lösung durchaus praktikabel.
Was nicht funktioniert, ist eine Point to Multipoint Lösung, also das sich dein Netcup-vServer zu mehreren anderen Servern via VPN verbindet.

Und ob man VoIP über TCP in SSH tunneln möchte, ist vermutlich Geschmackssache. Der RTP-Datenstrom besteht aus vielen winzigen UDP-Paketen. Jedes einzelne dieser Pakete nun in ein TCP-Paket zu verpacken, und vorallem jedes einzelne Paket via TCP-ACK bei der Übertragung bestätigen zu lassen, Retransmission bei Packet Loss usw... Ich denke es gibt schon gute Gründe für UDP und gegen TCP bei VoIP.

Als Alternative würde ich es nicht zwangsläufig in einen SSH-Tunnel packen, sondern eher versuchen, die VoIP-Verbindung direkt in der Applikation zu verschlüsseln.

Wenn du Asterisk und dessen IAX-Protokoll verwendest, so bringt Asterisk bereits alles notwendig mit, um ohne irgendwelchen zusätzlichen Aufwand den Datenstrom zu verschlüsseln.

http://www.voip-info.org/wiki/view/IAX+encryption

Die Authentifizierung kann über einen MD5-Hash geschehen, und der gesamte Datenstrom lässt sich via AES verschlüsseln.

"After successful (md5) authentication the whole channel including control data and voice data is encrypted with AES128."

Ich persönlich würde auf jeden Fall diese Lösung bevorzugen.

Ein kleiner Nachtrag zu deiner netten Liste:

virtuozzo hat einen "Ableger": openVZ.
Bei dem gelten die gleichen Beschränkungen / Features wie bei virtuozzo, nur ist es kostenlos.
Mein vServer, den ich mit openVPN nutze, läuft auf openVZ.

Zitat

Wo hast Du denn diesen vserver?

Das darf ich dir hier nicht sagen