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.
