mirror of
https://gitlab.com/libvirt/libvirt.git
synced 2025-02-22 17:57:43 +03:00
formatnwfilter.html.in: Kill useless spaces in <pre/>
The <pre/> section is rendered as-is on the page. That is, if all the lines are prefixed with 4 spaces the rendered page will also have them. Problem is if we put a box around such <pre/> because the content might not fix into it. Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
This commit is contained in:
Michal Privoznik
parent
f31be1499b
commit
2780c1a866
@ -61,14 +61,14 @@
|
||||
the filter <code>clean-traffic</code>.
|
||||
</p>
|
||||
<pre>
|
||||
...
|
||||
<devices>
|
||||
<interface type='bridge'>
|
||||
<mac address='00:16:3e:5d:c7:9e'/>
|
||||
<filterref filter='clean-traffic'/>
|
||||
</interface>
|
||||
</devices>
|
||||
...</pre>
|
||||
...
|
||||
<devices>
|
||||
<interface type='bridge'>
|
||||
<mac address='00:16:3e:5d:c7:9e'/>
|
||||
<filterref filter='clean-traffic'/>
|
||||
</interface>
|
||||
</devices>
|
||||
...</pre>
|
||||
|
||||
<p>
|
||||
Network filters are written in XML and may either contain references
|
||||
@ -91,16 +91,16 @@
|
||||
the parameter <code>IP</code> and a dotted IP address as value.
|
||||
</p>
|
||||
<pre>
|
||||
...
|
||||
<devices>
|
||||
<interface type='bridge'>
|
||||
<mac address='00:16:3e:5d:c7:9e'/>
|
||||
<filterref filter='clean-traffic'>
|
||||
<parameter name='IP' value='10.0.0.1'/>
|
||||
</filterref>
|
||||
</interface>
|
||||
</devices>
|
||||
...</pre>
|
||||
...
|
||||
<devices>
|
||||
<interface type='bridge'>
|
||||
<mac address='00:16:3e:5d:c7:9e'/>
|
||||
<filterref filter='clean-traffic'>
|
||||
<parameter name='IP' value='10.0.0.1'/>
|
||||
</filterref>
|
||||
</interface>
|
||||
</devices>
|
||||
...</pre>
|
||||
|
||||
<p>
|
||||
In this particular example, the <code>clean-traffic</code> network
|
||||
@ -285,18 +285,18 @@
|
||||
providing multiple elements for the IP variable is:
|
||||
</p>
|
||||
<pre>
|
||||
...
|
||||
<devices>
|
||||
<interface type='bridge'>
|
||||
<mac address='00:16:3e:5d:c7:9e'/>
|
||||
<filterref filter='clean-traffic'>
|
||||
<parameter name='IP' value='10.0.0.1'/>
|
||||
<parameter name='IP' value='10.0.0.2'/>
|
||||
<parameter name='IP' value='10.0.0.3'/>
|
||||
</filterref>
|
||||
</interface>
|
||||
</devices>
|
||||
...</pre>
|
||||
...
|
||||
<devices>
|
||||
<interface type='bridge'>
|
||||
<mac address='00:16:3e:5d:c7:9e'/>
|
||||
<filterref filter='clean-traffic'>
|
||||
<parameter name='IP' value='10.0.0.1'/>
|
||||
<parameter name='IP' value='10.0.0.2'/>
|
||||
<parameter name='IP' value='10.0.0.3'/>
|
||||
</filterref>
|
||||
</interface>
|
||||
</devices>
|
||||
...</pre>
|
||||
<p>
|
||||
This then allows filters to enable multiple IP addresses
|
||||
per interface. Therefore, with the list
|
||||
@ -304,11 +304,11 @@
|
||||
individual filtering rules, one for each IP address.
|
||||
</p>
|
||||
<pre>
|
||||
...
|
||||
<rule action='accept' direction='in' priority='500'>
|
||||
<tcp srpipaddr='$IP'/>
|
||||
</rule>
|
||||
...
|
||||
...
|
||||
<rule action='accept' direction='in' priority='500'>
|
||||
<tcp srpipaddr='$IP'/>
|
||||
</rule>
|
||||
...
|
||||
</pre>
|
||||
<p>
|
||||
<span class="since">Since 0.9.10</span> it is possible to access
|
||||
@ -317,11 +317,11 @@
|
||||
of the variable DSTPORTS.
|
||||
</p>
|
||||
<pre>
|
||||
...
|
||||
<rule action='accept' direction='in' priority='500'>
|
||||
<udp dstportstart='$DSTPORTS[1]'/>
|
||||
</rule>
|
||||
...
|
||||
...
|
||||
<rule action='accept' direction='in' priority='500'>
|
||||
<udp dstportstart='$DSTPORTS[1]'/>
|
||||
</rule>
|
||||
...
|
||||
</pre>
|
||||
<p>
|
||||
<span class="since">Since 0.9.10</span> it is possible to create
|
||||
@ -336,29 +336,29 @@
|
||||
iterators to access their elements.
|
||||
</p>
|
||||
<pre>
|
||||
...
|
||||
<rule action='accept' direction='in' priority='500'>
|
||||
<ip srcipaddr='$SRCIPADDRESSES[@1]' dstportstart='$DSTPORTS[@2]'/>
|
||||
</rule>
|
||||
...
|
||||
...
|
||||
<rule action='accept' direction='in' priority='500'>
|
||||
<ip srcipaddr='$SRCIPADDRESSES[@1]' dstportstart='$DSTPORTS[@2]'/>
|
||||
</rule>
|
||||
...
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
In an example we assign concrete values to SRCIPADDRESSES and DSTPORTS
|
||||
</p>
|
||||
<pre>
|
||||
SRCIPADDRESSES = [ 10.0.0.1, 11.1.2.3 ]
|
||||
DSTPORTS = [ 80, 8080 ]
|
||||
SRCIPADDRESSES = [ 10.0.0.1, 11.1.2.3 ]
|
||||
DSTPORTS = [ 80, 8080 ]
|
||||
</pre>
|
||||
<p>
|
||||
Accessing the variables using $SRCIPADDRESSES[@1] and $DSTPORTS[@2] would
|
||||
then result in all combinations of addresses and ports being created:
|
||||
</p>
|
||||
<pre>
|
||||
10.0.0.1, 80
|
||||
10.0.0.1, 8080
|
||||
11.1.2.3, 80
|
||||
11.1.2.3, 8080
|
||||
10.0.0.1, 80
|
||||
10.0.0.1, 8080
|
||||
11.1.2.3, 80
|
||||
11.1.2.3, 8080
|
||||
</pre>
|
||||
<p>
|
||||
Accessing the same variables using a single iterator, for example by using
|
||||
@ -366,8 +366,8 @@
|
||||
parallel access to both lists and result in the following combinations:
|
||||
</p>
|
||||
<pre>
|
||||
10.0.0.1, 80
|
||||
11.1.2.3, 8080
|
||||
10.0.0.1, 80
|
||||
11.1.2.3, 8080
|
||||
</pre>
|
||||
<p>
|
||||
Further, the notation of $VARIABLE is short-hand for $VARIABLE[@0]. The
|
||||
@ -440,12 +440,12 @@
|
||||
using the DHCP snooping method:
|
||||
</p>
|
||||
<pre>
|
||||
<interface type='bridge'>
|
||||
<source bridge='virbr0'/>
|
||||
<filterref filter='clean-traffic'>
|
||||
<parameter name='CTRL_IP_LEARNING' value='dhcp'/>
|
||||
</filterref>
|
||||
</interface>
|
||||
<interface type='bridge'>
|
||||
<source bridge='virbr0'/>
|
||||
<filterref filter='clean-traffic'>
|
||||
<parameter name='CTRL_IP_LEARNING' value='dhcp'/>
|
||||
</filterref>
|
||||
</interface>
|
||||
</pre>
|
||||
|
||||
<h3><a name="nwfelemsReservedVars">Reserved Variables</a></h3>
|
||||
@ -658,10 +658,10 @@
|
||||
</p>
|
||||
<pre>
|
||||
[...]
|
||||
<rule action='drop' direction='in'>
|
||||
<protocol match='no' attribute1='value1' attribute2='value2'/>
|
||||
<protocol attribute3='value3'/>
|
||||
</rule>
|
||||
<rule action='drop' direction='in'>
|
||||
<protocol match='no' attribute1='value1' attribute2='value2'/>
|
||||
<protocol attribute3='value3'/>
|
||||
</rule>
|
||||
[...]
|
||||
</pre>
|
||||
<p>
|
||||
@ -1896,11 +1896,11 @@
|
||||
turned off for incoming connections to TCP port 12345.
|
||||
</p>
|
||||
<pre>
|
||||
[...]
|
||||
<rule direction='in' action='accept' statematch='false'>
|
||||
<tcp dstportstart='12345'/>
|
||||
</rule>
|
||||
[...]
|
||||
[...]
|
||||
<rule direction='in' action='accept' statematch='false'>
|
||||
<tcp dstportstart='12345'/>
|
||||
</rule>
|
||||
[...]
|
||||
</pre>
|
||||
<p>
|
||||
This now allows incoming traffic to TCP port 12345, but would also
|
||||
@ -1918,26 +1918,26 @@
|
||||
time, the following XML fragment can be used to achieve this.
|
||||
</p>
|
||||
<pre>
|
||||
[...]
|
||||
<rule action='drop' direction='in' priority='400'>
|
||||
<tcp connlimit-above='1'/>
|
||||
</rule>
|
||||
<rule action='accept' direction='in' priority='500'>
|
||||
<tcp dstportstart='22'/>
|
||||
</rule>
|
||||
<rule action='drop' direction='out' priority='400'>
|
||||
<icmp connlimit-above='1'/>
|
||||
</rule>
|
||||
<rule action='accept' direction='out' priority='500'>
|
||||
<icmp/>
|
||||
</rule>
|
||||
<rule action='accept' direction='out' priority='500'>
|
||||
<udp dstportstart='53'/>
|
||||
</rule>
|
||||
<rule action='drop' direction='inout' priority='1000'>
|
||||
<all/>
|
||||
</rule>
|
||||
[...]
|
||||
[...]
|
||||
<rule action='drop' direction='in' priority='400'>
|
||||
<tcp connlimit-above='1'/>
|
||||
</rule>
|
||||
<rule action='accept' direction='in' priority='500'>
|
||||
<tcp dstportstart='22'/>
|
||||
</rule>
|
||||
<rule action='drop' direction='out' priority='400'>
|
||||
<icmp connlimit-above='1'/>
|
||||
</rule>
|
||||
<rule action='accept' direction='out' priority='500'>
|
||||
<icmp/>
|
||||
</rule>
|
||||
<rule action='accept' direction='out' priority='500'>
|
||||
<udp dstportstart='53'/>
|
||||
</rule>
|
||||
<rule action='drop' direction='inout' priority='1000'>
|
||||
<all/>
|
||||
</rule>
|
||||
[...]
|
||||
</pre>
|
||||
<p>
|
||||
Note that the rule for the limit has to logically appear
|
||||
@ -1958,7 +1958,7 @@
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
echo 3 > /proc/sys/net/netfilter/nf_conntrack_icmp_timeout
|
||||
echo 3 > /proc/sys/net/netfilter/nf_conntrack_icmp_timeout
|
||||
</pre>
|
||||
<p>
|
||||
sets the ICMP connection tracking timeout to 3 seconds. The
|
||||
@ -2201,12 +2201,12 @@
|
||||
the domain XML of the <code>test</code> VM could then look like this:
|
||||
</p>
|
||||
<pre>
|
||||
[...]
|
||||
<interface type='bridge'>
|
||||
<source bridge='mybridge'/>
|
||||
<filterref filter='test-eth0'/>
|
||||
</interface>
|
||||
[...]
|
||||
[...]
|
||||
<interface type='bridge'>
|
||||
<source bridge='mybridge'/>
|
||||
<filterref filter='test-eth0'/>
|
||||
</interface>
|
||||
[...]
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
@ -2216,15 +2216,15 @@
|
||||
<code>ICMP</code> rule can be replaced with the following two rules:
|
||||
</p>
|
||||
<pre>
|
||||
<!-- enable outgoing ICMP echo requests-->
|
||||
<rule action='accept' direction='out'>
|
||||
<icmp type='8'/>
|
||||
</rule>
|
||||
<!-- enable outgoing ICMP echo requests-->
|
||||
<rule action='accept' direction='out'>
|
||||
<icmp type='8'/>
|
||||
</rule>
|
||||
|
||||
<!-- enable incoming ICMP echo replies-->
|
||||
<rule action='accept' direction='in'>
|
||||
<icmp type='0'/>
|
||||
</rule>
|
||||
<!-- enable incoming ICMP echo replies-->
|
||||
<rule action='accept' direction='in'>
|
||||
<icmp type='0'/>
|
||||
</rule>
|
||||
</pre>
|
||||
|
||||
<h3><a name="nwfwriteexample2nd">Second example custom filter</a></h3>
|
||||
@ -2326,9 +2326,9 @@
|
||||
the ftp connection with the VM is established.
|
||||
</p>
|
||||
<pre>
|
||||
modprobe nf_conntrack_ftp # where available or
|
||||
modprobe nf_conntrack_ftp # where available or
|
||||
|
||||
modprobe ip_conntrack_ftp # if above is not available
|
||||
modprobe ip_conntrack_ftp # if above is not available
|
||||
</pre>
|
||||
<p>
|
||||
If other protocols than ftp are to be used in conjunction with the
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user