wirehub - decentralized, peer-to-peer and secure overlay networks built with WireGuard

[Gawen ARAB <g@wenarab.com>]

[-- Attachment #1.1: Type: text/plain, Size: 3518 bytes --]

Hello,

I've been giving my free time on a side project called WireHub
(https://github.com/gawen/wirehub), which is a simple tool to build
decentralized, peer-to-peer and secure overlay networks. It dynamically
configures WireGuard tunnels, discoverying peers' endpoints via a
authenticated
DHT, going through NATs, and relaying the WireGuard traffic if no P2P
communication is possible.

Overlay networks are defined by a single human-readable file which lists the
hostname and public key for each nodes of the network. Here's an example:

    name test               # network name is 'test'
    subnet 10.0.42.0/24     # overlay subnetwork is 10.0.42.0/24
    workbit 8               # PoW parameter for DHT security

    # a public bootstrap node
    boot P17zMwXJFbBdJEn05RFIMADw9TX5_m2xgf31OgNKX3w bootstrap.wirehub.io

    # Add trusted node 'a.test' to the overlay network.
    # Each trusted node are at least identified by an human-readable
hostname
    # and a base64 public key.
    trust a.test KJ7YGrBeqLLm_JJ1huIS26OnqAVFy57z5UJqjyMagW4

    # If the endpoint of a peer is static, it might be set after the public
key.
    # Note that this is optional, as endpoints can be dynamically found in
the
    # DHT.
    trust b.test eIix5ldvqDzOIrG9ViKTe9TSBlF4g9nUwKi20C06hFM 12.34.56.78

    # By default WireHub assigns nodes an (overlay) private IP, but a static
    # private IP might be defined
    trust c.test 10.0.42.254 kKZzuIm11zkBSHL9ETRwEthIBbLTvz840F_k4mhI_Hs
    ...

To start a peer,

    # wh up ./config private-key ./sk

When a network is up, the node's hostnames are resolved in userland.

    # ping b.test
    PING 10.0.42.2 (10.0.42.2): 56 data bytes
    64 bytes from 10.0.42.2: seq=0 ttl=64 time=106.801 ms
    64 bytes from 10.0.42.2: seq=1 ttl=64 time=49.778 ms

WireGuard and WireHub uses the same Curve25519 key. WireHub keys must be
generated with `wh genkey`, which adds a Proof-of-Work to the generation of
the
Curve25519 key, in order to mitigate Sybil attacks on the DHT. A high
workbit
will require more work to generate a valid key.

    # wh genkey workbit 8       # fast
    MFaqLuutFvNs79Xc9zhOUofIbL3xSLz1uo+RB1xB73s=
    # wh genkey workbit 8 | wh pubkey | wh workbit
    8
    # wh genkey workbit 16      # will take more time to generate
    kLfotsCIfB/7OcDGeLenptfy2Dzav9wmVZjVQ0Gvnk0=
    # wh genkey workbit 16 | wh pubkey | wh workbit
    16

    # wg genkey | wh pubkey | wh workbit    # WireGuard keys have 0 workbit
    0

Under the hood, WireHub runs its own UDP protocol, binding the same UDP port
than the WireGuard interface (for NAT trasversal technique reasons). It
does so using
libpcap. The first byte of a WireHub packet is 0xff, which corresponds to an
invalid WireGuard packet with message type outside the valid range
0x00-0x03.

WireHub currently authenticates its packets with a custom cryptographic
scheme
based on the node's keys. In the future, it might be better to tunnel
WireHub
packets through WireGuard, yet I'm not sure how to do that simply at the
moment,
as WireHub packets are not IP packets but more like authenticated messages.

There's much room for improvement (security, allowed-ips management, more
UDP
hole punching techniques, faster relaying), but it's usable. Docker images
are
provided to ease quick starting.

Feel free to test and give some feedbacks!

Also, I'll be at FOSDEM 2019 next week-end, so see you there! 🍺

Gawen

[-- Attachment #1.2: Type: text/html, Size: 4120 bytes --]

[-- Attachment #2: Type: text/plain, Size: 148 bytes --]

_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard