2009-06-30 17:55:19 +02:00
|
|
|
<?xml version="1.0" encoding="UTF-8"?>
|
|
|
|
|
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN"
|
|
|
|
|
"http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd">
|
|
|
|
|
<article>
|
|
|
|
|
<!--$Id$-->
|
|
|
|
|
|
|
|
|
|
<articleinfo>
|
|
|
|
|
<title>Shorewall and OpenVZ</title>
|
|
|
|
|
|
|
|
|
|
<authorgroup>
|
|
|
|
|
<author>
|
|
|
|
|
<firstname>Tom</firstname>
|
|
|
|
|
|
|
|
|
|
<surname>Eastep</surname>
|
|
|
|
|
</author>
|
|
|
|
|
</authorgroup>
|
|
|
|
|
|
|
|
|
|
<pubdate><?dbtimestamp format="Y/m/d"?></pubdate>
|
|
|
|
|
|
|
|
|
|
<copyright>
|
2009-07-05 18:09:58 +02:00
|
|
|
<year>2009</year>
|
2009-06-30 17:55:19 +02:00
|
|
|
|
|
|
|
|
<holder>Thomas M. Eastep</holder>
|
|
|
|
|
</copyright>
|
|
|
|
|
|
|
|
|
|
<legalnotice>
|
|
|
|
|
<para>Permission is granted to copy, distribute and/or modify this
|
|
|
|
|
document under the terms of the GNU Free Documentation License, Version
|
|
|
|
|
1.2 or any later version published by the Free Software Foundation; with
|
|
|
|
|
no Invariant Sections, with no Front-Cover, and with no Back-Cover
|
|
|
|
|
Texts. A copy of the license is included in the section entitled
|
|
|
|
|
<quote><ulink url="GnuCopyright.htm">GNU Free Documentation
|
|
|
|
|
License</ulink></quote>.</para>
|
|
|
|
|
</legalnotice>
|
|
|
|
|
</articleinfo>
|
|
|
|
|
|
|
|
|
|
<section>
|
|
|
|
|
<title>Introduction</title>
|
|
|
|
|
|
|
|
|
|
<para><ulink url="http://wiki.openvz.org/">Open Virtuoso (OpenVZ)</ulink>
|
|
|
|
|
is an open source kernel-based virtualization solution from
|
2009-07-02 02:30:56 +02:00
|
|
|
<trademark><ulink
|
|
|
|
|
url="http://www.parallels.com">Parallels</ulink></trademark> (formerly
|
|
|
|
|
<trademark>SWSoft</trademark>). Virtual servers take the form of
|
2009-07-05 18:09:58 +02:00
|
|
|
<firstterm>containers</firstterm> (the OpenVZ documentation calls these
|
|
|
|
|
<firstterm>Virtual Environments</firstterm> or <firstterm>VEs</firstterm>)
|
|
|
|
|
which are created via <firstterm>templates</firstterm>. Templates are
|
|
|
|
|
available for a wide variety of distributions and architectures.</para>
|
2009-06-30 17:55:19 +02:00
|
|
|
|
|
|
|
|
<para>OpenVZ requires a patched kernel. Beginning with Lenny,
|
|
|
|
|
<trademark>Debian</trademark> supplies OpenVZ kernels through the standard
|
|
|
|
|
stable repository.</para>
|
|
|
|
|
</section>
|
|
|
|
|
|
|
|
|
|
<section>
|
|
|
|
|
<title>Shorewall on an OpenVZ Host</title>
|
|
|
|
|
|
|
|
|
|
<para>As with any Shorewall installation involving other software, we
|
|
|
|
|
suggest that you first install OpenVZ and get it working before attempting
|
|
|
|
|
to add Shorewall. Alternatively, execute <command>shorewall
|
|
|
|
|
clear</command> while <ulink
|
|
|
|
|
url="http://wiki.openvz.org/Installation_on_Debian">installing and
|
|
|
|
|
configuring OpenVZ</ulink>.</para>
|
|
|
|
|
|
|
|
|
|
<section>
|
|
|
|
|
<title>Networking</title>
|
|
|
|
|
|
|
|
|
|
<para>The default OpenVZ networking configuration uses Proxy ARP. You
|
|
|
|
|
assign containers IP addresses in the IP network from one of your
|
|
|
|
|
interfaces and you are expected to set the proxy_arp flag on that
|
|
|
|
|
interface
|
|
|
|
|
(<filename>/proc/sys/net/ipv4/conf/<replaceable>interface</replaceable>/proxy_arp</filename>).</para>
|
|
|
|
|
|
2009-07-05 18:09:58 +02:00
|
|
|
<para>OpenVZ creates a point-to-point virtual interface in the host with
|
|
|
|
|
a rather odd configuration.</para>
|
2009-06-30 17:55:19 +02:00
|
|
|
|
2009-07-05 18:09:58 +02:00
|
|
|
<para>Example (Single VE with IP address 206.124.146.178):</para>
|
2009-06-30 17:55:19 +02:00
|
|
|
|
|
|
|
|
<programlisting>gateway:~# <command>ip addr ls dev venet0</command>
|
|
|
|
|
10: venet0: <BROADCAST,POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN
|
|
|
|
|
link/void
|
|
|
|
|
gateway:~# <command>ip route ls dev venet0</command>
|
|
|
|
|
206.124.146.178 scope link
|
|
|
|
|
gateway:~# </programlisting>
|
|
|
|
|
|
|
|
|
|
<para>The interface has no IP configuration yet it has a route to
|
|
|
|
|
206.124.146.178!</para>
|
|
|
|
|
|
2009-07-05 18:09:58 +02:00
|
|
|
<para>From within the VE with IP address 206.124.146.178, we have the
|
|
|
|
|
following:</para>
|
2009-06-30 17:55:19 +02:00
|
|
|
|
|
|
|
|
<programlisting>server:~ # <command>ip addr ls</command>
|
|
|
|
|
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
|
|
|
|
|
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
|
|
|
|
|
inet 127.0.0.1/8 brd 127.255.255.255 scope host lo
|
|
|
|
|
inet 127.0.0.2/8 brd 127.255.255.255 scope host secondary lo
|
|
|
|
|
inet6 ::1/128 scope host
|
|
|
|
|
valid_lft forever preferred_lft forever
|
|
|
|
|
2: venet0: <BROADCAST,POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN
|
|
|
|
|
link/void
|
|
|
|
|
inet 127.0.0.1/32 scope host venet0
|
|
|
|
|
inet 206.124.146.178/32 scope global venet0:0
|
|
|
|
|
server:~ # <command>ip route ls</command>
|
|
|
|
|
192.0.2.0/24 dev venet0 scope link
|
|
|
|
|
127.0.0.0/8 dev lo scope link
|
|
|
|
|
default via 192.0.2.1 dev venet0
|
|
|
|
|
server:~ # </programlisting>
|
|
|
|
|
|
|
|
|
|
<para>There are a couple of unique features of this
|
|
|
|
|
configuration:</para>
|
|
|
|
|
|
|
|
|
|
<itemizedlist>
|
|
|
|
|
<listitem>
|
|
|
|
|
<para>127.0.0.1/32 is configured on venet0 although the main routing
|
|
|
|
|
table routes loopback traffic through the <filename
|
|
|
|
|
class="devicefile">lo</filename> interface as normal.</para>
|
|
|
|
|
</listitem>
|
|
|
|
|
|
|
|
|
|
<listitem>
|
|
|
|
|
<para>There is a route to 192.0.2.0/24 through venet0 even though
|
|
|
|
|
the interface has no IP address in that network. Note: 192.0.2.0/24
|
|
|
|
|
is reserved for use in documentation and for testing.</para>
|
|
|
|
|
</listitem>
|
|
|
|
|
|
|
|
|
|
<listitem>
|
|
|
|
|
<para>The default route is via 192.0.2.1 yet there is no interface
|
|
|
|
|
on the host with that IP address.</para>
|
|
|
|
|
</listitem>
|
|
|
|
|
</itemizedlist>
|
|
|
|
|
|
|
|
|
|
<para>All of this doesn't really affect the Shorewall configuration but
|
|
|
|
|
it is interesting none the less.</para>
|
|
|
|
|
</section>
|
|
|
|
|
|
|
|
|
|
<section>
|
|
|
|
|
<title>Shorewall Configuration</title>
|
|
|
|
|
|
|
|
|
|
<para>We recommend handlintg the strange OpenVZ configuration in
|
|
|
|
|
Shorewall as follows:</para>
|
|
|
|
|
|
|
|
|
|
<para><filename>/etc/shorewall/zones</filename>:</para>
|
|
|
|
|
|
|
|
|
|
<programlisting>###############################################################################
|
|
|
|
|
#ZONE TYPE OPTIONS IN OUT
|
|
|
|
|
# OPTIONS OPTIONS
|
|
|
|
|
vz ipv4</programlisting>
|
|
|
|
|
|
|
|
|
|
<para><filename>/etc/shorewall/interfaces</filename>:</para>
|
|
|
|
|
|
|
|
|
|
<programlisting>###############################################################################
|
|
|
|
|
#ZONE INTERFACE BROADCAST OPTIONS
|
2009-07-05 19:08:50 +02:00
|
|
|
vz venet0 - routeback,rp_filter=0</programlisting>
|
2009-06-30 17:55:19 +02:00
|
|
|
|
|
|
|
|
<para><filename>/etc/shorewall/proxyarp</filename> (assumes that
|
|
|
|
|
external interface is eth0):</para>
|
|
|
|
|
|
|
|
|
|
<programlisting>###############################################################################
|
|
|
|
|
#ADDRESS INTERFACE EXTERNAL HAVEROUTE PERSISTENT
|
|
|
|
|
206.124.146.178 venet0 eth0 Yes</programlisting>
|
|
|
|
|
</section>
|
|
|
|
|
|
|
|
|
|
<section>
|
|
|
|
|
<title>Multi-ISP</title>
|
|
|
|
|
|
|
|
|
|
<para>If you run Shorewall Multi-ISP support on the host, you should
|
|
|
|
|
arrange for traffic to your containers to use the main routing table. In
|
|
|
|
|
the configuration shown here, this entry in /etc/shorewall/route_rules
|
|
|
|
|
is appropriate:</para>
|
|
|
|
|
|
|
|
|
|
<programlisting>#SOURCE DEST PROVIDER PRIORITY
|
|
|
|
|
- 206.124.146.178 main 1000</programlisting>
|
|
|
|
|
</section>
|
2009-07-05 18:09:58 +02:00
|
|
|
|
|
|
|
|
<section>
|
|
|
|
|
<title>RFC 1918 Addresses in a Container</title>
|
|
|
|
|
|
|
|
|
|
<para>You can assign an RFC 1918 address to a VE and use masquerade/SNAT
|
|
|
|
|
to provide Internet access to the container. This is just a normal
|
|
|
|
|
simple Shorewall configuration as shown in the <ulink
|
|
|
|
|
url="two-interface.htm">Two-interface Quick Start Guide</ulink>. In this
|
|
|
|
|
configuration the firewall's internal interface is <filename
|
2009-07-08 01:25:35 +02:00
|
|
|
class="devicefile">venet0</filename>. Be sure to include the options
|
|
|
|
|
shown above.</para>
|
2009-07-05 18:09:58 +02:00
|
|
|
</section>
|
2009-06-30 17:55:19 +02:00
|
|
|
</section>
|
|
|
|
|
|
|
|
|
|
<section>
|
2009-07-05 18:09:58 +02:00
|
|
|
<title>Shorewall in an OpenVZ Virtual Environment</title>
|
2009-06-30 17:55:19 +02:00
|
|
|
|
2009-07-05 18:09:58 +02:00
|
|
|
<para>If you have obtained an OpenVZ VE from a service provider, you may
|
|
|
|
|
find it difficult to configure any type of firewall within your VE. There
|
|
|
|
|
are two VE parameters that control iptables behavior within the
|
|
|
|
|
container:</para>
|
2009-06-30 17:55:19 +02:00
|
|
|
|
|
|
|
|
<variablelist>
|
|
|
|
|
<varlistentry>
|
|
|
|
|
<term>--iptables <replaceable>name </replaceable></term>
|
|
|
|
|
|
|
|
|
|
<listitem>
|
2009-07-05 18:09:58 +02:00
|
|
|
<para>Restrict access to iptables modules inside a container (The
|
|
|
|
|
OpenVZ claims that by default all iptables modules that are loaded
|
|
|
|
|
in the host system are accessible inside a container; I haven't
|
|
|
|
|
tried that).</para>
|
|
|
|
|
|
|
|
|
|
<para>You can use the following values for
|
|
|
|
|
<replaceable>name</replaceable>: <option>iptable_filter</option>,
|
|
|
|
|
<option>iptable_mangle</option>, <option>ipt_limit</option>,
|
|
|
|
|
<option>ipt_multiport</option>, <option>ipt_tos</option>,
|
|
|
|
|
<option>ipt_TOS</option>, <option>ipt_REJECT</option>,
|
|
|
|
|
<option>ipt_TCPMSS</option>, <option>ipt_tcpmss</option>,
|
|
|
|
|
<option>ipt_ttl</option>, <option>ipt_LOG</option>,
|
|
|
|
|
<option>ipt_length</option>, <option>ip_conntrack</option>,
|
|
|
|
|
<option>ip_conntrack_ftp</option>,
|
|
|
|
|
<option>ip_conntrack_irc</option>, <option>ipt_conntrack</option>,
|
|
|
|
|
<option>ipt_state</option>, <option>ipt_helper</option>,
|
|
|
|
|
<option>iptable_nat</option>, <option>ip_nat_ftp</option>,
|
|
|
|
|
<option>ip_nat_irc</option>, <option>ipt_REDIRECT</option>,
|
|
|
|
|
<option>xt_mac</option>, <option>ipt_owner</option>.</para>
|
2009-06-30 17:55:19 +02:00
|
|
|
|
|
|
|
|
<para>If your provider is using this option, you may be in deep
|
2009-07-05 18:09:58 +02:00
|
|
|
trouble trying to use Shorewall in your container. Look at the
|
|
|
|
|
output of <command>shorewall show capabilities</command> and weep.
|
|
|
|
|
Then try to get your provider to remove this restriction on your
|
|
|
|
|
container.</para>
|
2009-06-30 17:55:19 +02:00
|
|
|
</listitem>
|
|
|
|
|
</varlistentry>
|
|
|
|
|
|
|
|
|
|
<varlistentry>
|
|
|
|
|
<term>--numiptent <replaceable>num</replaceable></term>
|
|
|
|
|
|
|
|
|
|
<listitem>
|
|
|
|
|
<para>This parameter limits the number of iptables rules that are
|
|
|
|
|
allowed within the container. The default is 100 which is too small
|
|
|
|
|
for a Shorewall configuration. We recommend setting this to at least
|
|
|
|
|
200.</para>
|
|
|
|
|
</listitem>
|
|
|
|
|
</varlistentry>
|
|
|
|
|
</variablelist>
|
|
|
|
|
|
2009-07-06 19:03:27 +02:00
|
|
|
<para>if you see annoying error messages as shown below during
|
|
|
|
|
start/restart, remove the module-init-tools package.</para>
|
2009-06-30 17:55:19 +02:00
|
|
|
|
|
|
|
|
<programlisting>server:/etc/shorewall # shorewall restart
|
|
|
|
|
Compiling...
|
|
|
|
|
Compiling /etc/shorewall/zones...
|
|
|
|
|
Compiling /etc/shorewall/interfaces...
|
|
|
|
|
Determining Hosts in Zones...
|
|
|
|
|
Preprocessing Action Files...
|
|
|
|
|
Pre-processing /usr/share/shorewall/action.Drop...
|
|
|
|
|
Pre-processing /usr/share/shorewall/action.Reject...
|
|
|
|
|
Compiling /etc/shorewall/policy...
|
|
|
|
|
Adding Anti-smurf Rules
|
|
|
|
|
Adding rules for DHCP
|
|
|
|
|
Compiling TCP Flags filtering...
|
|
|
|
|
Compiling Kernel Route Filtering...
|
|
|
|
|
Compiling Martian Logging...
|
|
|
|
|
Compiling MAC Filtration -- Phase 1...
|
|
|
|
|
Compiling /etc/shorewall/rules...
|
|
|
|
|
Generating Transitive Closure of Used-action List...
|
|
|
|
|
Processing /usr/share/shorewall/action.Reject for chain Reject...
|
|
|
|
|
Processing /usr/share/shorewall/action.Drop for chain Drop...
|
|
|
|
|
Compiling MAC Filtration -- Phase 2...
|
|
|
|
|
Applying Policies...
|
|
|
|
|
Generating Rule Matrix...
|
|
|
|
|
Creating iptables-restore input...
|
|
|
|
|
Compiling iptables-restore input for chain mangle:...
|
|
|
|
|
Compiling /etc/shorewall/routestopped...
|
|
|
|
|
Shorewall configuration compiled to /var/lib/shorewall/.restart
|
|
|
|
|
Restarting Shorewall....
|
|
|
|
|
Initializing...
|
|
|
|
|
Processing /etc/shorewall/init ...
|
|
|
|
|
Processing /etc/shorewall/tcclear ...
|
|
|
|
|
Setting up Route Filtering...
|
|
|
|
|
Setting up Martian Logging...
|
|
|
|
|
Setting up Proxy ARP...
|
|
|
|
|
Setting up Traffic Control...
|
|
|
|
|
Preparing iptables-restore input...
|
|
|
|
|
Running /usr/sbin/iptables-restore...
|
|
|
|
|
<emphasis role="bold">FATAL: Could not load /lib/modules/2.6.26-2-openvz-amd64/modules.dep: No such file or directory
|
|
|
|
|
FATAL: Could not load /lib/modules/2.6.26-2-openvz-amd64/modules.dep: No such file or directory
|
|
|
|
|
FATAL: Could not load /lib/modules/2.6.26-2-openvz-amd64/modules.dep: No such file or directory
|
|
|
|
|
FATAL: Could not load /lib/modules/2.6.26-2-openvz-amd64/modules.dep: No such file or directory</emphasis>
|
|
|
|
|
IPv4 Forwarding Enabled
|
|
|
|
|
Processing /etc/shorewall/start ...
|
|
|
|
|
Processing /etc/shorewall/started ...
|
|
|
|
|
done.
|
|
|
|
|
</programlisting>
|
|
|
|
|
</section>
|
|
|
|
|
</article>
|
