594
edits
Changes
m
<pre># lsmod | grep tun</pre>
To make sure that '''tun''' module will be automatically loaded on every reboot you can also add it or into == Granting container an access to TUN/etc/modules.conf (on RHEL see /etc/sysconfig/modules/ directory) or into /etc/sysconfig/vzTAP == <!--T:6--scripts/''CTID''.mount. (echo 'modprobe tun' >> /etc/sysconfig/vz-scripts/''CTID''.mount)
== Granting container an access to TUN/TAP ==<!--T:7-->
vzctl set 101 <!--devices c:10:200T:rw 8--save> vzctl set CTID=101 --capability net_admin:on --save And create the character device file inside the container (execute the following on the host node): vzctl exec 101 mkdir -p /dev/net vzctl exec 101 mknod /dev/net/tun c 10 200 vzctl exec 101 chmod 600 /dev/net/tun Make vzctl recreate device node on container startup: vzctl set 101 $CTID --devnodes net/tun:rw --capability net_admin:on --save
# iptables <!-t nat -A POSTROUTING T:28-s 10.8.0.0/24 -o venet0 -j MASQUERADE><pre># tunctl iptables v1.4.3.2: can't initialize iptables table `nat'enabling TUNSETPERSIST: Table does Operation not exist (do you need to insmod?)permitted Perhaps iptables or your kernel needs to be upgraded.</pre>
The solution is given <!--T:29-->Get a patched tunctl [https://github.com/xl0/uml-utilities here:], and run it with the -n option. It will create a non-persistent tun device and sleep instead of terminating, to keep the device from deletion. To remove the tunnel, kill the tunctl process.
http://kb.parallels.com/en/5228
Also see page 69== Troubleshooting == <!-70 of-T:30-->If NAT is needed within the VE, this error will occur on attempts to use NAT:
http<!--T://download31--># iptables -t nat -A POSTROUTING -s 10.8.openvz0.org/doc0/OpenVZ24 -Userso venet0 -Guidej MASQUERADE iptables v1.4.3.2: can't initialize iptables table `nat': Table does not exist (do you need to insmod?) Perhaps iptables or your kernel needs to be upgraded.pdf
Note that the above steps do not solve the problem if a gentoo VE sits on a Centos HN; it's still an unsolved mystery.<!--T:32-->Solution:* use recent kernel* enable NAT inside CT:: <code>vzctl set $CTID --netfilter full --save</code>
<translate>
<!--T:1-->
This article describes how to use VPN via the TUN/TAP device inside a [[container]].
== Kernel TUN/TAP support ==<!--T:2-->
OpenVZ supports VPN inside a container via kernel TUN/TAP module and device.
To allow container #101 to use the TUN/TAP device the following should be done:
<!--T:3-->
Make sure the '''tun''' module has been already loaded on the [[hardware node]]:
<!--T:4-->
If it is not there, use the following command to load '''tun''' module:
modprobe tun <pre!--T:5--># modprobe To make sure that '''tun''' module will be automatically loaded on every reboot you can also add it or into <code>/etc/modules.conf</code> (on RHEL see <code>/etc/sysconfig/modules/</precode>directory).
Allow your container to use the tun/tap device by running the following commands on the host node:
== Configuring VPN inside container ==<!--T:9-->
After the configuration steps above are done it is possible to use VPN software working with TUN/TAP inside
container just like on a usual standalone linux Linux box.
<!--T:10-->
The following software can be used for VPN with TUN/TAP:
* Tinc (http://tinc-vpn.org)
* Virtual TUNnel (http://vtun.sourceforge.net)
== Reaching hosts behind VPN container ==<!--T:11-->
In order to reach hosts behind VPN container you must configure it to use a VETH interface instead a VENET one, at least with an OpenVPN server.
<!--T:12-->
With a VENET interface you will only reach the VPN container.
<!--T:13-->To use a VETH device follow this [http[Veth]] article. <!--T://wiki14-->If you insist on using a VENET interface and need to reach hosts behind the OpenVPN VE then you can use source NAT.openvz.org/Veth instructions]You need to mangle source packets so that they appear to originate from the OpenVPN server VE.
== Tinc problems ==<!--T:15-->
<!--T:16-->
Using the default venet0:0 interface on the container, tinc seems to have problems as it complains the port 655 is already used on 0.0.0.0.
<!--T:17-->
Netstat shows that the port 655 is available:
<!--T:18-->
<pre>
root@132 / [3]# netstat -l
</pre>
<!--T:19-->
Starting the Tincd daemon where it complains that port 655 is not available:
<!--T:20-->
<pre>
root@132 / [4]# tincd -n myvpn
</pre>
<!--T:21-->
An echo to Bindv6only (see [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=440150 discussion here]) seems to resolve the problem:
<!--T:22-->
<pre>
root@132 / [12]# echo 1 > /proc/sys/net/ipv6/bindv6only
</pre>
<!--T:23-->
Or put in your /etc/sysctl.conf file:
<!--T:24-->
<pre>
net.ipv6.bindv6only = 1
</pre>
<!--T:25-->
Then apply the changes with:
<!--T:26-->
<pre>
root@132 / [14]# sysctl -p
</pre>
== Troubleshooting The tunctl problem ==<!--T:27-->If NAT is needed within the VEUnfortunately, this error will occur on attempts you are limited to use NAT[http://forum.openvz.org/index.php?t=msg&th=4280&goto=22066&#msg_22066 non-persistent tunnels inside the VEs]:
== External links ==<!--T:33-->
* [http://vtun.sourceforge.net Virtual TUNnel]
* [http://openvpn.net OpenVPN]
* [http://tinc-vpn.org Tinc]
* [http://openvpn.net/index.php/access-server/howto-openvpn-as/186-how-to-run-access-server-on-a-vps-container.html How to run OpenVPN Access Server in OpenVZ]
* [http://kb.parallelsodin.com/en/696 Parallels Odin KB#696: Is VPN via the TUN/TAP device supported inside a Container?]</translate>
[[Category: HOWTO]]
[[Category: Networking]]
