Merge branch 'equuleus' of github.com:vyos/vyos-documentation into equuleus

This commit is contained in:
rebortg 2022-03-24 20:32:07 +01:00
commit db42af861e
14 changed files with 2023 additions and 1940 deletions

@ -1 +1 @@
Subproject commit 7c23d8a1de26b13e948c83a30771da259e9a59e8
Subproject commit b1449aa2bd2008f51b75a9976108f416209a5567

View File

@ -61,15 +61,16 @@ a remote VyOS system.
Will return:
```
Welcome to VyOS
Codes: S - State, L - Link, u - Up, D - Down, A - Admin Down
Interface IP Address S/L Description
--------- ---------- --- -----------
eth0 192.0.2.1/24 u/u
lo 127.0.0.1/8 u/u
::1/128
```
.. code-block:: none
Welcome to VyOS
Codes: S - State, L - Link, u - Up, D - Down, A - Admin Down
Interface IP Address S/L Description
--------- ---------- --- -----------
eth0 192.0.2.1/24 u/u
lo 127.0.0.1/8 u/u
::1/128
Other script languages
----------------------

View File

@ -8,6 +8,19 @@
_ext/releasenotes.py
2022-03-12
==========
* :vytask:`T4296` (bug): Interface config injected by Cloud-Init may interfere with VyOS native
* :vytask:`T4002` (default): firewall group network-group long names restriction incorrect behavior
2022-03-11
==========
* :vytask:`T4297` (bug): Interface configuration saving fails for ice/iavf based interfaces because they can't change speed/duplex settings
2022-03-05
==========
@ -1567,7 +1580,7 @@
2021-02-16
==========
* :vytask:`T3318` (feature): Update Linux Kernel to v5.4.182 / 5.10.103
* :vytask:`T3318` (feature): Update Linux Kernel to v5.4.185 / 5.10.106
2021-02-14

View File

@ -3,9 +3,9 @@ DHCP Relay trough GRE-Bridge
############################
| Testdate: 2021-12-22
| Version: 1.3.0
| Upgrade Version: 1.4-rolling-202112211328
| Testdate: 2022-03-22
| Version: 1.3.1
| Upgrade Version: 1.4-rolling-202203220701
This simple structure shows how to configure a DHCP Relay over a GRE Bridge
@ -78,14 +78,14 @@ Ping the Client from the DHCP Server.
vyos@dhcp-server:~$ ping 192.168.0.30 count 4
PING 192.168.0.30 (192.168.0.30) 56(84) bytes of data.
64 bytes from 192.168.0.30: icmp_seq=1 ttl=63 time=0.845 ms
64 bytes from 192.168.0.30: icmp_seq=2 ttl=63 time=1.21 ms
64 bytes from 192.168.0.30: icmp_seq=3 ttl=63 time=0.895 ms
64 bytes from 192.168.0.30: icmp_seq=4 ttl=63 time=1.27 ms
64 bytes from 192.168.0.30: icmp_seq=1 ttl=63 time=1.02 ms
64 bytes from 192.168.0.30: icmp_seq=2 ttl=63 time=1.07 ms
64 bytes from 192.168.0.30: icmp_seq=3 ttl=63 time=1.24 ms
64 bytes from 192.168.0.30: icmp_seq=4 ttl=63 time=1.00 ms
--- 192.168.0.30 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 7ms
rtt min/avg/max/mdev = 0.845/1.054/1.271/0.187 ms
rtt min/avg/max/mdev = 1.001/1.081/1.237/0.098 ms
And show all DHCP Leases
@ -96,4 +96,4 @@ And show all DHCP Leases
vyos@dhcp-server:~$ show dhcp server leases
IP address Hardware address State Lease start Lease expiration Remaining Pool Hostname
------------ ------------------ ------- ------------------- ------------------- ----------- ---------- ----------
192.168.0.30 00:50:79:66:68:05 active 2021/12/22 15:27:38 2021/12/23 15:27:38 23:59:17 DHCPTun100 VPCS
192.168.0.30 00:50:79:66:68:05 active 2022/03/22 20:23:12 2022/03/23 20:23:12 23:59:17 DHCPTun100 VPCS

File diff suppressed because it is too large Load Diff

View File

@ -3,9 +3,9 @@ Wireguard
#########
| Testdate: 2021-12-21
| Version: 1.3.0
| Upgrade Version: 1.4-rolling-202112211328
| Testdate: 2022-03-22
| Version: 1.3.1
| Upgrade Version: 1.4-rolling-202203220701
This simple structure show how to connect two offices. One remote branch and the
@ -47,7 +47,7 @@ After this, the public key can be displayed, to save for later.
vyos@central:~$ generate wireguard default-keypair
vyos@central:~$ show wireguard keypairs pubkey default
CfI9uV81w+zYGCR9tuun+yvj4w62/NEYX3XWFyxe1wg=
OagNr7jAXSAvQlieqKAmcEH9+s+JfVOw5EdUroFudxA=
After you have each public key. The wireguard interfaces can be setup.
@ -103,11 +103,11 @@ And ping the Branch PC from your central router to check the response.
vyos@central:~$ ping 10.0.2.100 count 4
PING 10.0.2.100 (10.0.2.100) 56(84) bytes of data.
64 bytes from 10.0.2.100: icmp_seq=1 ttl=63 time=0.590 ms
64 bytes from 10.0.2.100: icmp_seq=2 ttl=63 time=1.10 ms
64 bytes from 10.0.2.100: icmp_seq=3 ttl=63 time=0.716 ms
64 bytes from 10.0.2.100: icmp_seq=4 ttl=63 time=0.625 ms
64 bytes from 10.0.2.100: icmp_seq=1 ttl=63 time=0.593 ms
64 bytes from 10.0.2.100: icmp_seq=2 ttl=63 time=0.672 ms
64 bytes from 10.0.2.100: icmp_seq=3 ttl=63 time=0.828 ms
64 bytes from 10.0.2.100: icmp_seq=4 ttl=63 time=0.667 ms
--- 10.0.2.100 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 18ms
rtt min/avg/max/mdev = 0.590/0.758/1.102/0.204 ms
4 packets transmitted, 4 received, 0% packet loss, time 30ms
rtt min/avg/max/mdev = 0.593/0.690/0.828/0.085 ms

View File

@ -7,7 +7,7 @@ set interfaces wireguard wg01 peer central allowed-ips 10.0.1.0/24
set interfaces wireguard wg01 peer central allowed-ips 192.168.0.0/24
set interfaces wireguard wg01 peer central address 198.51.100.1
set interfaces wireguard wg01 peer central port 51820
set interfaces wireguard wg01 peer central pubkey "CfI9uV81w+zYGCR9tuun+yvj4w62/NEYX3XWFyxe1wg="
set interfaces wireguard wg01 peer central pubkey "OagNr7jAXSAvQlieqKAmcEH9+s+JfVOw5EdUroFudxA="
set interfaces wireguard wg01 port 51820
set protocols static interface-route 10.0.1.0/24 next-hop-interface wg01

View File

@ -7,7 +7,7 @@ set interfaces wireguard wg01 peer branch allowed-ips 10.0.2.0/24
set interfaces wireguard wg01 peer branch allowed-ips 192.168.0.0/24
set interfaces wireguard wg01 peer branch address 198.51.100.2
set interfaces wireguard wg01 peer branch port 51820
set interfaces wireguard wg01 peer branch pubkey "DoaxmsefQJSg2iTpyifU4EPUuyII8TaKUmctDbXO8RA="
set interfaces wireguard wg01 peer branch pubkey "PJls3F1FAHNmZJoGo1kFJIKDyWyT4pD0fneB0NdMTTg="
set interfaces wireguard wg01 port 51820
set protocols static interface-route 10.0.2.0/24 next-hop-interface wg01

File diff suppressed because it is too large Load Diff

View File

@ -4,9 +4,9 @@
Tunnelbroker.net (IPv6)
#######################
| Testdate: 2021-12-30
| Version: 1.3.0
| Upgrade Version: 1.4-rolling-202112300317
| Testdate: 2022-03-24
| Version: 1.3.1
| Upgrade Version: 1.4-rolling-202203220701
This guide walks through the setup of https://www.tunnelbroker.net/ for an
IPv6 Tunnel.
@ -62,14 +62,14 @@ Now you should be able to ping a public IPv6 Address
vyos@vyos-wan:~$ ping 2001:470:20::2 count 4
PING 2001:470:20::2(2001:470:20::2) 56 data bytes
64 bytes from 2001:470:20::2: icmp_seq=1 ttl=64 time=30.8 ms
64 bytes from 2001:470:20::2: icmp_seq=2 ttl=64 time=29.7 ms
64 bytes from 2001:470:20::2: icmp_seq=3 ttl=64 time=31.1 ms
64 bytes from 2001:470:20::2: icmp_seq=4 ttl=64 time=30.8 ms
64 bytes from 2001:470:20::2: icmp_seq=1 ttl=64 time=30.7 ms
64 bytes from 2001:470:20::2: icmp_seq=2 ttl=64 time=29.8 ms
64 bytes from 2001:470:20::2: icmp_seq=3 ttl=64 time=30.1 ms
64 bytes from 2001:470:20::2: icmp_seq=4 ttl=64 time=30.2 ms
--- 2001:470:20::2 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 9ms
rtt min/avg/max/mdev = 29.735/30.620/31.149/0.531 ms
rtt min/avg/max/mdev = 29.765/30.171/30.673/0.389 ms
Assuming the pings are successful, you need to add some DNS servers.
@ -86,14 +86,14 @@ You should now be able to ping something by IPv6 DNS name:
vyos@vyos-wan:~$ ping tunnelbroker.net count 4
PING tunnelbroker.net(tunnelbroker.net (2001:470:0:63::2)) 56 data bytes
64 bytes from tunnelbroker.net (2001:470:0:63::2): icmp_seq=1 ttl=54 time=180 ms
64 bytes from tunnelbroker.net (2001:470:0:63::2): icmp_seq=2 ttl=54 time=180 ms
64 bytes from tunnelbroker.net (2001:470:0:63::2): icmp_seq=3 ttl=54 time=187 ms
64 bytes from tunnelbroker.net (2001:470:0:63::2): icmp_seq=4 ttl=54 time=180 ms
64 bytes from tunnelbroker.net (2001:470:0:63::2): icmp_seq=1 ttl=54 time=179 ms
64 bytes from tunnelbroker.net (2001:470:0:63::2): icmp_seq=2 ttl=54 time=227 ms
64 bytes from tunnelbroker.net (2001:470:0:63::2): icmp_seq=3 ttl=54 time=179 ms
64 bytes from tunnelbroker.net (2001:470:0:63::2): icmp_seq=4 ttl=54 time=179 ms
--- tunnelbroker.net ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 7ms
rtt min/avg/max/mdev = 179.764/181.764/187.436/3.316 ms
4 packets transmitted, 4 received, 0% packet loss, time 8ms
rtt min/avg/max/mdev = 178.994/191.062/226.756/20.612 ms
*****************
@ -149,14 +149,14 @@ Now the Client is able to ping a public IPv6 address
vyos@client:~$ ping 2001:470:20::2 count 4
PING 2001:470:20::2(2001:470:20::2) 56 data bytes
64 bytes from 2001:470:20::2: icmp_seq=1 ttl=63 time=31.9 ms
64 bytes from 2001:470:20::2: icmp_seq=2 ttl=63 time=31.5 ms
64 bytes from 2001:470:20::2: icmp_seq=3 ttl=63 time=31.0 ms
64 bytes from 2001:470:20::2: icmp_seq=1 ttl=63 time=30.6 ms
64 bytes from 2001:470:20::2: icmp_seq=2 ttl=63 time=30.4 ms
64 bytes from 2001:470:20::2: icmp_seq=3 ttl=63 time=30.5 ms
64 bytes from 2001:470:20::2: icmp_seq=4 ttl=63 time=30.6 ms
--- 2001:470:20::2 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 8ms
rtt min/avg/max/mdev = 30.645/31.243/31.886/0.524 ms
4 packets transmitted, 4 received, 0% packet loss, time 9ms
rtt min/avg/max/mdev = 30.387/30.537/30.643/0.238 ms
Multiple LAN/DMZ Setup

View File

@ -127,8 +127,8 @@ Operation
.. opcmd:: generate ssh client-key /path/to/private_key
Re-generated a known pub/private keyfile which can e.g. used to connect to
other services (RPKI cache).
Re-generated a known pub/private keyfile which can be used to connect to
other services (e.g. RPKI cache).
Example:
@ -153,5 +153,36 @@ Operation
| =.. o=.oo|
+----[SHA256]-----+
Two new files ``/config/auth/id_rsa_rpki`` and ``/config/auth/id_rsa_rpki.pub``
Two new files ``/config/auth/id_rsa_rpki`` and
``/config/auth/id_rsa_rpki.pub``
will be created.
.. opcmd:: generate public-key-command name <username> path <location>
Generate the configuration mode commands to add a public key for
:ref:`ssh_key_based_authentication`.
``<location>`` can be a local path or a URL pointing at a remote file.
Supported remote protocols are FTP, FTPS, HTTP, HTTPS, SCP/SFTP and TFTP.
Example:
.. code-block:: none
alyssa@vyos:~$ generate public-key-command name alyssa path sftp://example.net/home/alyssa/.ssh/id_rsa.pub
# To add this key as an embedded key, run the following commands:
configure
set system login user alyssa authentication public-keys alyssa@example.net key AAA...
set system login user alyssa authentication public-keys alyssa@example.net type ssh-rsa
commit
save
exit
ben@vyos:~$ generate public-key-command user ben path ~/.ssh/id_rsa.pub
# To add this key as an embedded key, run the following commands:
configure
set system login user ben authentication public-keys ben@vyos key AAA...
set system login user ben authentication public-keys ben@vyos type ssh-dss
commit
save
exit

View File

@ -84,6 +84,10 @@ The third part is simply an identifier, and is for your own reference.
.. cfgcmd:: loadkey <username> <location>
**Deprecation notice:** ``loadkey`` has been deprecated in favour of
:opcmd:`generate public-key-commands` and will be removed in a future
version. See :ref:`ssh`.
SSH keys can not only be specified on the command-line but also loaded for
a given user with `<username>` from a file pointed to by `<location>.` Keys
can be either loaded from local filesystem or any given remote location

View File

@ -154,7 +154,7 @@ To replace a bad disk within a RAID 1 set, perform the following steps:
1 - Remove the failed disk from the RAID 1 set by issuing the following
command:
.. opcmd:: delete raid RAID1device member diskpartition
.. opcmd:: delete raid <RAID1device> member <diskpartition>
where RAID-1-device is the name of the RAID 1 device (for example, md0) and
disk-partition is the name of the failed disk partition (for example, sdb2).
@ -166,7 +166,7 @@ hot-swappable, then you must shut down the system before removing the disk.
4 - Format the new disk for RAID 1 by issuing the following command:
.. opcmd:: format <diskdevice1> like <diskdevice2>
.. opcmd:: format disk <diskdevice1> like <diskdevice2>
where disk-device1 is the replacement disk (for example, sdb) and
disk-device2 is the existing healthy disk (for example, sda).
@ -191,7 +191,7 @@ mirror synchronization, check and display information.
disk partition to a RAID 1 set initiates mirror synchronization, where all
data on the existing member partition is copied to the new partition.
.. opcmd:: format <diskdevice1> like <diskdevice2>
.. opcmd:: format disk <diskdevice1> like <diskdevice2>
This command is typically used to prepare a disk to be added to a preexisting
RAID 1 set (of which disk-device2 is already a member).