Keine Lösung vom S4Y Support, aber ein Workaround
Also, die Antwort von S4Y zusammengefasst: Wir installieren das iptables-NAT Modul nicht in ihrer VPS. Habe für den interssierten Leser weiter unten den Support Ticket Trail angehängt.
Inzwischen habe ich einen Workaround gefunden, der für mich funktioniert, allerdings recht hässlich ist. Meine Lösung besteht darin, eine virtuelle Maschine in qemu zu installieren, deren virtuelles Ethernet Interface eth0 per qemu -user-net Option auf venet0:0 genat'ed wird. Innerhalb der virtuellen Maschine läuft eine Basis-Debian Installation, die vollen tun-support und alle iptables-Kernelmodule besitzt. Innerhalb der VM läuft mein openvpn-Server. Per qemu -redir Option leite ich eingehenden tcp-Verkehr zum vServer an Port 1194 (den OpenVPN port) auf den selben Port innerhalb der virtuellen Maschine weiter, unter dem openvpn innerhalb der VM läuft. Den privat adressierten Traffic, der am tun-Interface innerhalb der VM ankommt, nat'e ich dann per iptables auf eth0, welches qemu dann auf venet0:0 im vServer nat'ed.
Das Konzept funktioniert, weil qemu (eine OpenSource Virtualisierungssoftware ähnlich VMWare) keine Kernel-Module laden muss, d.h. problemlos auch in einem Virtuozzo vServer läuft. Weiterhin hat qemu eine zwar simpel gestrickte, aber funktionale virtuelle Netzwerkemulation mit virtueller Firewall, DNS und DHCP Server eingebaut (die durch die genannte user-net Option aktiviert wird), welche komplett in Userland läuft, also NICHT auf die iptables/netfilter Schicht des vServer-Kernels zugreifen muss. Die Interfaces des virtuellen qemu-Netzes sind im vServer völlig unsichtbar. Aus vServer-Sicht öffnet der qemu-Prozess Sockets auf venet0:0, so wie z.B. ein Webrowser. Wenn man den Gedanken weiterspinnt, so muss man noch nicht einmal tun/tap Support im vServer haben, da ja opevpn in der VM läuft, nicht auf dem vServer. D.h. die Lösung müsste auch auf dem normalen S4Y vServer (=! RootDS) funktionieren.
Einschränkungen:
a) Die virtuelle Firewall unterstützt nur tcp und udp-Verkehr, icmp ins Internet (ping) funktioniert nicht. Ist für mich aber keine grosse Einschränkung, da die Applikationen, die ich verwende, alle tcp oder udp-basiert sind
b) Performance: Der erzielbare OpenVPN-Durchsatz ist nicht atemberaubend. Das Konstrukt "VM auf emulierter Hardware innerhalb eines vServer" ist schon mal ein limitierender Faktor, besonders wenn RAM auf dem vServer knapp ist. Als Daumenwert habe ich habe so ca. 15kbyte/sec Durchsatz geschafft, allerdings aus einem Netzwerk in Australien, getunnelt durch einen ziemlich lahmen Proxy. Es könnte also je nach Gesamtkonfiguration auch mehr drin sein.
Viel Spass beim Basteln!
Support-Ticket Trail:
==========================================================
Habe auf meinem RootDS OpenVPN eingerichtet und muss als letzten Schritt nur noch das tun-interface auf venet0:0 nat'en. Der übliche iptables Befehl (iptables -t nat -A POSTROUTING -s 192.168.30.0/24 -o venet0:0 -j MASQUERADE) funktioniert nicht, da das Kernel-Modul für den 'nat' Table nicht vorhanden ist. Was tun?
Mit freundlichen Grüssen,
xxx
Kunde
19.11.05 - 09:00:14 Unter
http://faq.swsoft.com/article_117_746_en.html wird beschrieben, wie man iptables innerhalb einer VPS einschaltet. Hier findet sich der folgende Befehl zum Freischalten bestimmter iptables Module innerhalb einer bestimmten VPS:
# vzctl set 101 --iptables iptable_filter --iptables ipt_length --iptables ipt_limit --iptables iptable_mangle --iptables ipt_REDIRECT --iptables ipt_REJECT --iptables iptable_nat --iptables ipt_state --iptables ip_conntrack --save
Dieser Befehl impliziert, dass das nat-Modul (iptable_nat) verfügbar ist.
sjansen
22.11.05 - 18:07:05 Sehr geehrter Herr xxx,
mir ist bislang keine VPN-Konfiguration bekannt, wo ein Network Address Translation des TUN-Devices notwendig wäre.
Da an Ihrem vServer kein Privates Netz 192.168.30.0/24 angebunden ist, wird die Regel
iptables -t nat -A POSTROUTING -s 192.168.30.0/24 -o venet0:0 -j MASQUERADE
auch keine Wirkung haben.
Die NAT und MASQ Module von IPTables sind in den Kernel nicht eingebunden, da bei einem vServer diese ohnehin nicht nutzbar sind.
Mit freundlichen Grüßen
Sven Jansen
Kunde
25.11.05 - 04:51:50 Sehr geehrter Herr Jansen,
danke für Ihre Ausführungen. Die VPN-Konfiguration, die ich aufsetzen möchte, ist ein sehr gängiges Szenario: Der (privat adressierte) Traffic aus dem VPN wird auf dem VPN-Server (dem Egress) ins Internet geroutet. In meinem Szenario fungiert der vServer als VPN-Server. Deshalb ist auch NAT von tun auf venet0:0 notwendig. Ohne die NAT-Umstetzung findet sonst der Traffic nicht mehr den Weg zurück aus dem Internet in mein VPN.
Virtuozzo unterstützt ab Version 2.6 das iptable_nat Modul (wie sie auch in meiner vorigen Antwort sehen können) und kann somit entgegen Ihrer Aussage natürlich auch innerhalb eines vServers genutzt werden. Die Möglichkeit, tun-Interfaces innerhalb eines vServers zu erzeugen impliziert für mich, dass ich auch den Traffic zwischen den Interfaces mittels iptables kontrollieren kann - ohne das nat-Modul kann ich das nur eingeschränkt.
Sie müssen also das iptable_nat Modul nur mit dem entsprechend vzctl-Befehl in meiner VPS freischalten. Darum würde ich Sie bitten, denn ohne die NAT-Funktionalität ist der rootDS für mich wertlos.
Mit freundlichen Grüssen,
xxx
sjansen
25.11.05 - 18:15:35 Sehr geehrter Kunde,
unsere Server sind für das Tunneln von fremden Traffic nicht hervorgesehen, weshalb wir Ihnen auch die nötigen Tools dafür leider nicht bereitstellen können.
Mit freundlichen Grüßen
Sven Jansen
