| .vscode | ||
| crypto | ||
| host | ||
| net | ||
| node | ||
| proto | ||
| rpc | ||
| tests | ||
| .gitignore | ||
| go.mod | ||
| go.sum | ||
| LICENSE | ||
| main.go | ||
| README.md | ||
lux
Lain Uplink eXchange
______________ ______________
| | | |
| Node A | Interior | Node B |
| | <------------> | |
| State | State | State |
______________ ______________
^ ^
E | | I
x | | n
t | | t
e | | e
r | | r
i | | i
o | | o
r | | r
| |
______________ ______________
| | | |
| Host 1 | | Host 2 |
| | | |
| | | |
______________ ______________
Node
Each node receives heartbeats from various hosts and registers their status, name, WAN IP and operating time via external connections. Each host can only query information about other hosts via internal connections. The status must remain the same for all nodes so that a failover can be configured.
The node can also provide a DNS server front-end for easy integration with DNS resolvers such as unbound, dnsmasq or systemd-resolved.
Exterior and Interior
An external connection is made via a medium with low trustworthiness, e.g. the WAN Internet, which is why the encryption layer protects against replay attacks and ensures the uniqueness of the packets.
Internal connections are established via a medium with high trustworthiness, e.g. VPN tunnels such as OpenVPN or Tailscale. Only internal connections can be used to synchronize the status between the nodes.
Host
Each host sends a heartbeat and thus transmits its status - such as WAN IP, operating time, resource utilization. Hosts can send a heartbeat via external and internal connections, but the information request can only be made via internal connections, and the status can only be synchronized via internal connections, because at the time of the request or synchronization, the external uplink information, such as the WAN IP, may not be read out; therefore, the internal connection must always be available and cost-effective.
State
Host's state consists of:
- Hostname(+.lux)
- WAN IP
The state of the node is a table of the states of the hosts + their last heartbeat time. The state of the node must also contain the generation ID, which must be guaranteed to be unique within the last 128 generations. A new generation should only take place if one of the hosts has a new heartbeat.
Sync state broadcast
Once consensus has been reached, the state must be synchronized across all nodes. To achieve this, neighbouring nodes must be recognized and registered.
The sending process is as follows.
- the list of neighbors must already be created (through neighbor discovery)
- the sync packet is formed and contains the list of nodes to which it is addressed: all neighbors (except the sending node)
- the sync packet is sent to all nodes via internal connections
- so that the transmission does not end in a loop and is short, each node must merge its neighbor list when the sync packet arrives - in this way, neighbor discovery will also take place, update the node's neighbor list and/or add new nodes to the broadcast
- remember the generation ID of the sync packet and ignore all other sync packets with the same generation ID.
This procedure will cause a tolerable but still good amount of packet storms, but it will also serve to resend packets if they are lost on the network path.
Encryption
The symmetric cipher AES-256 is used for communication from host to node and from node to node.
Each node has a node key and the node stores the host key for each host. The host must be configured with its host key, which is provided by the node.
The node key is only used for node-to-node communication and must be kept secret unless another node is used.
Identification
Each host and each node has its own unique UUID, which is used for packet addressing.
Software architecture
- Config are defined as INI files.
- Daemon that runs continuously and operates the protocol. Also provides a UNIX socket for the CLI configuration
- CLI for communication with UNIX socket and for issuing commands