tinc-vpn:T766:Initial support for tinc VPN

[jack9603301]

https://phabricator.vyos.net/T766

[jack9603301]

@runborg

on the other hand i cant find any definition of remote-nodes(hosts?), is this missing or have i just missed it?

One of the connect options is used to set the host address connected to the opposite end (the address must have a file in the hosts directory)

doing systemctl restart tinc after a config change, will that tear down the interface so it need to be fully reinitialized?

After executing systemctl restart tinc, the interface will be dismantled and reinitialized according to the specific configuration

This cannot be done this way, as there are more settings to configure on the interface. is it possible to make the execution of tinc-up trigger a rfull e-configuration of the interface from the interface class?

the way that tinc-up/down is laid out will not work and need to be refactored.

This file is used to set the basic address and fixed configuration information of the interface. I set the interface class and do more configuration in it

Network name should be hardcoded to the interface name, and the user should not need to keep track of this setting

After testing, the network parameters only take effect locally, so cancel this setting option, the network parameters will correspond to the interface name

the type option needs to be reconsidered, and used more understandable options.

Regarding equipment type parameters, do you have better suggestions for my reference?

[runborg]

This cannot be done this way, as there are more settings to configure on the interface. is it possible to make the >>execution of tinc-up trigger a rfull e-configuration of the interface from the interface class?

the way that tinc-up/down is laid out will not work and need to be refactored.

This file is used to set the basic address and fixed configuration information of the interface. I set the interface class and do more configuration in it

The address should be configured trough the configuration class and not hardcoded this way. The reason for this is that as the interface is recreated all options needs to be readded to the interface. this means that all options configured from the interface class needs to be readded..

[runborg]

About the MODE and DeviceType variables. There seems to be a correlation between these two options, following this from the documentation:

DeviceType = <type> (platform dependent)
The type of the virtual network device. Tinc will normally automatically select the right type of tun/tap interface, and this option should not be used. However, this option can be used to select one of the special interface types, if support for them is compiled in.
......
tun (BSD and Linux)
Set type to tun. Depending on the platform, this can either be with or without an address family header (see below).
tap (BSD and Linux)
Set type to tap. Tinc will expect packets read from the virtual network device to start with an Ethernet header.

and

Mode = <router|switch|hub> (router)
This option selects the way packets are routed to other daemons.

router
In this mode Subnet variables in the host configuration files will be used to form a routing table. Only unicast packets of routable protocols (IPv4 and IPv6) are supported in this mode.

This is the default mode, and unless you really know you need another mode, don’t change it.

switch
In this mode the MAC addresses of the packets on the VPN will be used to dynamically create a routing table just like an Ethernet switch does. Unicast, multicast and broadcast packets of every protocol that runs over Ethernet are supported in this mode at the cost of frequent broadcast ARP requests and routing table updates.

This mode is primarily useful if you want to bridge Ethernet segments.

hub
This mode is almost the same as the switch mode, but instead every packet will be broadcast to the other daemons while no routing table is managed.

is the deviceType/tap(ethernet header ) usable with the mode/router flag? and are the tun(without ethernet header) flag usable with the mode switch/router flag?

looking at the documentation also states that The type of the virtual network device. Tinc will normally automatically select the right type of tun/tap interface, and this option should not be used. However, this option can be used to select one of the special interface types, if support for them is compiled in.

I think we should not allow modification of deviceType and let it be autoselected by tinc itself as the author of tinc states in the documentation

[runborg]

for the mode setting the default is router (l3) so the two options available is switch and hub . these could be added by using a bridge vyos-option instead of mode switch and bridge hub instead of mode hub

[jack9603301]

About the MODE and DeviceType variables. There seems to be a correlation between these two options, following this from the documentation:

DeviceType = <type> (platform dependent)
The type of the virtual network device. Tinc will normally automatically select the right type of tun/tap interface, and this option should not be used. However, this option can be used to select one of the special interface types, if support for them is compiled in.
......
tun (BSD and Linux)
Set type to tun. Depending on the platform, this can either be with or without an address family header (see below).
tap (BSD and Linux)
Set type to tap. Tinc will expect packets read from the virtual network device to start with an Ethernet header.

and

Mode = <router|switch|hub> (router)
This option selects the way packets are routed to other daemons.

router
In this mode Subnet variables in the host configuration files will be used to form a routing table. Only unicast packets of routable protocols (IPv4 and IPv6) are supported in this mode.

This is the default mode, and unless you really know you need another mode, don’t change it.

switch
In this mode the MAC addresses of the packets on the VPN will be used to dynamically create a routing table just like an Ethernet switch does. Unicast, multicast and broadcast packets of every protocol that runs over Ethernet are supported in this mode at the cost of frequent broadcast ARP requests and routing table updates.

This mode is primarily useful if you want to bridge Ethernet segments.

hub
This mode is almost the same as the switch mode, but instead every packet will be broadcast to the other daemons while no routing table is managed.

is the deviceType/tap(ethernet header ) usable with the mode/router flag? and are the tun(without ethernet header) flag usable with the mode switch/router flag?

looking at the documentation also states that The type of the virtual network device. Tinc will normally automatically select the right type of tun/tap interface, and this option should not be used. However, this option can be used to select one of the special interface types, if support for them is compiled in.

I think we should not allow modification of deviceType and let it be autoselected by tinc itself as the author of tinc states in the documentation

Do you need to keep other options of device.type (except tun and tap)

[runborg]

About the MODE and DeviceType variables. There seems to be a correlation between these two options, following this from the documentation:

DeviceType = <type> (platform dependent)
The type of the virtual network device. Tinc will normally automatically select the right type of tun/tap interface, and this option should not be used. However, this option can be used to select one of the special interface types, if support for them is compiled in.
......
tun (BSD and Linux)
Set type to tun. Depending on the platform, this can either be with or without an address family header (see below).
tap (BSD and Linux)
Set type to tap. Tinc will expect packets read from the virtual network device to start with an Ethernet header.

and

Mode = <router|switch|hub> (router)
This option selects the way packets are routed to other daemons.

router
In this mode Subnet variables in the host configuration files will be used to form a routing table. Only unicast packets of routable protocols (IPv4 and IPv6) are supported in this mode.

This is the default mode, and unless you really know you need another mode, don’t change it.

switch
In this mode the MAC addresses of the packets on the VPN will be used to dynamically create a routing table just like an Ethernet switch does. Unicast, multicast and broadcast packets of every protocol that runs over Ethernet are supported in this mode at the cost of frequent broadcast ARP requests and routing table updates.

This mode is primarily useful if you want to bridge Ethernet segments.

hub
This mode is almost the same as the switch mode, but instead every packet will be broadcast to the other daemons while no routing table is managed.

is the deviceType/tap(ethernet header ) usable with the mode/router flag? and are the tun(without ethernet header) flag usable with the mode switch/router flag? looking at the documentation also states that The type of the virtual network device. Tinc will normally automatically select the right type of tun/tap interface, and this option should not be used. However, this option can be used to select one of the special interface types, if support for them is compiled in. I think we should not allow modification of deviceType and let it be autoselected by tinc itself as the author of tinc states in the documentation

Do you need to keep other options of device.type (except tun and tap)

I do not see a need to keep any of the other options. i'm proposing removing the deviceType option in its entirely and it could be readded if there is a demand at a later time

[runborg]

on the other hand i cant find any definition of remote-nodes(hosts?), is this missing or have i just missed it?

One of the connect options is used to set the host address connected to the opposite end (the address must have a file in the hosts directory)

This is not what i ment. All hosts (remote nodes) needs to be defined with its own configuration files and encryption public keys. these are not defined anywhere as i can see. the ConnectTo option only specifies what primary endpoint should be tried to connect to. all connect statements also needs a corresponding host config

[jack9603301]

Normally, the following command is used to generate the host configuration file

set interfaces tinc tinc0 subnet 192.168.10.0/24
set interfaces tinc tinc0 local_address my_service_address
set interfaces tinc tinc0 port 1002
set interfaces tinc tinc0 private-keyfile private-keyfile

The local node configuration file is automatically generated in this way, without other instructions and configuration intervention

Some other options also come from the host configuration file, but it seems that they can be written in tinc.conf

I plan to download files from remote using the following command:

op-mode:

generate tinc tinc0 host-conf root@ip:/path

or

generate tinc tinc0 host-conf /path

To copy the hosts file

To use ConnectTo, you need to specify a host file:

set interfaces tinc tinc0 connect service conf-path root@ip:/path

or

set interfaces tinc tinc0 connect service conf-path /path

When the file soft link does not exist, it will be copied automatically (soft link is created, and the file pointed to here cannot be deleted, otherwise it will cause an exception)

[jack9603301]

@runborg If there are no other problems, I will consider doing the final test in GNS3

[jack9603301]

@runborg

vyos@fc00:1::1's password: 
scp: /config/tinc0/hosts/r1: Permission denied

I don’t know why, using scp will always report denial of permission, and there is no information even when calling in the call.

User belonging is a problem

[jack9603301]

I tried to obtain it automatically, but it is not easy in the special environment of cli. The exchange process still needs to be done manually. The host configuration of the local node is automatically generated, so the exchange becomes very easy (just copy the file) Please see https://phabricator.vyos.net/T766

[jack9603301]

Note that vyos tinc support is based on tinc 1.1 instead of 1.0

[jack9603301]

Note: The latest fix has not been tested yet, I will test it in these two days

[jack9603301]

Tested today, the generated tinc directory layout is consistent with expectations

[msenebald]

I wait for this to become active. I will integrate that in my tinc mesh for testing asap. :)

[jack9603301]

It depends on tinc 1.1, so someone needs to build the DEB of tinc and pass it to the apt repo of vyos

[jack9603301]

https://salsa.debian.org/guus/tinc.git

The following patches are required:

diff --git a/debian/postinst b/debian/postinst
index e05f787..1501922 100644
--- a/debian/postinst
+++ b/debian/postinst
@@ -2,10 +2,15 @@
 
 NETSFILE="/etc/tinc/nets.boot"
 
+NETSFILE_CONF="/etc/tinc"
+
 set -e
 
 case "$1" in
     configure)
+    if [ ! -e $NETSFILE_CONF ] ; then
+        mkdir $NETSFILE_CONF
+    fi
 	if [ ! -e $NETSFILE ] ; then
 	    echo "## This file contains all names of the networks to be started on system startup." > $NETSFILE
 	fi

It is suggested that vyos establish its own repo to build DEB and track the upstream version updates

[jack9603301]

The official upstream address is https://gitlab.com/gsliepen/tinc , no Debian package generation rule file

[sever-sever]

Re-check please all whitespaces after ',' and '=' Re-check please imported modules.

deepcopy
defaults
dict_merge
verify_interface_exists
verify_mtu
verify_mtu_ipv6
verify_vlan_config

[jack9603301]

Re-check please all whitespaces after ',' and '=' Re-check please imported modules.

deepcopy
defaults
dict_merge
verify_interface_exists
verify_mtu
verify_mtu_ipv6
verify_vlan_config

done

[github-actions[bot]]

This pull request has conflicts, please resolve those before we can evaluate the pull request.

[github-actions[bot]]

Conflicts have been resolved. A maintainer will review the pull request shortly.

[github-actions[bot]]

This pull request has conflicts, please resolve those before we can evaluate the pull request.

[github-actions[bot]]

Conflicts have been resolved. A maintainer will review the pull request shortly.

[github-actions[bot]]

This pull request has conflicts, please resolve those before we can evaluate the pull request.

[github-actions[bot]]

Conflicts have been resolved. A maintainer will review the pull request shortly.

[jack9603301]

Seems to be lost in late conflict resolution, I've manually restored this and kept the mainline in sync

[dmbaturin]

Tinc facts:

• Last official release: 2019 (1.0.36)
• Last commit to the development branch, as of today: three months ago.

[jack9603301]

Tinc facts:

* Last official release: 2019 (1.0.36)

* Last commit to the development branch, as of today: three months ago.

you mean?

[github-actions[bot]]

This pull request has conflicts, please resolve those before we can evaluate the pull request.