forked from extern/shorewall_code
Documentation updates
git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@1762 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
This commit is contained in:
parent
9a309a7115
commit
bacb79fe52
@ -1224,6 +1224,29 @@ loc loc REJECT info</programlisting>
|
||||
traffic within the zone is handled just like traffic between zones
|
||||
is.</para>
|
||||
|
||||
<para>The idea is this:</para>
|
||||
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>A zone should be homogenous with respect to security
|
||||
requirements.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Traffic within a zone should not require rules or
|
||||
policies.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Shorewall will not restrict traffic within a zone.</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
|
||||
<para>UNLESS the user defines the zone badly so that intra-zone rules
|
||||
are required. In that case, Shorewall will not try to guess what the
|
||||
user's intentions are and will treat traffic within the affected zone(s)
|
||||
just like any other traffic. </para>
|
||||
|
||||
<para>Any time that you have multiple interfaces associated with a
|
||||
single zone, you should ask yourself if you really want traffic routed
|
||||
between those interfaces. Cases where you might not want that behavior
|
||||
@ -3969,4 +3992,4 @@ eth1 -</programlisting>
|
||||
</revision>
|
||||
</revhistory></para>
|
||||
</appendix>
|
||||
</article>
|
||||
</article>
|
||||
|
@ -15,7 +15,7 @@
|
||||
</author>
|
||||
</authorgroup>
|
||||
|
||||
<pubdate>2004-10-20</pubdate>
|
||||
<pubdate>2004-11-22</pubdate>
|
||||
|
||||
<copyright>
|
||||
<year>2001-2004</year>
|
||||
@ -53,13 +53,14 @@
|
||||
</caution>
|
||||
|
||||
<para>I have DSL service and have 5 static IP addresses
|
||||
(206.124.146.176-180). My DSL <quote>modem</quote> (Westell 2200) is
|
||||
connected to eth1 and has IP address 192.168.1.1 (factory default). The
|
||||
modem is configured in <quote>bridge</quote> mode so PPPoE is not
|
||||
involved. I have a local network connected to eth0 (subnet 192.168.1.0/24)
|
||||
and a DMZ connected to eth2 (206.124.146.176/32). Note that I configure
|
||||
the same IP address on both <filename class="devicefile">eth1</filename>
|
||||
and <filename class="devicefile">eth2</filename>.</para>
|
||||
(206.124.146.176-180). My DSL <quote>modem</quote> (Westell 2200 running
|
||||
in Bridge mode) is connected to eth1 and has IP address 192.168.1.1
|
||||
(factory default). The modem is configured in <quote>bridge</quote> mode
|
||||
so PPPoE is not involved. I have a local network connected to eth0 (subnet
|
||||
192.168.1.0/24) and a DMZ connected to eth2 (206.124.146.176/32). Note
|
||||
that I configure the same IP address on both <filename
|
||||
class="devicefile">eth1</filename> and <filename
|
||||
class="devicefile">eth2</filename>.</para>
|
||||
|
||||
<para>In this configuration:</para>
|
||||
|
||||
@ -119,7 +120,7 @@
|
||||
|
||||
<para>The single system in the DMZ (address 206.124.146.177) runs postfix,
|
||||
Courier IMAP (imaps and pop3), DNS, a Web server (Apache) and an FTP
|
||||
server (Pure-ftpd) under Fedora Core 2. The system also runs fetchmail to
|
||||
server (Pure-ftpd) under Fedora Core 3. The system also runs fetchmail to
|
||||
fetch our email from our old and current ISPs. That server is managed
|
||||
through Proxy ARP.</para>
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user