Securely connect applications through open networks
TLS/SSL
Managing TLS/SSL in application layer is tricky:
need to manage root CA
need to implement keys rotation
differs from service to service
and it's not always available
no support in
zookeeper for server2server TLS
clickhouse to zk connection
Wireguard
by Jason A. Donenfeld aka zx2c4
Goal
make a VPN that avoids the problems in both crypto and implementation
What is WireGuard?
Layer 3 secure network tunnel for IPv4 and IPv6.
Opinionated.
Lives in the Linux kernel, but cross platform implementations are in the works.
Modern conservative cryptographic principles.
Emphasis on simplicity and auditability.
Authentication model similar to SSH’s authenticated_keys.
Replacement for OpenVPN and IPsec.
Easily Auditable
OpenVPN – 116,730 LoC
StrongSwan – 405,894 LoC
WireGuard – 3,904 LoC
Simplicity of Interface
WireGuard presents a normal network interface:
# ip link add wg0 type wireguard
# ip address add 192.168.3.2/24 dev wg0
# ip route add default via wg0
# ifconfig wg0 …
# iptables –A INPUT -i wg0 …
Everything that ordinarily builds on top of network interfaces – like eth0 or wlan0 – can build on top of wg0.
Simplicity of Interface #2
The interface appears stateless to the system administrator.
Add an interface – wg0, wg1, wg2, … – configure its peers, and immediately packets can be sent.
Endpoints roam, like in mosh.
Identities are just the static public keys, just like SSH.
Everything else, like session state, connections, and so forth, is invisible to admin.
Cryptokey Routing
The fundamental concept of any VPN is an association between public keys of peers and the IP addresses that those peers are allowed to use.