mirror of
https://gitlab.com/shorewall/code.git
synced 2024-11-08 00:34:04 +01:00
Minor document updates
git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@3780 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
This commit is contained in:
teastep
parent
559898a8c9
commit
8aad8dbfee
@ -15,7 +15,7 @@
|
||||
</author>
|
||||
</authorgroup>
|
||||
|
||||
<pubdate>2006-03-27</pubdate>
|
||||
<pubdate>2006-04-02</pubdate>
|
||||
|
||||
<copyright>
|
||||
<year>2005</year>
|
||||
@ -392,18 +392,71 @@
|
||||
permanently alter your firewall/gateway's routing; that is, the effect
|
||||
of these changes is not reversed by <command>shorewall stop</command>
|
||||
or <command>shorewall clear</command>. To restore routing to its
|
||||
original state, you will have to restart your network. This can
|
||||
usually be done by <command>/etc/init.d/network restart</command> or
|
||||
original state, you may have to restart your network. This can usually
|
||||
be done by <command>/etc/init.d/network restart</command> or
|
||||
<command>/etc/init.d/networking restart</command>. Check your
|
||||
distribution's networking documentation.</para>
|
||||
|
||||
<para>You can mitigate the effect of the Shorewall-generated changes
|
||||
to your routing table by specifying a <emphasis>metric</emphasis> for
|
||||
each default route that you configure. Shorewall will generate a
|
||||
load-balancing default route (assuming that <emphasis
|
||||
role="bold">balance</emphasis> has been specified for some of the
|
||||
providers) that does not include a metric and that will therefore not
|
||||
replace any existing route that has a non-zero metric.</para>
|
||||
<para>Here are some additional things to consider:</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>You can mitigate the effect of the Shorewall-generated
|
||||
changes to your routing table by specifying a
|
||||
<emphasis>metric</emphasis> for each default route that you
|
||||
configure. Shorewall will generate a load-balancing default route
|
||||
(assuming that <emphasis role="bold">balance</emphasis> has been
|
||||
specified for some of the providers) that does not include a
|
||||
metric and that will therefore not replace any existing route that
|
||||
has a non-zero metric.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>The <command>-n</command> option to <command>shorewall
|
||||
restart</command> and <command>shorewall restore</command> can be
|
||||
used to prevent the command from changing your routing.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>The <filename>/etc/shorewall/stopped</filename> file can
|
||||
also be used to restore routing when you stop Shorewall. With your
|
||||
firewall in it's normal (single-table) routing configuration, you
|
||||
can capture the contents as follows:</para>
|
||||
|
||||
<programlisting>ip route ls > routes</programlisting>
|
||||
|
||||
<para>Here's what the <filename>routes</filename> file looked like
|
||||
after I did that on my firewall:</para>
|
||||
|
||||
<programlisting>192.168.1.1 dev eth3 scope link
|
||||
206.124.146.177 dev eth1 scope link
|
||||
192.168.2.2 dev tun0 proto kernel scope link src 192.168.2.1
|
||||
192.168.2.0/24 via 192.168.2.2 dev tun0
|
||||
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.254
|
||||
206.124.146.0/24 dev eth3 proto kernel scope link src 206.124.146.176
|
||||
169.254.0.0/16 dev eth0 scope link
|
||||
127.0.0.0/8 dev lo scope link
|
||||
default via 206.124.146.254 dev eth3</programlisting>
|
||||
|
||||
<para>Now edit the file as shown below:</para>
|
||||
|
||||
<programlisting><command>ip route flush table main
|
||||
ip route add</command> 192.168.1.1 dev eth3 scope link
|
||||
<command>ip route add </command>206.124.146.177 dev eth1 scope link
|
||||
<command>ip route add </command>192.168.2.2 dev tun0 proto kernel scope link src 192.168.2.1
|
||||
<command>ip route add </command>192.168.2.0/24 via 192.168.2.2 dev tun0
|
||||
<command>ip route add </command>192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.254
|
||||
<command>ip route add </command>206.124.146.0/24 dev eth3 proto kernel scope link src 206.124.146.176
|
||||
<command>ip route add </command>169.254.0.0/16 dev eth0 scope link
|
||||
<command>ip route add </command>127.0.0.0/8 dev lo scope link
|
||||
<command>ip route add </command>default via 206.124.146.254 dev eth3
|
||||
<command>ip route flush cache</command>
|
||||
</programlisting>
|
||||
|
||||
<para>Now paste the contents of that file into
|
||||
<filename>/etc/shorewall/stopped</filename>.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</warning>
|
||||
</section>
|
||||
|
||||
|
||||
@ -15,7 +15,7 @@
|
||||
</author>
|
||||
</authorgroup>
|
||||
|
||||
<pubdate>2006-03-26</pubdate>
|
||||
<pubdate>2006-04-10</pubdate>
|
||||
|
||||
<copyright>
|
||||
<year>2006</year>
|
||||
@ -78,8 +78,9 @@
|
||||
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>Combination Firewall/Public Server/Private Server using Xen
|
||||
(created by building out my Linux desktop system).</para>
|
||||
<para>Combination Firewall/Public Server/Private Server/Wireless
|
||||
Gateway using Xen (created by building out my Linux desktop
|
||||
system).</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
@ -126,17 +127,37 @@
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<para>There are four Xen domains. Dom0 (ursa.shorewall.net) is used as a
|
||||
file server (NFS and Samba). The first DomU (Dom name <emphasis
|
||||
role="bold">firewall</emphasis>, gateway.shorewall.net) is used as our
|
||||
main firewall; the second DomU (Dom name <emphasis
|
||||
role="bold">lists</emphasis>, lists.shorewall.net) is used as a public
|
||||
Web/FTP/Mail/DNS server while the third DomU (Dom name <emphasis
|
||||
role="bold">wireless</emphasis>, wireless.shorewall.net) 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>
|
||||
<para>There are four Xen domains.</para>
|
||||
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>Dom0 (ursa.shorewall.net) is used as a local file server (NFS
|
||||
and Samba).</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>The first DomU (Dom name <emphasis
|
||||
role="bold">firewall</emphasis>, gateway.shorewall.net) is used as our
|
||||
main firewall.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>The second DomU (Dom name <emphasis
|
||||
role="bold">lists</emphasis>, lists.shorewall.net) is used as a public
|
||||
Web/FTP/Mail/DNS server.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>The third DomU (Dom name <emphasis
|
||||
role="bold">wireless</emphasis>, wireless.shorewall.net) is used as a
|
||||
gateway to our wireless network.</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
|
||||
<para>A seperate wireless gateway is necessary because Xen 3.0 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>
|
||||
|
||||
<section id="Domains">
|
||||
<title>Domain Configuration</title>
|
||||
@ -250,10 +271,13 @@ disk = [ 'phy:hdb4,hdb4,w' ]</programlisting>
|
||||
<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 bootup of Dom0, it
|
||||
creates the four bridges using this
|
||||
<para>SuSE 10.0 includes Xen 3.0 which does not support PCI
|
||||
delegation<footnote>
|
||||
<para>PCI delegation was a feature of Xen 2.0 but that capability
|
||||
was dropped in 3.0. It has been restore in Xen 3.0.2.</para>
|
||||
</footnote>; I therefore use a bridged configuration with four bridges
|
||||
(one for each network interface). When Shorewall starts during bootup of
|
||||
Dom0, it creates the four bridges using this
|
||||
<filename>/etc/shorewall/init</filename> extension script:</para>
|
||||
|
||||
<blockquote>
|
||||
@ -367,7 +391,9 @@ SECTION NEW
|
||||
<para>The two laptops can be directly attached to the LAN as shown above
|
||||
or they can be attached wirelessly through the <link
|
||||
linkend="Wireless">wireless gateway</link> -- their IP addresses are the
|
||||
same in either case.</para>
|
||||
same in either case; when they are directly attached, the IP address is
|
||||
assigned by the DHCP server running on the firewall and when they are
|
||||
attached wirelessly, the IP address is assigned by OpenVPN.</para>
|
||||
|
||||
<para>The Shorewall configuration files are shown below. All routing and
|
||||
secondary IP addresses are handled in the SuSE network
|
||||
|
||||
Binary file not shown.
Binary file not shown.
|
Before Width: | Height: | Size: 36 KiB After Width: | Height: | Size: 37 KiB |
Loading…
Reference in New Issue
Block a user