mirror of
https://gitlab.com/shorewall/code.git
synced 2025-01-09 15:18:12 +01:00
Break XenMyWay doc into sections and expand
git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@3706 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
This commit is contained in:
parent
8608cf9aa9
commit
55df9ff829
@ -15,7 +15,7 @@
|
||||
</author>
|
||||
</authorgroup>
|
||||
|
||||
<pubdate>2006-03-19</pubdate>
|
||||
<pubdate>2006-03-20</pubdate>
|
||||
|
||||
<copyright>
|
||||
<year>2006</year>
|
||||
@ -92,7 +92,7 @@
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
|
||||
<para>All of the Linux systems run SuSE 10.0.</para>
|
||||
<para>All of the Linux systems run SuSE 10.0 or SuSE 10.1 Beta.</para>
|
||||
|
||||
<para>If you are unfamiliar with Xen networking, I recommend that you read
|
||||
the first section of the companion <ulink url="Xen.html">Xen and
|
||||
@ -132,16 +132,19 @@
|
||||
is used as a gateway to our wireless network. A seperate wireless gateway
|
||||
is necessary because Xen 3 only supports three virtual interfaces per DomU
|
||||
and the firewall DomU already has three interfaces. Shorewall runs in
|
||||
Dom0, in the firewall domain and in the wireless gateway..</para>
|
||||
Dom0, in the firewall domain and in the wireless gateway.</para>
|
||||
|
||||
<para>Below are the relevant configuration files for the four domains. The
|
||||
"loopback.nloopbacks=..." entries are used to restrict the number of
|
||||
<section id="Domains">
|
||||
<title>Domain Configuration</title>
|
||||
|
||||
<para>Below are the relevant configuration files for the four domains.
|
||||
The "loopback.nloopbacks=..." entries are used to restrict the number of
|
||||
"veth<emphasis>n</emphasis>" devices that the Xen kernel creates. I use
|
||||
partitions on my hard drives for DomU storage devices.</para>
|
||||
|
||||
<blockquote>
|
||||
<para><filename>/boot/grub/menu.lst</filename> — here is the entry that
|
||||
boots Xen in Dom0.</para>
|
||||
<para><filename>/boot/grub/menu.lst</filename> — here is the entry
|
||||
that boots Xen in Dom0.</para>
|
||||
|
||||
<programlisting>title XEN
|
||||
root (hd0,1)
|
||||
@ -149,8 +152,8 @@
|
||||
module /boot/vmlinuz-xen root=/dev/hda2 vga=0x31a selinux=0 resume=/dev/hda1 splash=silent showopts loopback.nloopbacks=1
|
||||
module /boot/initrd-xen</programlisting>
|
||||
|
||||
<para><filename>/etc/xen/auto/01-gateway</filename> — configuration file
|
||||
for the firewall domain</para>
|
||||
<para><filename>/etc/xen/auto/01-gateway</filename> — configuration
|
||||
file for the firewall domain</para>
|
||||
|
||||
<programlisting># -*- mode: python; -*-
|
||||
|
||||
@ -177,8 +180,8 @@ hostname = name
|
||||
# storage devices:
|
||||
disk = [ 'phy:hdb2,hdb2,w' ]</programlisting>
|
||||
|
||||
<para><filename>/etc/xen/auto/02-server</filename> — configuration file
|
||||
for the lists domain</para>
|
||||
<para><filename>/etc/xen/auto/02-server</filename> — configuration
|
||||
file for the lists domain</para>
|
||||
|
||||
<programlisting># -*- mode: python; -*-
|
||||
|
||||
@ -205,7 +208,7 @@ hostname = name
|
||||
# storage devices:
|
||||
disk = [ 'phy:hda3,hda3,w' ]</programlisting>
|
||||
|
||||
<para>/etc/xen/auto/03-gateway — configuration file for the wireless
|
||||
<para>/etc/xen/auto/03-wireless — configuration file for the wireless
|
||||
domain.</para>
|
||||
|
||||
<programlisting># -*- mode: python; -*-
|
||||
@ -235,20 +238,19 @@ hostname = name
|
||||
disk = [ 'phy:hdb4,hdb4,w' ]</programlisting>
|
||||
</blockquote>
|
||||
|
||||
<para>With all four Xen domains up and running, the system looks as shown
|
||||
in the following diagram.</para>
|
||||
<para>With all four Xen domains up and running, the system looks as
|
||||
shown in the following diagram.</para>
|
||||
|
||||
<graphic align="center" fileref="images/Xen4.png" />
|
||||
|
||||
<para>The zones correspond to the Shorewall zones in the Dom0
|
||||
configuration.</para>
|
||||
|
||||
<para>SuSE 10.0 includes Xen 3.0 which does not support PCI delegation; I
|
||||
therefore use a bridged configuration with four bridges (one for each
|
||||
network interface). When Shorewall starts during boot, it creates the four
|
||||
bridges.</para>
|
||||
|
||||
<para>Here is <filename>/etc/shorewall/init in Dom0</filename>:</para>
|
||||
<para>SuSE 10.0 includes Xen 3.0 which does not support PCI delegation;
|
||||
I therefore use a bridged configuration with four bridges (one for each
|
||||
network interface). When Shorewall starts during boot of Dom0, it
|
||||
creates the four bridges using this
|
||||
<filename>/etc/shorewall/init</filename> extension script:</para>
|
||||
|
||||
<blockquote>
|
||||
<programlisting>for bridge in xenbr0 xenbr1 xenbr2 xenbr3; do
|
||||
@ -274,6 +276,10 @@ disk = [ 'phy:hdb4,hdb4,w' ]</programlisting>
|
||||
fi
|
||||
done</programlisting>
|
||||
</blockquote>
|
||||
</section>
|
||||
|
||||
<section id="Dom0">
|
||||
<title>Dom0 Configuration</title>
|
||||
|
||||
<para>The goals for the Shorewall configuration in Dom0 are as
|
||||
follows:</para>
|
||||
@ -282,14 +288,14 @@ done</programlisting>
|
||||
<listitem>
|
||||
<para>Allow traffic to flow unrestricted through the four bridges.
|
||||
This is done by configuring the hosts connected to each bridge as a
|
||||
separate zone and relying on the implicit intra-zone ACCEPT policy to
|
||||
permit traffic through the bridge.</para>
|
||||
separate zone and relying on Shorewall's implicit intra-zone ACCEPT
|
||||
policy to permit traffic through the bridge.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Ensure that there is no stray traffic between the zones. This is
|
||||
a "belt+suspenders" measure since there should be no routing between
|
||||
the bridges (because they don't have IP addresses).</para>
|
||||
<para>Ensure that there is no stray traffic between the zones. This
|
||||
is a "belt+suspenders" measure since there should be no routing
|
||||
between the bridges (because they don't have IP addresses).</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
@ -308,7 +314,8 @@ net ipv4
|
||||
#LAST LINE - ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE
|
||||
</programlisting>
|
||||
|
||||
<para><filename>/etc/shorewall/policy</filename>:</para>
|
||||
<para><filename>/etc/shorewall/policy</filename> (Note the unusual use
|
||||
of an ACCEPT all->all policy):</para>
|
||||
|
||||
<programlisting>#SOURCE DEST POLICY LOG LIMIT:BURST
|
||||
# LEVEL
|
||||
@ -339,13 +346,17 @@ net xenbr2 - routeback
|
||||
SECTION NEW
|
||||
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE</programlisting>
|
||||
</blockquote>
|
||||
</section>
|
||||
|
||||
<para>In the firewall DomU, I run a conventional three-interface firewall
|
||||
with Proxy ARP DMZ -- it is very similar to the firewall described in the
|
||||
<ulink url="shorewall_setup_guide.htm">Shorewall Setup Guide</ulink>. The
|
||||
firewall runs a routed <ulink url="OPENVPN.html">OpenVPN server</ulink> to
|
||||
provide roadwarrior access for our two laptops. Here is the firewall's
|
||||
view of the network:</para>
|
||||
<section id="Firewall">
|
||||
<title>Firewall DomU Configuration</title>
|
||||
|
||||
<para>In the firewall DomU, I run a conventional three-interface
|
||||
firewall with Proxy ARP DMZ -- it is very similar to the firewall
|
||||
described in the <ulink url="shorewall_setup_guide.htm">Shorewall Setup
|
||||
Guide</ulink>. The firewall runs a routed <ulink
|
||||
url="OPENVPN.html">OpenVPN server</ulink> to provide roadwarrior access
|
||||
for our two laptops. Here is the firewall's view of the network:</para>
|
||||
|
||||
<graphic align="center" fileref="images/network4.png" />
|
||||
|
||||
@ -452,14 +463,11 @@ EXT_IF=eth3
|
||||
|
||||
OMAK=<IP address at our second home>
|
||||
|
||||
#LAST LINE - ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE
|
||||
</programlisting>
|
||||
#LAST LINE - ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE</programlisting>
|
||||
|
||||
<para><filename>/etc/shorewall/init</filename>:</para>
|
||||
|
||||
<programlisting>echo 1 > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_be_liberal
|
||||
|
||||
</programlisting>
|
||||
<programlisting>echo 1 > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_be_liberal</programlisting>
|
||||
|
||||
<para><filename>/</filename></para>
|
||||
|
||||
@ -679,17 +687,26 @@ Ping/ACCEPT fw dmz
|
||||
DROP net:82.96.96.3 all
|
||||
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE</programlisting>
|
||||
</blockquote>
|
||||
</section>
|
||||
|
||||
<para>The Shorewall configuration in the 'wireless' DomU is similarly
|
||||
simple-minded. It's sole purpose is to protect the local network from the
|
||||
Wireless net.</para>
|
||||
<section id="Wireless">
|
||||
<title>Wireless Gateway DomU Configuration</title>
|
||||
|
||||
<para>The Shorewall configuration in the 'wireless' DomU is very
|
||||
simple-minded. It's sole purpose is to protect the local network from
|
||||
the Wireless net by restricting wireless access to clients that have
|
||||
established an <ulink url="OPENVPN.html">OpenVPN</ulink> Bridged
|
||||
connection. This configuration illustrates that you can use any Linux
|
||||
system on your internal LAN as a wireless gateway -- it doesn't have to
|
||||
be your main firewall (and it doesn't have to run in a Xen domain
|
||||
either).</para>
|
||||
|
||||
<graphic align="center" fileref="images/Xen6.png" />
|
||||
|
||||
<para>We restrict wireless access to clients that have established an
|
||||
<ulink url="OPENVPN.html">OpenVPN</ulink> Bridged connection. The 'tap0'
|
||||
device used by OpenVPN is bridged to eth2 using this startup
|
||||
script:</para>
|
||||
<para>The 'tap0' device used by OpenVPN is bridged to eth2 using this
|
||||
SuSE-specific startup script (see the <ulink url="bridge.html">Shorewall
|
||||
Bridge Documentation</ulink> for scripts that work on other
|
||||
distributions):</para>
|
||||
|
||||
<blockquote>
|
||||
<para><filename>/etc/init.d/bridge</filename>:</para>
|
||||
@ -744,7 +761,7 @@ DROP net:82.96.96.3 all
|
||||
### END INIT INFO
|
||||
|
||||
################################################################################
|
||||
# Interfaces to be bridged -- may be listed by device name or by MAC
|
||||
# Interfaces to be bridged -- may be listed by device name or by MAC address
|
||||
#
|
||||
INTERFACES="eth2"
|
||||
|
||||
@ -798,7 +815,7 @@ get_interfaces() {
|
||||
INTERFACES="$interfaces"
|
||||
}
|
||||
################################################################################
|
||||
# Start the Bridge
|
||||
# Configure the Bridge -- IP configuration is left to the SuSE network scripts
|
||||
################################################################################
|
||||
do_start()
|
||||
{
|
||||
@ -863,7 +880,24 @@ case "$command" in
|
||||
;;
|
||||
esac</programlisting>
|
||||
|
||||
<para>BRIDGING=No in
|
||||
<para>As mentioned in the comments in the above script, IP
|
||||
configuration of the bridge is done through the normal SuSE network
|
||||
scripts. Here's the config file:</para>
|
||||
|
||||
<programlisting>BOOTPROTO='static'
|
||||
BROADCAST=''
|
||||
IPADDR='192.168.1.7'
|
||||
MTU=''
|
||||
NAME='Ethernet Network Card'
|
||||
NETMASK='255.255.255.0'
|
||||
NETWORK=''
|
||||
REMOTE_IPADDR=''
|
||||
STARTMODE='auto'
|
||||
USERCONTROL='no'
|
||||
_nm_name='br0'</programlisting>
|
||||
|
||||
<para>Since there is no requirement to restrict connections through
|
||||
the bridge, I set BRIDGING=No in
|
||||
<filename>/etc/shorewall/shorewall.conf</filename>.</para>
|
||||
|
||||
<para><filename>/etc/shorewall/zones</filename>:</para>
|
||||
@ -911,6 +945,69 @@ ACCEPT eth4 00:12:79:3d:fe:2e 192.168.3.6
|
||||
ACCEPT eth4 - 192.168.3.254 #Broadcast/Multicast from us
|
||||
DROP:info eth4 - 192.168.3.0/24
|
||||
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE</programlisting>
|
||||
|
||||
<para><filename>/etc/shorewall/rules</filename>:</para>
|
||||
|
||||
<programlisting>#ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL RATE USER/
|
||||
# PORT PORT(S) DEST LIMIT GROUP
|
||||
#SECTION ESTABLISHED
|
||||
#SECTION RELATED
|
||||
SECTION NEW
|
||||
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE</programlisting>
|
||||
</blockquote>
|
||||
|
||||
<para>Here is the configuration of OpenVPN on this system:</para>
|
||||
|
||||
<blockquote>
|
||||
<para><filename>/etc/openvpn/server-bridge</filename> (Note that I
|
||||
prefer to push two /1 routes rather than to use the <emphasis
|
||||
role="bold">redirect-gateway</emphasis> directive; I find that the
|
||||
latter occasionally leaves the remote system with <emphasis
|
||||
role="bold">no</emphasis> default gateway):</para>
|
||||
|
||||
<programlisting>dev tap0
|
||||
|
||||
local 192.168.3.254
|
||||
|
||||
server-bridge 192.168.1.5 255.255.255.0 192.168.1.64 192.168.1.71
|
||||
|
||||
client-to-client
|
||||
|
||||
dh dh1024.pem
|
||||
|
||||
ca /etc/certs/cacert.pem
|
||||
|
||||
crl-verify /etc/certs/crl.pem
|
||||
|
||||
cert /etc/certs/wireless.pem
|
||||
key /etc/certs/wireless_key.pem
|
||||
|
||||
port 1194
|
||||
|
||||
comp-lzo
|
||||
|
||||
user nobody
|
||||
group nogroup
|
||||
|
||||
keepalive 15 45
|
||||
ping-timer-rem
|
||||
persist-tun
|
||||
persist-key
|
||||
|
||||
client-config-dir /etc/openvpn/bridge-clients
|
||||
ccd-exclusive
|
||||
|
||||
verb 3
|
||||
|
||||
push "route 0.0.0.0 128.0.0.0 192.168.1.254"
|
||||
push "route 128.0.0.0 128.0.0.0 192.168.1.254"</programlisting>
|
||||
|
||||
<para><filename>/etc/bridge-clients/tipper.shorewall.net</filename>
|
||||
(used to assign a fixed IP address to clients -- there are other
|
||||
similar files in this directory):</para>
|
||||
|
||||
<programlisting>ifconfig-push 192.168.1.8 255.255.255.0</programlisting>
|
||||
</blockquote>
|
||||
</section>
|
||||
</section>
|
||||
</article>
|
Loading…
Reference in New Issue
Block a user