diff --git a/docs/OpenVZ.xml b/docs/OpenVZ.xml new file mode 100644 index 000000000..8dfdc3c4e --- /dev/null +++ b/docs/OpenVZ.xml @@ -0,0 +1,272 @@ + + +
+ + + + Shorewall and OpenVZ + + + + Tom + + Eastep + + + + + + + 2008 + + Thomas M. Eastep + + + + 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 + GNU Free Documentation + License. + + + +
+ Introduction + + Open Virtuoso (OpenVZ) + is an open source kernel-based virtualization solution from + SWSoft. Virtual servers take the form of + containers which are created via + templates. Templates are available for a wide + variety of distributions and architectures. + + OpenVZ requires a patched kernel. Beginning with Lenny, + Debian supplies OpenVZ kernels through the standard + stable repository. +
+ +
+ Shorewall on an OpenVZ Host + + 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 shorewall + clear while installing and + configuring OpenVZ. + +
+ Networking + + 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 + (/proc/sys/net/ipv4/conf/interface/proxy_arp). + + OpenVZ creates virtual interfaces in the host with very odd + configurations. + + Example: + + gateway:~# ip addr ls dev venet0 +10: venet0: <BROADCAST,POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN + link/void +gateway:~# ip route ls dev venet0 +206.124.146.178 scope link +gateway:~# + + The interface has no IP configuration yet it has a route to + 206.124.146.178! + + From within the container with IP address 206.124.146.178, we have + the following: + + server:~ # ip addr ls +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:~ # ip route ls +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:~ # + + There are a couple of unique features of this + configuration: + + + + 127.0.0.1/32 is configured on venet0 although the main routing + table routes loopback traffic through the lo interface as normal. + + + + 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. + + + + The default route is via 192.0.2.1 yet there is no interface + on the host with that IP address. + + + + All of this doesn't really affect the Shorewall configuration but + it is interesting none the less. +
+ +
+ Shorewall Configuration + + We recommend handlintg the strange OpenVZ configuration in + Shorewall as follows: + + /etc/shorewall/zones: + + ############################################################################### +#ZONE TYPE OPTIONS IN OUT +# OPTIONS OPTIONS +vz ipv4 + + /etc/shorewall/interfaces: + + ############################################################################### +#ZONE INTERFACE BROADCAST OPTIONS +vz venet0 - + + /etc/shorewall/proxyarp (assumes that + external interface is eth0): + + ############################################################################### +#ADDRESS INTERFACE EXTERNAL HAVEROUTE PERSISTENT +206.124.146.178 venet0 eth0 Yes +
+ +
+ Multi-ISP + + 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: + + #SOURCE DEST PROVIDER PRIORITY +- 206.124.146.178 main 1000 +
+
+ +
+ Shorewall in an OpenVZ Container + + If you have optained an OpenVZ container from a service provider, + you may find it difficult to configure any type of firewall within the + container. There are two container parameters that control iptables + behavior within the container: + + + + --iptables name + + + Restrict access to iptables modules inside a container (by + default all iptables modules that are loaded in the host system are + accessible inside a container). + + You can use the following values for name: iptable_filter, + iptable_mangle, ipt_limit, ipt_multiport, ipt_tos, ipt_TOS, + ipt_REJECT, ipt_TCPMSS, ipt_tcpmss, ipt_ttl, ipt_LOG, ipt_length, + ip_conntrack, ip_conntrack_ftp, ip_conntrack_irc, ipt_conntrack, + ipt_state, ipt_helper, iptable_nat, ip_nat_ftp, ip_nat_irc, + ipt_REDIRECT, xt_mac, ipt_owner. + + If your provider is using this option, you may be in deep + trouble using Shorewall. Look at the output of shorewall + show capabilities and weep. Then try to get your provider + to remove this restriction on your container. + + + + + --numiptent num + + + 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. + + + + + To cut down on the amount of useless error messages during shorewall + start/restart, we suggest that you create a capabilities file as + follows: + + shorewall show -f capabilities > /etc/shorewall/capabilities + + You may still see annoying error messages during + start/restart: + + 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... +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 +IPv4 Forwarding Enabled +Processing /etc/shorewall/start ... +Processing /etc/shorewall/started ... +done. + + + Those may be safely ignored. +
+