OpenVZ Virtuozzo Containers Wiki - User contributions [en]

User:Guaka

2022-02-09T16:42:08Z

Guaka:

[https://guaka.org/]

User:Guaka

2009-04-09T16:15:50Z

Guaka: My contributions on this wiki are public domain.

[http://guaka.org/ Kasper Souren]

My contributions on this wiki are public domain.

Talk:Using NAT for container with private IPs

2009-04-08T14:03:36Z

Guaka: "Usually you supply public IP addresses to your containers"? How? ~~~~

I was stumbling a lot with the configuration where allowing access to a service from outside, because I assumed that after adding the iptables DNAT rule, I could test the rule from the hardware node. The rule only works for packets send from outside.

I added some text about it now, but maybe someone could rephrase it more nicely.
----

<pre>For OpenVZ kernels later than 2.6.8, connection tracking
for VE0 is enabled by default. However, make sure there is no line like

options ip_conntrack ip_conntrack_disable_ve0=1
</pre>

It seems to me that here must be =0 ??? Or not?

[[User:Shaplov|Shaplov]] 10:27, 23 June 2007 (EDT)

----
"Usually you [[supply public IP addresses to your containers]]"? How? [[User:Guaka|Guaka]] 14:03, 8 April 2009 (UTC)

Talk:Container

2009-04-08T14:00:35Z

Guaka: New page: About the note, is it okay to replace VE by container in existing articles? ~~~~

About the note, is it okay to replace VE by container in existing articles? [[User:Guaka|Guaka]] 14:00, 8 April 2009 (UTC)

Common Networking HOWTOs

2009-04-08T13:59:37Z

Guaka: VE?

While other pages do a great job of going into the details of veth and venet networking, this page is all about getting the results you want quickly.

== Private VEs (not directly visible from the LAN) ==

When starting with a new [[VE]] that should not be directly visible on the LAN it is important to choose an appropriate IP address. By running "ifconfig -a" on the host it is possible to see all the networks the host is connected to. The VE should reside on a a new private network, choosing one of the 192.168.X.Y/24 subnets is a good choice.

For example, on a host which is already on a 192.168.1.0/24 subnet then the 192.168.2.0/24 subnet would be a reasonable choice (unless the host is already on that subnet too).

In these examples the host has eth0 with address 192.168.1.53, and 192.168.2.0/24 is free so we will give the VE 192.168.2.1. The VE (101) is assumed to be freshly created and started, with no networking currently set up.

=== Venet ===

Venet routed networking is probably the simplest to set up, simply add the IP address to the VE:

<pre>
[host-node]# vzctl set 101 --ipadd 192.168.2.1 --save
</pre>

After this the host should be able to ping the VE.

To allow the VE to access the rest of the LAN we must enable forwarding and masquerading, as all activity on the LAN must look like it is coming directly from host (with its IP address).

<pre>
[host-node]# echo 1 > /proc/sys/net/ipv4/ip_forward
[host-node]# iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
</pre>

=== Veth ===

This is a stub

== Public VEs (with their own IP addresses) ==

=== Static addresses ===

This is very similar to using private addresses, except there is no need for masquerading and the VE will be visible to others on the LAN.

In this example the host has eth0 with address 192.168.1.53, and the VE will be set up with 192.168.1.101. The VE (101) is assumed to be freshly created and started, with no networking currently set up.

<pre>
[host-node]# vzctl set 101 --ipadd 192.168.1.101 --save
[host-node]# echo 1 > /proc/sys/net/ipv4/ip_forward
</pre>

=== DHCP supplied addresses ===

For this section the following assumptions have been made:

* The host is connected to the LAN by eth0, and also uses DHCP.
* The DHCP server is another machine on the LAN.

To make the VEs truly part of the LAN it is best to create a bridge that binds them, and the LAN, together.
Configuring the host to use a bridge when it boots is distribution specific and beyond the scope of this article.
It can be done from the command line as follows:

<pre>
bring eth0 down (distro dependent)
[host-node]# /etc/init.d/net.eth0 down
-- or --
[host-node]# ifdown eth0
etc.

create the bridge
[host-node]# brctl addbr br0

add eth0
[host-node]# brctl addif br0 eth0

each bridge interface must be up, but with no ip address
[host-node]# ifconfig eth0 0

now run DHCP for the bridge (client dependent)
[host-node]# dhcpcd br0
-- or --
[host-node]# dhclient3 br0
etc.
</pre>

At this stage the host should be present on the LAN (test with pings), much as it was before, only now it is using a bridge that can have other interfaces attached to it.

Starting with a new VE (101), which should have no networking configured and be running, it is now necessary to add a veth device. First the mac address of eth0 must be determined.

<pre>
[host-node]# ifconfig eth0
...
HWaddress 00:12:34:56:78:9B
...
</pre>

Now a new mac address must be invented, preferably higher than eth0's address.

<pre>
[host-node]# easymac.sh -R
00:12:34:56:78:9A
</pre>

The new veth device can be assigned using the above information.

<pre>
[host-node]# vzctl set 101 --veth_add veth101.0,00:12:34:56:78:9A,eth0,00:12:34:56:78:9B --save
</pre>

Now add the new device to the bridge and bring it up on the host.

<pre>
[host-node]# ifconfig veth101.0 0
[host-node]# brctl addif br0 veth101.0
</pre>

Finally, the network should be fully in place, so run the DHCP client inside the VE
<pre>
[host-node]# vzctl enter 101
101# dhcpcd venet0:0
</pre>

[[Category: HOWTO]]
[[Category:Networking]]

User:Guaka

2009-04-08T13:58:41Z

Guaka: New page: [http://guaka.org/ Kasper Souren]

[http://guaka.org/ Kasper Souren]

Setting up an iptables firewall

2009-04-08T13:54:41Z

Guaka: HN?

This document consists of two parts. The first is setting up a firewall (using iptables) on the HN, which will restrict traffic to the containers. The effect would emulate, as far as the containers and their customers are concerned, an external hardware firewall controlled by the sysadmin. The second is setting up a firewall that protects the [[HN]] itself but still allows traffic to the containers, thus allowing individual containers to define their own iptables.

While the firewalls shown here can be accomplished using iptables manually (or using Fedora core's iptables service), the methods presented here are especially modular and easy to modify. This is important when you have 20+ containers and a lot of other things to be doing...

The scripts and pathnames given here are for Fedora Core 6, though they can probably be applied to most similar SysV-like systems with little modification.

== A little background ==

On our systems, we use the HN to provide privileged services which are not appropriate for access by the containers. For example, the HN acts as a backup server, runs Nagios for health monitoring, has a webserver for managing the 3ware RAID controller, etc. The containers are leased to customers, who can't entirely be trusted, especially if they get hacked. As such, our scenario is one in which the HN must be protected from all access (even from the containers) except for a few trusted hosts (e.g. my home-office).

The exception to this is the nameserver, which we want open to the world. We use it as a caching nameserver for our containers and also to host DNS for a few customer domain.

== Setting up a HN-based firewall ==

This setup emulates (to the containers anyway) an external hardware firewall. It protects the HN from any access and then defines what services and ports are allowed/banned for individual containers. This leaves the firewall controlled by the site administrator, not be individual containers and the hackers who've gotten into them. ;)

First off, let's disable Fedora's existing <code>iptables</code> service:
<pre>
service iptables stop
chkconfig iptables off
</pre>

Now create the new <code>firewall</code> service. This code should be <code>/etc/init.d/firewall</code> and then should be chmod'd 755.
<pre>
#!/bin/sh
# firewall Start iptables firewall
# chkconfig: 2345 08 92
# description: Starts, stops and saves iptables firewall
# This script sets up the firewall for the INPUT chain (which is for
# the HN itself) and then processes the config files under
# /etc/firewall.d to set up additional rules in the FORWARD chain
# to allow access to containers' services.

. /etc/init.d/functions

# the IP block allocated to this server
SEGMENT="192.168.0.0/24"
# the IP used by the hosting server itself
THISHOST="192.168.0.1"
# services that should be allowed to the HN;
# services for containers are configured in /etc/firewall.d/*
OKPORTS="53"
# hosts allowed full access through the firewall,
# to all containers and to this server
DMZS="12.34.56.78 90.123.45.67"

purge() {
echo -n "Firewall: Purging and allowing all traffic"
iptables -P OUTPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P INPUT ACCEPT
iptables -F
success ; echo
}

setup() {
echo -n "Firewall: Setting default policies to DROP"
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -I INPUT -j ACCEPT -m state --state ESTABLISHED,RELATED
iptables -I FORWARD -j ACCEPT -m state --state ESTABLISHED,RELATED
iptables -I INPUT -j ACCEPT -i lo
iptables -I FORWARD -j ACCEPT --source $SEGMENT
success ; echo

echo "Firewall: Allowing access to HN"
for port in $OKPORTS ; do
echo -n " port $port"
iptables -I INPUT -j ACCEPT -s $SEGMENT -d $THISHOST --protocol tcp --destination-port $port
iptables -I INPUT -j ACCEPT -s $SEGMENT -d $THISHOST --protocol udp --destination-port $port
success ; echo
done
for ip in $DMZS ; do
echo -n " DMZ $ip"
iptables -I INPUT -i eth0 -j ACCEPT -s $ip
iptables -I FORWARD -i eth0 -j ACCEPT -s $ip
success ; echo
done

CTSETUPS=`echo /etc/firewall.d/*`
if [ "$CTSETUPS" != "/etc/firewall.d/*" ] ; then
echo "Firewall: Setting up container firewalls"
for i in $CTSETUPS ; do
. $i
echo -n " $CTNAME CT$CTID"
if [ -n "$BANNED" ]; then
for source in $BANNED ; do iptables -I FORWARD -j DROP --destination $CTIP --source $source ; done
fi
if [ -n "$OPENPORTS" ]; then
for port in $OPENPORTS ; do iptables -I FORWARD -j ACCEPT --protocol tcp --destination $CTIP --destination-port $port ; done
for port in $OPENPORTS ; do iptables -I FORWARD -j ACCEPT --protocol udp --destination $CTIP --destination-port $port ; done
fi
if [ -n "$DMZS" ]; then
for source in $DMZS ; do iptables -I FORWARD -j ACCEPT --protocol tcp --destination $CTIP --source $source ; done
for source in $DMZS ; do iptables -I FORWARD -j ACCEPT --protocol udp --destination $CTIP --source $source ; done
fi
[ $? -eq 0 ] && success || failure
echo
done
fi
}

case "$1" in
start)
echo "Starting firewall..."
purge
setup
;;
stop)
echo "Stopping firewall..."
purge
;;
restart)
$0 stop
$0 start
;;
status)
iptables -n -L
;;
*)
echo "Usage: $0 <start|stop|restart|status>"
;;
esac
</pre>

The above script can be called like this:
<pre>
service firewall start
service firewall stop
service firewall restart
service firewall status
</pre>

It will set up the firewall for the HN according to the parameters you specified for OKPORTS, DMZs, etc. and then it will call each file under /etc/firewall.d and process its configuration.

So create a file under /etc/firewall.d The exact filename isn't important, as long as it's meaningful to you, e.g. <code>ExampleCompany</code> or <code>ve12</code> and give it content like this:

<pre>
# This file is processed by /etc/init.d/firewall
CTID="1" # the container's ID#
CTNAME="Customer1" # A human-friendly label for the container
CTIP="192.168.1.34" # the IP address for this container
OPENPORTS="80 443" # ports that should be universally opened
# to the entire Internet
DMZS="1.2.3.0/24 5.6.7.8/32" # IPs and blocks that should have full access
# to the container's services
BANNED="" # IPs and blocks that should be entirely
# blocked from the container's services
</pre>

And there you go. Go ahead and start the firewall and check its status:
<pre>
service firewall restart
service firewall status
</pre>

As you can see, you can now add and edit the configurations for individual containers very easily. This method proves a lot easier to manage than Fedora's iptables-config mechamism!

=== Debian Notes ===

The setup above works fine for Debian as well, however /etc/init.d/functions is missing. Here is a very simple version that you can use:

# /etc/init.d/functions

success() {
echo -n "...success"
}
failure() {
echo -n "...failure"
}

== Setting up a firewall that allows per-container configuration ==

This setup configures iptables on the HN to disallow access to all hosts, including the containers. However, it allows all traffic into the containers so they may define their own iptables rules and therefore manage their own firewall.

<pre>
iptables -P FORWARD ACCEPT
iptables -F FORWARD
</pre>

This will remove all rules for the FORWARD chain so all packets can pass back and forth between containers and the outside world.

If you want to use a firewall inside a container, please load these modules BEFORE starting the container:

<pre>
modprobe xt_tcpudp
modprobe ip_conntrack
</pre>

If you do not, you will get an error like this: "iptables: No chain/target/match by that name"

If you want to use stateful firewall rules (and you should!) you will also need to make sure that 'ipt_state' is in the 'IPTABLES' option in your vz.conf file:

<pre>
IPTABLES="ipt_REJECT ipt_tos ipt_limit ipt_multiport iptable_filter iptable_mangle ipt_TCPMSS ipt_tcpmss ipt_ttl ipt_length ipt_state"
</pre>

Also make sure the 'xt_state' module is loaded on the host:

<pre>
modprobe xt_state
</pre>

== See also ==

* [[Traffic accounting with iptables]]

[[Category: Networking]]