This article describes how to use VPN via the TUN/TAP device inside a container.
Contents
Kernel TUN/TAP support
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:
Make sure the tun module has been already loaded on the hardware node:
# lsmod | grep tun
If it is not there, use the following command to load tun module:
# modprobe tun
To make sure that tun module will be automatically loaded on every reboot you can also add it or into /etc/modules.conf (on RHEL see /etc/sysconfig/modules/ directory) or into /etc/sysconfig/vz-scripts/CTID.mount. (echo 'modprobe tun' >> /etc/sysconfig/vz-scripts/CTID.mount)
Granting container an access to TUN/TAP
Allow your container to use the tun/tap device by running the following commands on the host node:
vzctl set 101 --devices c:10:200:rw --save vzctl set 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
Configuring VPN inside container
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 box.
The following software can be used for VPN with TUN/TAP:
- Tinc (http://tinc-vpn.org)
- OpenVPN (http://openvpn.net)
- Virtual TUNnel (http://vtun.sourceforge.net)
Reaching hosts behind VPN container
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.
With a VENET interface you will only reach the VPN container.
To use a VETH device follow this instructions: http://wiki.openvz.org/Veth
Tinc problems
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.
Netstat shows that the port 655 is available:
root@132 / [3]# netstat -l Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State tcp 0 0 localhost.localdom:8001 *:* LISTEN tcp 0 0 *:2223 *:* LISTEN tcp6 0 0 [::]:2223 [::]:* LISTEN udp6 0 0 [::]:talk [::]:* udp6 0 0 [::]:ntalk [::]:* Active UNIX domain sockets (only servers) Proto RefCnt Flags Type State I-Node Path unix 2 [ ACC ] STREAM LISTENING 4831020 /var/run/uml-utilities/uml_switch.ctl
Starting the Tincd daemon where it complains that port 655 is not available:
root@132 / [4]# tincd -n myvpn root@132 / [5]# tail -f /var/log/syslog Jul 26 14:08:01 132 /USR/SBIN/CRON[15159]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly) Jul 26 14:37:42 132 -- MARK -- Jul 26 14:57:42 132 -- MARK -- Jul 26 15:08:01 132 /USR/SBIN/CRON[15178]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly) Jul 26 15:11:23 132 tinc.myvpn[15139]: Got TERM signal Jul 26 15:11:23 132 tinc.myvpn[15139]: Terminating Jul 26 15:11:37 132 tinc.myvpn[15191]: tincd 1.0.8 (Aug 14 2007 13:51:23) starting, debug level 0 Jul 26 15:11:37 132 tinc.myvpn[15191]: /dev/net/tun is a Linux tun/tap device (tun mode) Jul 26 15:11:37 132 tinc.myvpn[15191]: Can't bind to 0.0.0.0 port 655/tcp: Address already in use Jul 26 15:11:37 132 tinc.myvpn[15191]: Ready ^C root@132 / [6]#
An echo to Bindv6only (see discussion here) seems to resolve the problem:
root@132 / [12]# echo 1 > /proc/sys/net/ipv6/bindv6only
Or put in your /etc/sysctl.conf file:
net.ipv6.bindv6only = 1
Then apply the changes with:
root@132 / [14]# sysctl -p
Troubleshooting
If NAT is needed within the VE, this error will occur on attempts to use NAT:
# iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o venet0 -j 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.
The solution is given here:
http://kb.parallels.com/en/5228
Also see page 69-70 of:
http://download.openvz.org/doc/OpenVZ-Users-Guide.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.