mirror of
https://github.com/vyos/vyos-documentation.git
synced 2025-12-15 18:12:02 +01:00
Merge pull request #1416 from Embezzle/spelling
Fix spelling mistakes across multiple files
This commit is contained in:
Daniil Baturin
GitHub
commit
ccc07b4601
@ -13,7 +13,7 @@ configuration is done only on one router.
|
||||
Network Topology and requirements
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
This configuration example and the requirments consists of:
|
||||
This configuration example and the requirements consists of:
|
||||
|
||||
- Two VyOS routers with public IP address.
|
||||
|
||||
@ -37,7 +37,7 @@ This configuration example and the requirments consists of:
|
||||
|
||||
- Allow all new connections from local subnets.
|
||||
|
||||
- Allow connections from LANs to LANs throught the tunnel.
|
||||
- Allow connections from LANs to LANs through the tunnel.
|
||||
|
||||
|
||||
.. image:: /_static/images/policy-based-ipsec-and-firewall.png
|
||||
|
||||
@ -69,7 +69,7 @@ Example 2: Failover based on interface weights
|
||||
|
||||
This example uses the failover mode.
|
||||
|
||||
.. _wan:example2_overwiew:
|
||||
.. _wan:example2_overview:
|
||||
|
||||
Overview
|
||||
^^^^^^^^
|
||||
@ -98,7 +98,7 @@ The previous example used the failover command to send traffic through
|
||||
eth1 if eth0 fails. In this example, failover functionality is provided
|
||||
by rule order.
|
||||
|
||||
.. _wan:example3_overwiew:
|
||||
.. _wan:example3_overview:
|
||||
|
||||
Overview
|
||||
^^^^^^^^
|
||||
@ -129,7 +129,7 @@ traffic. It is assumed for this example that eth1 is connected to a
|
||||
slower connection than eth0 and should prioritize VoIP traffic.
|
||||
|
||||
|
||||
.. _wan:example4_overwiew:
|
||||
.. _wan:example4_overview:
|
||||
|
||||
Overview
|
||||
^^^^^^^^
|
||||
|
||||
@ -6,7 +6,7 @@ Zone-Policy example
|
||||
-------------------
|
||||
|
||||
.. note:: Starting from VyOS 1.4-rolling-202308040557, a new firewall
|
||||
structure can be found on all vyos instalations, and zone based firewall is
|
||||
structure can be found on all vyos installations, and zone based firewall is
|
||||
no longer supported. Documentation for most of the new firewall CLI can be
|
||||
found in the `firewall
|
||||
<https://docs.vyos.io/en/latest/configuration/firewall/general.html>`_
|
||||
|
||||
@ -125,7 +125,7 @@ Configuration
|
||||
- **net-bind-service**: Bind a socket to privileged ports (port numbers less than 1024)
|
||||
- **net-raw**: Permission to create raw network sockets
|
||||
- **setpcap**: Capability sets (from bounded or inherited set)
|
||||
- **sys-admin**: Administation operations (quotactl, mount, sethostname, setdomainame)
|
||||
- **sys-admin**: Administration operations (quotactl, mount, sethostname, setdomainame)
|
||||
- **sys-time**: Permission to set system clock
|
||||
|
||||
.. cfgcmd:: set container name <name> disable
|
||||
|
||||
@ -13,7 +13,7 @@ Overview
|
||||
********
|
||||
|
||||
In this section there's useful information of all firewall configuration that
|
||||
can be done regarding bridge, and appropiate op-mode commands.
|
||||
can be done regarding bridge, and appropriate op-mode commands.
|
||||
Configuration commands covered in this section:
|
||||
|
||||
.. cfgcmd:: set firewall bridge ...
|
||||
@ -37,13 +37,13 @@ for this layer is shown next:
|
||||
|
||||
.. figure:: /_static/images/firewall-bridge-packet-flow.png
|
||||
|
||||
For traffic that needs to be forwared internally by the bridge, base chain is
|
||||
For traffic that needs to be forwarded internally by the bridge, base chain is
|
||||
is **forward**, and it's base command for filtering is ``set firewall bridge
|
||||
forward filter ...``, which happens in stage 4, highlightened with red color.
|
||||
forward filter ...``, which happens in stage 4, highlighted with red color.
|
||||
|
||||
Custom bridge firewall chains can be create with command ``set firewall bridge
|
||||
name <name> ...``. In order to use such custom chain, a rule with action jump,
|
||||
and the appropiate target should be defined in a base chain.
|
||||
and the appropriate target should be defined in a base chain.
|
||||
|
||||
.. note:: **Layer 3 bridge**:
|
||||
When an IP address is assigned to the bridge interface, and if traffic
|
||||
@ -137,7 +137,7 @@ not match any rule in it's chain. For base chains, possible options for
|
||||
|
||||
.. cfgcmd:: set firewall bridge name <name> default-jump-target <text>
|
||||
|
||||
To be used only when ``defult-action`` is set to ``jump``. Use this
|
||||
To be used only when ``default-action`` is set to ``jump``. Use this
|
||||
command to specify jump target for default rule.
|
||||
|
||||
.. note:: **Important note about default-actions:**
|
||||
@ -236,9 +236,9 @@ There are a lot of matching criteria against which the packet can be tested.
|
||||
.. cfgcmd:: set firewall bridge name <name> rule <1-999999>
|
||||
inbound-interface name <iface>
|
||||
|
||||
Match based on inbound interface. Wilcard ``*`` can be used.
|
||||
Match based on inbound interface. Wildcard ``*`` can be used.
|
||||
For example: ``eth2*``. Prepending character ``!`` for inverted matching
|
||||
criteria is also supportd. For example ``!eth2``
|
||||
criteria is also supported. For example ``!eth2``
|
||||
|
||||
.. cfgcmd:: set firewall bridge forward filter rule <1-999999>
|
||||
inbound-interface group <iface_group>
|
||||
@ -246,16 +246,16 @@ There are a lot of matching criteria against which the packet can be tested.
|
||||
inbound-interface group <iface_group>
|
||||
|
||||
Match based on inbound interface group. Prepending character ``!`` for
|
||||
inverted matching criteria is also supportd. For example ``!IFACE_GROUP``
|
||||
inverted matching criteria is also supported. For example ``!IFACE_GROUP``
|
||||
|
||||
.. cfgcmd:: set firewall bridge forward filter rule <1-999999>
|
||||
outbound-interface name <iface>
|
||||
.. cfgcmd:: set firewall bridge name <name> rule <1-999999>
|
||||
outbound-interface name <iface>
|
||||
|
||||
Match based on outbound interface. Wilcard ``*`` can be used.
|
||||
Match based on outbound interface. Wildcard ``*`` can be used.
|
||||
For example: ``eth2*``. Prepending character ``!`` for inverted matching
|
||||
criteria is also supportd. For example ``!eth2``
|
||||
criteria is also supported. For example ``!eth2``
|
||||
|
||||
.. cfgcmd:: set firewall bridge forward filter rule <1-999999>
|
||||
outbound-interface group <iface_group>
|
||||
@ -263,7 +263,7 @@ There are a lot of matching criteria against which the packet can be tested.
|
||||
outbound-interface group <iface_group>
|
||||
|
||||
Match based on outbound interface group. Prepending character ``!`` for
|
||||
inverted matching criteria is also supportd. For example ``!IFACE_GROUP``
|
||||
inverted matching criteria is also supported. For example ``!IFACE_GROUP``
|
||||
|
||||
.. cfgcmd:: set firewall bridge forward filter rule <1-999999>
|
||||
vlan id <0-4096>
|
||||
@ -288,7 +288,7 @@ Rule-set overview
|
||||
|
||||
In this section you can find all useful firewall op-mode commands.
|
||||
|
||||
General commands for firewall configuration, counter and statiscits:
|
||||
General commands for firewall configuration, counter and statistics:
|
||||
|
||||
.. opcmd:: show firewall
|
||||
.. opcmd:: show firewall summary
|
||||
|
||||
@ -99,20 +99,20 @@ Creating rules for using flow tables:
|
||||
Configuration Example
|
||||
*********************
|
||||
|
||||
Things to be considred in this setup:
|
||||
Things to be considered in this setup:
|
||||
|
||||
* Two interfaces are going to be used in the flowtables: eth0 and eth1
|
||||
|
||||
* Minumum firewall ruleset is provided, which includes some filtering rules,
|
||||
and appropiate rules for using flowtable offload capabilities.
|
||||
* Minimum firewall ruleset is provided, which includes some filtering rules,
|
||||
and appropriate rules for using flowtable offload capabilities.
|
||||
|
||||
As described, first packet will be evaluated by all the firewall path, so
|
||||
desired connection should be explicitely accepted. Same thing should be taken
|
||||
desired connection should be explicitly accepted. Same thing should be taken
|
||||
into account for traffic in reverse order. In most cases state policies are
|
||||
used in order to accept connection in reverse patch.
|
||||
|
||||
We will only accept traffic comming from interface eth0, protocol tcp and
|
||||
destination port 1122. All other traffic traspassing the router should be
|
||||
We will only accept traffic coming from interface eth0, protocol tcp and
|
||||
destination port 1122. All other traffic trespassing the router should be
|
||||
blocked.
|
||||
|
||||
Commands
|
||||
|
||||
@ -24,7 +24,7 @@ firewall are covered below:
|
||||
where the packet was received is part of a bridge, or not.
|
||||
|
||||
If the interface where the packet was received isn't part of a bridge, then
|
||||
packetis processed at the **IP Layer**:
|
||||
packet is processed at the **IP Layer**:
|
||||
|
||||
* **Prerouting**: several actions can be done in this stage, and currently
|
||||
these actions are defined in different parts in VyOS configuration. Order
|
||||
@ -65,7 +65,7 @@ packetis processed at the **IP Layer**:
|
||||
* **Output**: stage where traffic that originates from the router itself
|
||||
can be filtered and controlled. Bear in mind that this traffic can be a
|
||||
new connection originated by a internal process running on VyOS router,
|
||||
such as NTP, or a response to traffic received externaly through
|
||||
such as NTP, or a response to traffic received externally through
|
||||
**input** (for example response to an ssh login attempt to the router).
|
||||
This includes ipv4 and ipv6 filtering rules, defined in:
|
||||
|
||||
@ -84,7 +84,7 @@ If the interface where the packet was received is part of a bridge, then
|
||||
the packet is processed at the **Bridge Layer**, which contains a basic setup for
|
||||
bridge filtering:
|
||||
|
||||
* **Forward (Bridge)**: stage where traffic that is trespasing through the
|
||||
* **Forward (Bridge)**: stage where traffic that is trespassing through the
|
||||
bridge is filtered and controlled:
|
||||
|
||||
* ``set firewall bridge forward filter ...``.
|
||||
|
||||
@ -11,7 +11,7 @@ Overview
|
||||
********
|
||||
|
||||
In this section there's useful information of all firewall configuration that
|
||||
can be done regarding IPv4, and appropiate op-mode commands.
|
||||
can be done regarding IPv4, and appropriate op-mode commands.
|
||||
Configuration commands covered in this section:
|
||||
|
||||
.. cfgcmd:: set firewall ipv4 ...
|
||||
@ -41,12 +41,12 @@ next:
|
||||
|
||||
Where firewall base chain to configure firewall filtering rules for transit
|
||||
traffic is ``set firewall ipv4 forward filter ...``, which happens in stage 5,
|
||||
highlightened with red color.
|
||||
highlighted with red color.
|
||||
|
||||
For traffic towards the router itself, base chain is **input**, while traffic
|
||||
originated by the router, base chain is **output**.
|
||||
A new simplified packet flow diagram is shown next, which shows the path
|
||||
for traffic destinated to the router itself, and traffic generated by the
|
||||
for traffic destined to the router itself, and traffic generated by the
|
||||
router (starting from circle number 6):
|
||||
|
||||
.. figure:: /_static/images/firewall-input-packet-flow.png
|
||||
@ -64,7 +64,7 @@ output filter ...``
|
||||
|
||||
Custom firewall chains can be created, with commands
|
||||
``set firewall ipv4 name <name> ...``. In order to use
|
||||
such custom chain, a rule with **action jump**, and the appropiate **target**
|
||||
such custom chain, a rule with **action jump**, and the appropriate **target**
|
||||
should be defined in a base chain.
|
||||
|
||||
*********************
|
||||
@ -184,7 +184,7 @@ not match any rule in it's chain. For base chains, possible options for
|
||||
|
||||
.. cfgcmd:: set firewall ipv4 name <name> default-jump-target <text>
|
||||
|
||||
To be used only when ``defult-action`` is set to ``jump``. Use this
|
||||
To be used only when ``default-action`` is set to ``jump``. Use this
|
||||
command to specify jump target for default rule.
|
||||
|
||||
.. note:: **Important note about default-actions:**
|
||||
@ -683,9 +683,9 @@ geoip) to keep database and rules updated.
|
||||
.. cfgcmd:: set firewall ipv4 name <name> rule <1-999999>
|
||||
inbound-interface name <iface>
|
||||
|
||||
Match based on inbound interface. Wilcard ``*`` can be used.
|
||||
Match based on inbound interface. Wildcard ``*`` can be used.
|
||||
For example: ``eth2*``. Prepending character ``!`` for inverted matching
|
||||
criteria is also supportd. For example ``!eth2``
|
||||
criteria is also supported. For example ``!eth2``
|
||||
|
||||
.. cfgcmd:: set firewall ipv4 forward filter rule <1-999999>
|
||||
inbound-interface group <iface_group>
|
||||
@ -695,7 +695,7 @@ geoip) to keep database and rules updated.
|
||||
inbound-interface group <iface_group>
|
||||
|
||||
Match based on inbound interface group. Prepending character ``!`` for
|
||||
inverted matching criteria is also supportd. For example ``!IFACE_GROUP``
|
||||
inverted matching criteria is also supported. For example ``!IFACE_GROUP``
|
||||
|
||||
.. cfgcmd:: set firewall ipv4 forward filter rule <1-999999>
|
||||
outbound-interface name <iface>
|
||||
@ -704,9 +704,9 @@ geoip) to keep database and rules updated.
|
||||
.. cfgcmd:: set firewall ipv4 name <name> rule <1-999999>
|
||||
outbound-interface name <iface>
|
||||
|
||||
Match based on outbound interface. Wilcard ``*`` can be used.
|
||||
Match based on outbound interface. Wildcard ``*`` can be used.
|
||||
For example: ``eth2*``. Prepending character ``!`` for inverted matching
|
||||
criteria is also supportd. For example ``!eth2``
|
||||
criteria is also supported. For example ``!eth2``
|
||||
|
||||
.. cfgcmd:: set firewall ipv4 forward filter rule <1-999999>
|
||||
outbound-interface group <iface_group>
|
||||
@ -716,7 +716,7 @@ geoip) to keep database and rules updated.
|
||||
outbound-interface group <iface_group>
|
||||
|
||||
Match based on outbound interface group. Prepending character ``!`` for
|
||||
inverted matching criteria is also supportd. For example ``!IFACE_GROUP``
|
||||
inverted matching criteria is also supported. For example ``!IFACE_GROUP``
|
||||
|
||||
.. cfgcmd:: set firewall ipv4 forward filter rule <1-999999>
|
||||
ipsec [match-ipsec | match-none]
|
||||
|
||||
@ -11,7 +11,7 @@ Overview
|
||||
********
|
||||
|
||||
In this section there's useful information of all firewall configuration that
|
||||
can be done regarding IPv6, and appropiate op-mode commands.
|
||||
can be done regarding IPv6, and appropriate op-mode commands.
|
||||
Configuration commands covered in this section:
|
||||
|
||||
.. cfgcmd:: set firewall ipv6 ...
|
||||
@ -41,12 +41,12 @@ next:
|
||||
|
||||
Where firewall base chain to configure firewall filtering rules for transit
|
||||
traffic is ``set firewall ipv6 forward filter ...``, which happens in stage 5,
|
||||
highlightened with red color.
|
||||
highlighted with red color.
|
||||
|
||||
For traffic towards the router itself, base chain is **input**, while traffic
|
||||
originated by the router, base chain is **output**.
|
||||
A new simplified packet flow diagram is shown next, which shows the path
|
||||
for traffic destinated to the router itself, and traffic generated by the
|
||||
for traffic destined to the router itself, and traffic generated by the
|
||||
router (starting from circle number 6):
|
||||
|
||||
.. figure:: /_static/images/firewall-input-packet-flow.png
|
||||
@ -64,7 +64,7 @@ output filter ...``
|
||||
|
||||
Custom firewall chains can be created, with commands
|
||||
``set firewall ipv6 name <name> ...``. In order to use
|
||||
such custom chain, a rule with **action jump**, and the appropiate **target**
|
||||
such custom chain, a rule with **action jump**, and the appropriate **target**
|
||||
should be defined in a base chain.
|
||||
|
||||
******************************
|
||||
@ -184,7 +184,7 @@ not match any rule in it's chain. For base chains, possible options for
|
||||
|
||||
.. cfgcmd:: set firewall ipv6 name <name> default-jump-target <text>
|
||||
|
||||
To be used only when ``defult-action`` is set to ``jump``. Use this
|
||||
To be used only when ``default-action`` is set to ``jump``. Use this
|
||||
command to specify jump target for default rule.
|
||||
|
||||
.. note:: **Important note about default-actions:**
|
||||
@ -670,9 +670,9 @@ geoip) to keep database and rules updated.
|
||||
.. cfgcmd:: set firewall ipv6 name <name> rule <1-999999>
|
||||
inbound-interface name <iface>
|
||||
|
||||
Match based on inbound interface. Wilcard ``*`` can be used.
|
||||
Match based on inbound interface. Wildcard ``*`` can be used.
|
||||
For example: ``eth2*``. Prepending character ``!`` for inverted matching
|
||||
criteria is also supportd. For example ``!eth2``
|
||||
criteria is also supported. For example ``!eth2``
|
||||
|
||||
.. cfgcmd:: set firewall ipv6 forward filter rule <1-999999>
|
||||
inbound-interface group <iface_group>
|
||||
@ -682,7 +682,7 @@ geoip) to keep database and rules updated.
|
||||
inbound-interface group <iface_group>
|
||||
|
||||
Match based on inbound interface group. Prepending character ``!`` for
|
||||
inverted matching criteria is also supportd. For example ``!IFACE_GROUP``
|
||||
inverted matching criteria is also supported. For example ``!IFACE_GROUP``
|
||||
|
||||
.. cfgcmd:: set firewall ipv6 forward filter rule <1-999999>
|
||||
outbound-interface name <iface>
|
||||
@ -691,9 +691,9 @@ geoip) to keep database and rules updated.
|
||||
.. cfgcmd:: set firewall ipv6 name <name> rule <1-999999>
|
||||
outbound-interface name <iface>
|
||||
|
||||
Match based on outbound interface. Wilcard ``*`` can be used.
|
||||
Match based on outbound interface. Wildcard ``*`` can be used.
|
||||
For example: ``eth2*``. Prepending character ``!`` for inverted matching
|
||||
criteria is also supportd. For example ``!eth2``
|
||||
criteria is also supported. For example ``!eth2``
|
||||
|
||||
.. cfgcmd:: set firewall ipv6 forward filter rule <1-999999>
|
||||
outbound-interface group <iface_group>
|
||||
@ -703,7 +703,7 @@ geoip) to keep database and rules updated.
|
||||
outbound-interface group <iface_group>
|
||||
|
||||
Match based on outbound interface group. Prepending character ``!`` for
|
||||
inverted matching criteria is also supportd. For example ``!IFACE_GROUP``
|
||||
inverted matching criteria is also supported. For example ``!IFACE_GROUP``
|
||||
|
||||
.. cfgcmd:: set firewall ipv6 forward filter rule <1-999999>
|
||||
ipsec [match-ipsec | match-none]
|
||||
|
||||
@ -11,7 +11,7 @@ Overview
|
||||
********
|
||||
|
||||
.. note:: Starting from VyOS 1.4-rolling-202308040557, a new firewall
|
||||
structure can be found on all vyos instalations. Zone based firewall was
|
||||
structure can be found on all VyOS installations. Zone based firewall was
|
||||
removed in that version, but re introduced in VyOS 1.4 and 1.5. All
|
||||
versions built after 2023-10-22 has this feature.
|
||||
Documentation for most of the new firewall CLI can be
|
||||
|
||||
@ -8,7 +8,7 @@
|
||||
PKI
|
||||
###
|
||||
|
||||
VyOS 1.4 changed the way in how encrytion keys or certificates are stored on the
|
||||
VyOS 1.4 changed the way in how encryption keys or certificates are stored on the
|
||||
system. In the pre VyOS 1.4 era, certificates got stored under /config and every
|
||||
service referenced a file. That made copying a running configuration from system
|
||||
A to system B a bit harder, as you had to copy the files and their permissions
|
||||
@ -120,12 +120,12 @@ OpenVPN
|
||||
|
||||
.. opcmd:: generate pki openvpn shared-secret
|
||||
|
||||
Genearate a new OpenVPN shared secret. The generated secret is the output to
|
||||
Generate a new OpenVPN shared secret. The generated secret is the output to
|
||||
the console.
|
||||
|
||||
.. opcmd:: generate pki openvpn shared-secret install <name>
|
||||
|
||||
Genearate a new OpenVPN shared secret. The generated secret is the output to
|
||||
Generate a new OpenVPN shared secret. The generated secret is the output to
|
||||
the console.
|
||||
|
||||
.. include:: pki_cli_import_help.txt
|
||||
@ -163,7 +163,7 @@ WireGuard
|
||||
the output from op-mode into configuration mode.
|
||||
|
||||
``peer`` is used for the VyOS CLI command to identify the WireGuard peer where
|
||||
this secred is to be used.
|
||||
this secret is to be used.
|
||||
|
||||
Key usage (CLI)
|
||||
===============
|
||||
|
||||
@ -12,7 +12,7 @@ interior gateway protocol (IGP) which is described in ISO10589,
|
||||
algorithm to create a database of the network’s topology, and
|
||||
from that database to determine the best (that is, lowest cost) path to a
|
||||
destination. The intermediate systems (the name for routers) exchange topology
|
||||
information with their directly conencted neighbors. IS-IS runs directly on
|
||||
information with their directly connected neighbors. IS-IS runs directly on
|
||||
the data link layer (Layer 2). IS-IS addresses are called
|
||||
:abbr:`NETs (Network Entity Titles)` and can be 8 to 20 bytes long, but are
|
||||
generally 10 bytes long. The tree database that is created with IS-IS is
|
||||
@ -39,7 +39,7 @@ occur within IS-IS when it comes to said duplication.
|
||||
|
||||
.. cfgcmd:: set protocols isis net <network-entity-title>
|
||||
|
||||
This commad sets network entity title (NET) provided in ISO format.
|
||||
This command sets network entity title (NET) provided in ISO format.
|
||||
|
||||
Here is an example :abbr:`NET (Network Entity Title)` value:
|
||||
|
||||
@ -52,9 +52,9 @@ occur within IS-IS when it comes to said duplication.
|
||||
* :abbr:`AFI (Address family authority identifier)` - ``49`` The AFI value
|
||||
49 is what IS-IS uses for private addressing.
|
||||
|
||||
* Area identifier: ``0001`` IS-IS area number (numberical area ``1``)
|
||||
* Area identifier: ``0001`` IS-IS area number (numerical area ``1``)
|
||||
|
||||
* System identifier: ``1921.6800.1002`` - for system idetifiers we recommend
|
||||
* System identifier: ``1921.6800.1002`` - for system identifiers we recommend
|
||||
to use IP address or MAC address of the router itself. The way to construct
|
||||
this is to keep all of the zeroes of the router IP address, and then change
|
||||
the periods from being every three numbers to every four numbers. The
|
||||
|
||||
@ -20,7 +20,7 @@ Configuration
|
||||
.. cfgcmd:: set service broadcast-relay id <n> description <description>
|
||||
|
||||
A description can be added for each and every unique relay ID. This is
|
||||
useful to distinguish between multiple different ports/appliactions.
|
||||
useful to distinguish between multiple different ports/applications.
|
||||
|
||||
.. cfgcmd:: set service broadcast-relay id <n> interface <interface>
|
||||
|
||||
@ -35,7 +35,7 @@ Configuration
|
||||
|
||||
.. cfgcmd:: set service broadcast-relay id <n> port <port>
|
||||
|
||||
The UDP port number used by your apllication. It is mandatory for this kind
|
||||
The UDP port number used by your application. It is mandatory for this kind
|
||||
of operation.
|
||||
|
||||
.. cfgcmd:: set service broadcast-relay id <n> disable
|
||||
|
||||
@ -29,7 +29,7 @@ will be mandatorily defragmented.
|
||||
|
||||
It is possible to use either Multicast or Unicast to sync conntrack traffic.
|
||||
Most examples below show Multicast, but unicast can be specified by using the
|
||||
"peer" keywork after the specificed interface, as in the following example:
|
||||
"peer" keywork after the specified interface, as in the following example:
|
||||
|
||||
:cfgcmd:`set service conntrack-sync interface eth0 peer 192.168.0.250`
|
||||
|
||||
@ -204,7 +204,7 @@ Now configure conntrack-sync service on ``router1`` **and** ``router2``
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
set high-availablilty vrrp group internal virtual-address ... etc ...
|
||||
set high-availability vrrp group internal virtual-address ... etc ...
|
||||
set high-availability vrrp sync-group syncgrp member 'internal'
|
||||
set service conntrack-sync accept-protocol 'tcp'
|
||||
set service conntrack-sync accept-protocol 'udp'
|
||||
|
||||
@ -33,7 +33,7 @@ Configuration
|
||||
Configure direction for processing traffic.
|
||||
|
||||
.. cfgcmd:: set service ids ddos-protection exclude-network <x.x.x.x/x>
|
||||
.. cfgcmd:: set service ids ddos-protection exlude-network <h:h:h:h:h:h:h:h/x>
|
||||
.. cfgcmd:: set service ids ddos-protection exclude-network <h:h:h:h:h:h:h:h/x>
|
||||
|
||||
Specify IPv4 and/or IPv6 networks which are going to be excluded.
|
||||
|
||||
@ -56,7 +56,7 @@ Configuration
|
||||
|
||||
.. cfgcmd:: set service ids ddos-protection sflow port <1-65535>
|
||||
|
||||
Configure port number to be used for sflow conection. Default port is 6343.
|
||||
Configure port number to be used for sflow connection. Default port is 6343.
|
||||
|
||||
.. cfgcmd:: set service ids ddos-protection threshold general
|
||||
[fps | mbps | pps] <0-4294967294>
|
||||
@ -96,7 +96,7 @@ In this simplified scenario, main things to be considered are:
|
||||
* Interface **eth0** used to connect to upstream.
|
||||
|
||||
Since we are analyzing attacks to and from our internal network, two types
|
||||
of attacks can be identified, and differents actions are needed:
|
||||
of attacks can be identified, and different actions are needed:
|
||||
|
||||
* External attack: an attack from the internet towards an internal IP
|
||||
is identify. In this case, all connections towards such IP will be
|
||||
|
||||
@ -38,7 +38,7 @@ Configuration
|
||||
"Cur Hop Limit", "hop-limit", "Hop count field of the outgoing RA packets"
|
||||
"""Managed address configuration"" flag", "managed-flag", "Tell hosts to use the administered stateful protocol (i.e. DHCP) for autoconfiguration"
|
||||
"""Other configuration"" flag", "other-config-flag", "Tell hosts to use the administered (stateful) protocol (i.e. DHCP) for autoconfiguration of other (non-address) information"
|
||||
"MTU","link-mtu","Link MTU value placed in RAs, exluded in RAs if unset"
|
||||
"MTU","link-mtu","Link MTU value placed in RAs, excluded in RAs if unset"
|
||||
"Router Lifetime","default-lifetime","Lifetime associated with the default router in units of seconds"
|
||||
"Reachable Time","reachable-time","Time, in milliseconds, that a node assumes a neighbor is reachable after having received a reachability confirmation"
|
||||
"Retransmit Timer","retrans-timer","Time in milliseconds between retransmitted Neighbor Solicitation messages"
|
||||
|
||||
@ -17,7 +17,7 @@ Requirements
|
||||
************
|
||||
|
||||
To use the Salt-Minion, a running Salt-Master is required. You can find more
|
||||
in the `Salt Poject Documentaion
|
||||
in the `Salt Project Documentation
|
||||
<https://docs.saltproject.io/en/latest/contents.html>`_
|
||||
|
||||
*************
|
||||
|
||||
@ -94,7 +94,7 @@ states.
|
||||
.. cfgcmd:: set system conntrack timeout udp stream <1-21474836>
|
||||
:defaultvalue:
|
||||
|
||||
Set the timeout in secounds for a protocol or state.
|
||||
Set the timeout in seconds for a protocol or state.
|
||||
|
||||
You can also define custom timeout values to apply to a specific subset of
|
||||
connections, based on a packet and flow selector. To do this, you need to
|
||||
@ -172,7 +172,7 @@ create a rule defining the packet and flow selector.
|
||||
.. cfgcmd:: set system conntrack timeout custom [ipv4 | ipv6] rule <1-999999>
|
||||
protocol udp unreplied <1-21474836>
|
||||
|
||||
Set the timeout in secounds for a protocol or state in a custom rule.
|
||||
Set the timeout in seconds for a protocol or state in a custom rule.
|
||||
|
||||
Conntrack ignore rules
|
||||
======================
|
||||
|
||||
@ -50,7 +50,7 @@ interface, the interface must be configured for flow accounting.
|
||||
Configure and enable collection of flow information for the interface
|
||||
identified by `<interface>`.
|
||||
|
||||
You can configure multiple interfaces which whould participate in flow
|
||||
You can configure multiple interfaces which would participate in flow
|
||||
accounting.
|
||||
|
||||
.. note:: Will be recorded only packets/flows on **incoming** direction in
|
||||
|
||||
@ -30,7 +30,7 @@ System configuration commands
|
||||
Zebra/Kernel route filtering
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Zebra supports prefix-lists and Route Mapss to match routes received from
|
||||
Zebra supports prefix-lists and Route Maps to match routes received from
|
||||
other FRR components. The permit/deny facilities provided by these commands
|
||||
can be used to filter which routes zebra will install in the kernel.
|
||||
|
||||
@ -48,7 +48,7 @@ Nexthop Tracking
|
||||
|
||||
Nexthop tracking resolve nexthops via the default route by default. This is enabled
|
||||
by default for a traditional profile of FRR which we use. It and can be disabled if
|
||||
you do not wan't to e.g. allow BGP to peer across the default route.
|
||||
you do not want to e.g. allow BGP to peer across the default route.
|
||||
|
||||
.. cfgcmd:: set system ip nht no-resolve-via-default
|
||||
|
||||
|
||||
@ -26,7 +26,7 @@ System configuration commands
|
||||
Zebra/Kernel route filtering
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Zebra supports prefix-lists and Route Mapss to match routes received from
|
||||
Zebra supports prefix-lists and Route Maps to match routes received from
|
||||
other FRR components. The permit/deny facilities provided by these commands
|
||||
can be used to filter which routes zebra will install in the kernel.
|
||||
|
||||
@ -44,7 +44,7 @@ Nexthop Tracking
|
||||
|
||||
Nexthop tracking resolve nexthops via the default route by default. This is enabled
|
||||
by default for a traditional profile of FRR which we use. It and can be disabled if
|
||||
you do not wan't to e.g. allow BGP to peer across the default route.
|
||||
you do not want to e.g. allow BGP to peer across the default route.
|
||||
|
||||
.. cfgcmd:: set system ipv6 nht no-resolve-via-default
|
||||
|
||||
|
||||
@ -88,7 +88,7 @@ Keyboard Layout
|
||||
***************
|
||||
|
||||
When starting a VyOS live system (the installation CD) the configured keyboard
|
||||
layout defaults to US. As this might not suite everyones use case you can adjust
|
||||
layout defaults to US. As this might not suite everyone's use case you can adjust
|
||||
the used keyboard layout on the system console.
|
||||
|
||||
.. cfgcmd:: set system option keyboard-layout <us | fr | de | fi | no | dk>
|
||||
|
||||
@ -29,7 +29,7 @@ Configuration
|
||||
|
||||
Configure and enable collection of flow information for the interface identified by <interface>.
|
||||
|
||||
You can configure multiple interfaces which whould participate in sflow accounting.
|
||||
You can configure multiple interfaces which would participate in sflow accounting.
|
||||
|
||||
|
||||
.. cfgcmd:: set system sflow polling <sec>
|
||||
|
||||
@ -45,7 +45,7 @@ Custom File
|
||||
|
||||
.. cfgcmd:: set system syslog file <filename> archive file <number>
|
||||
|
||||
Syslog uses logrotate to rotate logiles after a number of gives bytes.
|
||||
Syslog uses logrotate to rotate logfiles after a number of gives bytes.
|
||||
We keep as many as `<number>` rotated file before they are deleted on the
|
||||
system.
|
||||
|
||||
@ -200,7 +200,7 @@ Display Logs
|
||||
.. opcmd:: show log [all | authorization | cluster | conntrack-sync | ...]
|
||||
|
||||
Display log files of given category on the console. Use tab completion to get
|
||||
a list of available categories. Thos categories could be: all, authorization,
|
||||
a list of available categories. Those categories could be: all, authorization,
|
||||
cluster, conntrack-sync, dhcp, directory, dns, file, firewall, https, image
|
||||
lldp, nat, openvpn, snmp, tail, vpn, vrrp
|
||||
|
||||
|
||||
@ -7,7 +7,7 @@ Task Scheduler
|
||||
The task scheduler allows you to execute tasks on a given schedule. It makes
|
||||
use of UNIX cron_.
|
||||
|
||||
.. note:: All scripts excecuted this way are executed as root user - this may
|
||||
.. note:: All scripts executed this way are executed as root user - this may
|
||||
be dangerous. Together with :ref:`command-scripting` this can be used for
|
||||
automating (re-)configuration.
|
||||
|
||||
|
||||
@ -368,7 +368,7 @@ are to be sent, they could get dropped when trying to get enqueued at
|
||||
the tail. This can happen if the queue has still not been able to
|
||||
release enough packets from its head.
|
||||
|
||||
This is the policy that requieres the lowest resources for the same
|
||||
This is the policy that requires the lowest resources for the same
|
||||
amount of traffic. But **very likely you do not need it as you cannot
|
||||
get much from it. Sometimes it is used just to enable logging.**
|
||||
|
||||
@ -504,7 +504,7 @@ and increase `interval` to something around 150 ms.
|
||||
the number of sub-queues (default: 1024) into which packets are
|
||||
classified.
|
||||
|
||||
.. cfgcmd:: set qos policy fq-codel <policy name> interval <miliseconds>
|
||||
.. cfgcmd:: set qos policy fq-codel <policy name> interval <milliseconds>
|
||||
|
||||
Use this command to configure an fq-codel policy, set its name and
|
||||
the time period used by the control loop of CoDel to detect when a
|
||||
@ -518,7 +518,7 @@ and increase `interval` to something around 150 ms.
|
||||
define a hard limit on the real queue size. When this limit is
|
||||
reached, new packets are dropped (default: 10240 packets).
|
||||
|
||||
.. cfgcmd:: set qos policy fq-codel <policy-name> target <miliseconds>
|
||||
.. cfgcmd:: set qos policy fq-codel <policy-name> target <milliseconds>
|
||||
|
||||
Use this command to configure an fq-codel policy, set its name, and
|
||||
define the acceptable minimum standing/persistent queue delay. This
|
||||
@ -710,7 +710,7 @@ continuously, packets from lower priority classes will only be
|
||||
transmitted after traffic volume from higher priority classes decreases.
|
||||
|
||||
|
||||
.. note:: In Priority Queue we do not define clases with a meaningless
|
||||
.. note:: In Priority Queue we do not define classes with a meaningless
|
||||
class ID number but with a class priority number (1-7). The lower the
|
||||
number, the higher the priority.
|
||||
|
||||
@ -912,7 +912,7 @@ In principle, values must be
|
||||
Rate Control
|
||||
------------
|
||||
|
||||
| **Queueing discipline:** Tocken Bucket Filter.
|
||||
| **Queueing discipline:** Token Bucket Filter.
|
||||
| **Applies to:** Outbound traffic.
|
||||
|
||||
Rate-Control is a classless policy that limits the packet flow to a set
|
||||
|
||||
@ -43,7 +43,7 @@ then enslaved to a VRF device.
|
||||
Zebra/Kernel route filtering
|
||||
----------------------------
|
||||
|
||||
Zebra supports prefix-lists and Route Mapss to match routes received from
|
||||
Zebra supports prefix-lists and Route Maps to match routes received from
|
||||
other FRR components. The permit/deny facilities provided by these commands
|
||||
can be used to filter which routes zebra will install in the kernel.
|
||||
|
||||
@ -72,7 +72,7 @@ Nexthop Tracking
|
||||
|
||||
Nexthop tracking resolve nexthops via the default route by default. This is enabled
|
||||
by default for a traditional profile of FRR which we use. It and can be disabled if
|
||||
you do not wan't to e.g. allow BGP to peer across the default route.
|
||||
you do not want to e.g. allow BGP to peer across the default route.
|
||||
|
||||
.. cfgcmd:: set vrf name <name> ip nht no-resolve-via-default
|
||||
|
||||
|
||||
@ -24,7 +24,7 @@ The VyOS implementation of RAID 1 allows the following:
|
||||
* The ability to replace a failed disk and initiate re-mirroring
|
||||
* The ability to monitor the status of remirroring
|
||||
|
||||
.. _raid_instalation:
|
||||
.. _raid_installation:
|
||||
|
||||
Installation Implications
|
||||
=========================
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user