tinc-vpn: T766: Initial support for tinc VPN #570

jack9603301 · 2020-10-15T12:52:05Z

https://phabricator.vyos.net/T766

runborg

I've done a lot of commenting on the current PR code. and have a few comments:

All yes/no options should be changed to Node object, that is the oposite of the default value. if the value is not specified the default value should be used instead
Change interface names to tincN instead of vtincN the v is not needed in this setting
the type option needs to be reconsidered, and used more understandable options.
Network name should be hardcoded to the interface name, and the user should not need to keep track of this setting
Marked some typo's
the way that tinc-up/down is laid out will not work and need to be refactored.
doing systemctl restart tinc after a config change, will that tear down the interface so it need to be fully reinitialized?

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

other than that this is great work

data/templates/tinc/tinc-up.tmpl

interface-definitions/interfaces-tinc.xml.in

op-mode-definitions/show_tinc.xml

python/vyos/ifconfig/vtinc.py

smoketest/scripts/cli/test_interfaces_tinc.py

jack9603301 · 2020-10-16T05:18:30Z

@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?

interface-definitions/interfaces-tinc.xml.in

runborg · 2020-10-16T12:16:30Z

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 · 2020-10-16T12:45:13Z

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 · 2020-10-16T12:48:57Z

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 · 2020-10-16T12:58:12Z

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)

interface-definitions/interfaces-tinc.xml.in

runborg · 2020-10-16T13:13:03Z

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 · 2020-10-16T13:17:32Z

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

interface-definitions/interfaces-tinc.xml.in

jack9603301 · 2020-10-16T18:12:42Z

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 · 2022-09-02T08:44:15Z

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

dmbaturin · 2022-09-15T16:31:22Z

Tinc facts:

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

jack9603301 · 2022-11-30T04:10:22Z

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 · 2022-12-12T15:20:23Z

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

github-actions · 2022-12-17T08:04:48Z

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

github-actions · 2023-08-07T07:19:59Z

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

github-actions · 2023-08-13T13:45:37Z

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

dmbaturin

There are quite a few improvements to make in the CLI. Please address the suggestions about spurious capitalizations, overly long lines, and other style issues (please note that many of those issues appear in many places, so if I commented on anything once, it means it applies to all similar cases, it just wouldn't be practical to duplicate those comments).

Whether we should use the PKI infrastructure for keys instead of file paths is a more interesting question, let's see what other people think. I'd be in favor of moving to PKI for consistency with OpenVPN and other components.

debian/control

op-mode-definitions/tinc.xml.in

interface-definitions/interfaces-tinc.xml.in

dmbaturin · 2023-08-13T14:31:09Z

interface-definitions/interfaces-tinc.xml.in

+        <children>
+          <leafNode name="node-name">
+            <properties>
+              <help>Local Node Name options(require)</help>


Why capitalize "Node Name"? Also, it should be [REQUIRED] as per out convention, although I'm not a big fan of it — if users miss it, the commit verification will fail and they will know, so I'd remove it altogether.

What's the meaning?

interface-definitions/interfaces-tinc.xml.in

dmbaturin · 2023-08-13T14:35:34Z

interface-definitions/interfaces-tinc.xml.in

+          </leafNode>
+          <leafNode name="mtu">
+            <properties>
+              <help>MTU(Bytes,default:1514)</help>


Why is it larger than the typical Ethernet MTU? To cause fragmentation? ;)

https://manpages.ubuntu.com/manpages/xenial/en/man5/tinc.conf.5.html

Because the description of the man manual is written as the default 1514

This can be consistent with the official default settings of tinc

dmbaturin · 2023-08-13T14:40:10Z

interface-definitions/interfaces-tinc.xml.in

+              <valueless/>
+            </properties>
+          </leafNode>
+          <leafNode name="private-keyfile">


We should probably use the PKI instrastructure now that OpenVPN etc. are using it already. I mean, set pki .... I'd be curious what @sever-sever, @c-po and others think about that.

interface-definitions/interfaces-tinc.xml.in

dmbaturin · 2023-08-31T14:41:37Z

The last release of TINC was in 2018 and there was no development activity since the last year: https://github.com/gsliepen/tinc

I believe this means TINC abandoned and cannot be included. However, if the development activity resumes and they make a stable release, we can reconsider it and reopen the PR.

marek22k · 2024-02-02T10:08:43Z

Tinc is still alive: gsliepen/tinc#443

jack9603301 force-pushed the T766 branch 5 times, most recently from 195cc7a to b5cc71f Compare October 15, 2020 16:53

runborg suggested changes Oct 15, 2020

View reviewed changes

jack9603301 force-pushed the T766 branch 2 times, most recently from 9ec47ee to e99bfac Compare October 16, 2020 05:17

jack9603301 force-pushed the T766 branch 3 times, most recently from 5a27c74 to 8d2b668 Compare October 16, 2020 05:37

jack9603301 commented Oct 16, 2020

View reviewed changes

interface-definitions/interfaces-tinc.xml.in Show resolved Hide resolved

jack9603301 force-pushed the T766 branch from 8d2b668 to 71cad43 Compare October 16, 2020 12:28

runborg reviewed Oct 16, 2020

View reviewed changes

interface-definitions/interfaces-tinc.xml.in Outdated Show resolved Hide resolved

interface-definitions/interfaces-tinc.xml.in Outdated Show resolved Hide resolved

interface-definitions/interfaces-tinc.xml.in Outdated Show resolved Hide resolved

jack9603301 commented Oct 16, 2020

View reviewed changes

interface-definitions/interfaces-tinc.xml.in Show resolved Hide resolved

jack9603301 force-pushed the T766 branch 7 times, most recently from a671981 to 23f1218 Compare October 16, 2020 17:40

jack9603301 requested review from c-po and removed request for dmbaturin, zdc, DmitriyEshenko, jestabro and sever-sever September 2, 2022 08:44

github-actions bot added the state: conflict label Dec 12, 2022

jack9603301 force-pushed the T766 branch from 3a546e7 to 577bbc5 Compare December 17, 2022 08:04

github-actions bot removed the state: conflict label Dec 17, 2022

jack9603301 force-pushed the T766 branch from 577bbc5 to 9129072 Compare December 17, 2022 08:09

jack9603301 changed the title ~~tinc-vpn:T766:Initial support for tinc VPN~~ tinc-vpn: T766: Initial support for tinc VPN Dec 17, 2022

c-po force-pushed the current branch from 6a6ea8e to 93724b5 Compare June 29, 2023 07:07

github-actions bot added the state: conflict label Aug 7, 2023

tinc-vpn: T766: Initial support for tinc VPN

b04aaf6

jack9603301 force-pushed the T766 branch from 9129072 to b04aaf6 Compare August 13, 2023 13:43

github-actions bot removed the state: conflict label Aug 13, 2023

dmbaturin requested changes Aug 13, 2023

View reviewed changes

tinc-vpn: T766: Fix some inappropriate descriptions

26518cd

jack9603301 force-pushed the T766 branch from f7ac497 to 26518cd Compare August 14, 2023 14:59

c-po added the current label Aug 25, 2023

dmbaturin closed this Aug 31, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

tinc-vpn: T766: Initial support for tinc VPN #570

tinc-vpn: T766: Initial support for tinc VPN #570

jack9603301 commented Oct 15, 2020 •

edited

runborg left a comment

jack9603301 commented Oct 16, 2020

runborg commented Oct 16, 2020 •

edited

runborg commented Oct 16, 2020 •

edited

runborg commented Oct 16, 2020

jack9603301 commented Oct 16, 2020

runborg commented Oct 16, 2020

runborg commented Oct 16, 2020

jack9603301 commented Oct 16, 2020 •

edited

jack9603301 commented Sep 2, 2022

dmbaturin commented Sep 15, 2022

jack9603301 commented Nov 30, 2022

github-actions bot commented Dec 12, 2022

github-actions bot commented Dec 17, 2022

github-actions bot commented Aug 7, 2023

github-actions bot commented Aug 13, 2023

dmbaturin left a comment

dmbaturin Aug 13, 2023

jack9603301 Aug 15, 2023

dmbaturin Aug 13, 2023

jack9603301 Aug 14, 2023

dmbaturin Aug 13, 2023

dmbaturin commented Aug 31, 2023

marek22k commented Feb 2, 2024

tinc-vpn: T766: Initial support for tinc VPN #570

tinc-vpn: T766: Initial support for tinc VPN #570

Conversation

jack9603301 commented Oct 15, 2020 • edited

runborg left a comment

Choose a reason for hiding this comment

jack9603301 commented Oct 16, 2020

runborg commented Oct 16, 2020 • edited

runborg commented Oct 16, 2020 • edited

runborg commented Oct 16, 2020

jack9603301 commented Oct 16, 2020

runborg commented Oct 16, 2020

runborg commented Oct 16, 2020

jack9603301 commented Oct 16, 2020 • edited

jack9603301 commented Sep 2, 2022

dmbaturin commented Sep 15, 2022

jack9603301 commented Nov 30, 2022

github-actions bot commented Dec 12, 2022

github-actions bot commented Dec 17, 2022

github-actions bot commented Aug 7, 2023

github-actions bot commented Aug 13, 2023

dmbaturin left a comment

Choose a reason for hiding this comment

dmbaturin Aug 13, 2023

Choose a reason for hiding this comment

jack9603301 Aug 15, 2023

Choose a reason for hiding this comment

dmbaturin Aug 13, 2023

Choose a reason for hiding this comment

jack9603301 Aug 14, 2023

Choose a reason for hiding this comment

dmbaturin Aug 13, 2023

Choose a reason for hiding this comment

dmbaturin commented Aug 31, 2023

marek22k commented Feb 2, 2024

jack9603301 commented Oct 15, 2020 •

edited

runborg commented Oct 16, 2020 •

edited

runborg commented Oct 16, 2020 •

edited

jack9603301 commented Oct 16, 2020 •

edited