Platform support for multihop connections

[bakulf]

Platform support for multihop connections provides the functionality needed for this feature. As a high level description of how this works, we can add each server in the multihop connection to the wireguard interface as a peer, and then make use of the routing table to assemble the packet’s route.

The scope of this issue only includes the bare minimal UI, and a crude path selection algorithm, needed to test the feature.

Acceptance Criteria:

• Add a checkbox in the network settings to enable/disable the multihop feature.
  • When the checkbox is off, a single hop should be used and the client should behave as normal.
  • When the checkbox is on, two hops should be used, with the first/ingress hop being selected at random.
• The Controller class is extended to allow either one or multiple hops to be selected.
• With multihop turned on, and the VPN connected, the following must be observed:
  • The report shown by http://ipleak.net must report the user’s selected server location (exit node).
  • Running a traffic analysis tool (such as Wireshark) on the user’s default network interface must not show any packets addressed to or from the user’s selected exit node or any address within the same /24 subnet.
  • Running a traffic analysis tool on the user’s default network interface must not show any plaintext traffic addressed to a non-local address.
• This feature shall be implemented on:
  • Windows
  • Linux
  • MacOS

┆Issue is synchronized with this Jira Task

[oskirby]

The simplest approach that comes to mind would be to replace the Server class provided to the controller with a QList<Server> that describes the routing path packets need to take (with the innermost tunnel first), and in the simple case of a single-hop tunnel the platform only needs to pay attention to the first entry in the list.

When it comes to setting up the interface, it's only the innermost tunnel that would require complicated platform setup (eg: for firewall, DNS and split tunneling) The intermediate hops should be a lot simpler since they should only contain fairly well-defined traffic (UDP wiregard packets always sent to a single, well-known IP), and it would just take a single routing table entry to direct their traffic accordingly.

For quick-and-dirty UX during development, this feature could be enabled by a single boolean option and let the client pick the intermediate hop(s) randomly from the available servers until a more complex UX flow is needed.

However, this kind of simple approach might prevent us from being able to do complicated things in the future, such as directing different traffic flows along different paths, or a server switch smewhere in an intermediate hop, in which case I think we really will need some kind of multi-controller.

[data-sync-user]

➤ Valentina Virlics commented:

Verified this as a new feature for 2.5 VPN release based on the reviewed Test Cases and Test Plan;