mirror of
https://github.com/vyos/vyos-documentation.git
synced 2025-10-26 08:41:46 +01:00
Merge branch 'equuleus' of github.com:vyos/vyos-documentation into equuleus
This commit is contained in:
commit
db42af861e
@ -1 +1 @@
|
||||
Subproject commit 7c23d8a1de26b13e948c83a30771da259e9a59e8
|
||||
Subproject commit b1449aa2bd2008f51b75a9976108f416209a5567
|
||||
@ -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
|
||||
----------------------
|
||||
|
||||
@ -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
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
@ -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
@ -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
|
||||
|
||||
@ -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
|
||||
@ -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
@ -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
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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 RAID‐1‐device member disk‐partition
|
||||
.. opcmd:: delete raid <RAID‐1‐device> member <disk‐partition>
|
||||
|
||||
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 <disk‐device1> like <disk‐device2>
|
||||
.. opcmd:: format disk <disk‐device1> like <disk‐device2>
|
||||
|
||||
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 <disk‐device1> like <disk‐device2>
|
||||
.. opcmd:: format disk <disk‐device1> like <disk‐device2>
|
||||
|
||||
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).
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user