WireGuard Part 2: Introduction to WireGuard - Fast, Modern, Secure VPN Tunnels

Synopsis of the series:

1. WireGuard article series (1): What is a VPN?

WireGuard® is a very simple, fast, and modern VPN that it takes advantage ofState-of-the-art cryptology。 It is designed to be better than IPsecFaster，Simpler, leaner and more useful while avoiding huge headaches. It has much higher performance than OpenVPN. WireGuard is designed as a general-purpose VPN designed to run on embedded interfaces and supercomputers for many different situations. It was originally released for the Linux kernel and is now cross-platform (Windows, macOS, BSD, iOS, Android) and can be widely deployed. It’s currently undergoing a lot of development, but it’s already considered the safest, easiest to use, and easiest VPN solution in the industry.

As of January 2020, it has been incorporated into the Linux kernel 5.6 version, which means that most users of Linux distributions will have an out-of-the-box WireGuard.

WireGuard advantages

Simple and easy to use

WireGuard is designed to be as easy to configure and deploy as SSH. VPN connections are made possible simply by exchanging very simple public keys - just like exchanging SSH keys - and everything else is handled transparently by WireGuard. It is even able to roam between IP addresses, like Mosh The same. There’s no need to manage connections, keep an eye on state, manage daemons, or worry about what’s behind the scenes. WireGuard offers a very basic but powerful interface.

Sound encryption

WireGuard uses state-of-the-art cryptography such as Noise protocol framework，Curve25519，ChaCha20，Poly1305，BLAKE2，SipHash24，HKDF and secure trusted structures. It has made conservative and reasonable choices and has been vetted by cryptographers.

Minimum attack surface

WireGuard was designed with ease of implementation and simplicity in mind. It means easy implementation in few lines of code and easy to audit security vulnerabilities. Compared to behemoths like *Swan/IPsec or OpenVPN/OpenSSL, auditing a huge code base is a daunting task even for large teams of security experts, and WireGuard means that it can be fully vetted by a single person.

Performance

The combination of extremely high-speed cryptographic primitives and the fact that WireGuard exists in the Linux kernel means that secure nets can be very high-speed. It is suitable for small embedded devices such as smartphones and fully loaded backbone routers.

Performance test comparison of WireGuard with other VPN protocols:

Well defined and well thought out

WireGuard is the result of a long and thoroughly considered academic process that was produced Technical white papers, an academic research paper that clearly defines the protocol and the intense considerations for each decision.

WireGuard securely encapsulates IP packets over UDP. You can add a WireGuard interface, configure it with your private key and the public key of your peers, and then send packets through it. All problems with key distribution and push configuration are outside the scope of WireGuard; These issues are best left to other layers so as not to end up with bloat like IKE or OpenVPN. In contrast, it mimics the models of SSH and Mosh more; Both parties have the other’s public key, and then they can start transchanging packets by interchange.

Simple network interface

WireGuard works by adding one (or more) interfaces, for example eth0 or wlan0 Called wg0 (orwg1、wg2、wg3 etc.). It can then be used ifconfig(8) or ip-address(8) Configure the interface normally and use it route(8) or ip-route(8) Add or remove routes for that network interface, and so on, using all common network utilities. Specific WireGuard aspects of this interface are used wg(8) Tool configuration. This interface is equivalent to a tunnel interface.

WireGuard associates a tunnel IP address with a public key and a remote endpoint. When an interface sends a packet to a peer, it does the following:

1. This packet is for 192.168.30.8. Which peer is that? Let me see… Found it, this is for peers ABCDEFGHPreparatory. (Or, if it is not for any configured peers, drop the packet.) )
2. Use peers ABCDEFGH The public key encrypts the entire IP packet.
3. peer ABCDEFGH What is the remote endpoint? Let me see… Found and the endpoint is UDP port 53133 on host 216.58.211.110.
4. Use UDP to send the encrypted bytes from step 2 over the Internet to 216.58.211.110:53133.

This happens when the interface receives the packet:

1. I just got a packet from UDP port 7361 on host 98.139.183.24. Let’s decrypt it!
2. Peer LMNOPQRS Proper decryption and verification was carried out. Okay, let’s remember, peer LMNOPQRS The latest internet endpoint is 98.139.183.24:7361, using UDP.
3. After decryption, the plaintext packet comes from 192.168.43.89. Whether peers are allowed LMNOPQRS Send us a packet as 192.168.43.89?
4. If so, accept the packet on the interface. If not, give up.

Behind the scenes, using state-of-the-art encryption technology, proper privacy, authenticity, and perfect forward secrecy can be provided.

Encryption key routing

The core of WireGuard is a program called Cryptokey Routing concept, which works by associating a public key with a list of tunnel IP addresses allowed in the tunnel. Each network interface has a private key and a peer list. Each peer has a public key. Public keys are short and simple, and are used by peers to authenticate each other. They can be passed in the configuration file through any out-of-band method, similar to sending their SSH public key to a friend to access a shell server.

For example, a server computer might have the following configuration:

[Interface]
PrivateKey = yAnz5TF+lXXJte14tji3zlMNq+hd2rYUIgJBgB3fBmk=
ListenPort = 51820

[Peer]
PublicKey = xTIBA5rboUvnH4htodjb6e697QjLERt1NAB4mZqp8Dg=
AllowedIPs = 10.192.122.3/32, 10.192.124.1/24

[Peer]
PublicKey = TrMvSoP4jYQlY6RIzBgbssQqY3vxI2Pi+y71lOWWXX0=
AllowedIPs = 10.192.122.4/32, 192.168.0.0/16

[Peer]
PublicKey = gN65BkIKy1eCE9pP1wdc8ROUtkHLF2PfAqYdyYBz6EA=
AllowedIPs = 10.10.10.230/32

Client computers may have the following simpler configuration:

[Interface]
PrivateKey = gI6EdUSYvn8ugXOt8QQD6Yc+JyiZxIhp3GInSWRfWGE=
ListenPort = 21841

[Peer]
PublicKey = HIgo9xNzJMWLKASShiTqIybxZ0U3wGLiUeJ1PKf8ykw=
Endpoint = 192.95.5.69:51820
AllowedIPs = 0.0.0.0/0

In a server configuration, each peer (client) will be able to send packets to a network interface with a source IP that matches the corresponding list of allowed IPs. For example, when the server is from a peer gN65BkIK... After receiving a packet, if its source IP is 10.10.10.230, it is allowed to enter the interface after decryption and authentication; Otherwise it is discarded.

In a server configuration, when an interface wants to send a packet to a peer (client), it looks at the destination IP of the packet and compares it to each peer’s list of allowed IPs to determine which peer to send it to. For example, if the network interface is required to send a packet with a destination IP of 10.10.10.230, it will use peer gN65BkIK...encrypts it with the public key, and then sends it to the node’s closest Internet endpoint.

In a client configuration, its single peer (server) will be able to send packets toAny source IPnetwork interface (because 0.0.0.0/0 is a wildcard). For example, when a packet is from a peer HIgo9xNz...Received, if it properly decrypts and authenticates any source IP, then it can enter the interface; Otherwise it is discarded.

In a client configuration, it is used when a network interface wants to send a packet to its single peer (server).Any destination IP addressEncrypts a single peer’s package (because 0.0.0.0/0 is a wildcard). For example, if an interface is required to send packets with arbitrary destination IPs, it will use a single peer HIgo9xNz... The public key encrypts it and then sends it to the Internet endpoint closest to the peer.

In other words, when a packet is sent, the allowed IP list behaves as a routing table, and when a packet is received, the allowed IP list behaves as an access control list.

That’s what we’re talking about Cryptokey Routing Table: Simple association of public keys and allowed IPs.

For any field, you can use any combination of IPv4 and IPv6. If necessary, Wireguard is perfectly capable of encapsulating one inside the other.

Because all packets sent on the WireGuard interface are encrypted and authenticated, and because there is such a tight coupling between the peer’s identity and the IP address allowed by the peer, system administrators do not need complex firewall extensions (such as in the case of IPsec), but can simply match “Does it come from this IP?” On this interface?" and make sure it is a secure and authentic packet. This greatly simplifies network management and access control, and provides more assurance that your iptables rules are actually doing what you want them to do.

Built-in roaming

The client configuration contains its single peer (server).initialAn endpoint so that it knows where to send encrypted data before it receives it. The server configuration does not have any initial endpoints for its peers (clients). This is because the server discovers the endpoint of its peers by checking the source of the data for proper authentication. If the server itself changes its own endpoint and sends data to the client, the client discovers the new server endpoint and updates the same configuration. Both the client and server send the encrypted data to the latest IP endpoint for which they actually decrypt the data. Therefore, there is full IP roaming on both ends.

The container is ready

WireGuard Send and receive encrypted packets using the network namespace where the WireGuard interface was originally created。 This means that you can create a WireGuard interface in the main network namespace (which can access the Internet) and then move it to the network namespace that belongs to the Docker container as the container’ssoleInterface. This ensures that the only possible way for containers to access the network is through a secure, encrypted WireGuard tunnel.

Summary of WireGuard benefits

• Simple and easy to use
• Sound encryption
• Minimum attack surface
• High performance: Faster connection speeds and lower latency than current mainstream VPN protocols
• Simple network interface: Just like a normal Ethernet interface, it runs as a Linux kernel module with a small resource footprint.
• Encryption key routing: More advanced encryption technology is used, with forward encryption and resistance to downgrade attacks.
• Built-in roaming
• Container-ready: You can run in the host to provide communication between containers, or you can run in the container to provide communication between hosts.
• The ability to route some or all of your traffic over VPN to any host within your LAN.
• The ability to automatically reconnect after recovering from a network failure is an advantage over other VPNs
• Supports any type of Layer 2 network communication, eg ARP、DHCP and ICMP, not just TCP/HTTP. For example, VPN peers can ping each other

WireGuard glossary

Peer/Node/Device

Peer: Peer.

A host that connects to the VPN and registers itself with a VPN subnet address, such as 10.4.1.3. You can also select routes for IP addresses other than their own addresses by specifying subnet ranges with comma-separated CIDRs.

Relay Server (Bounce Server)

It’s essentially a peer, just that peer Public network reachable, you can relay traffic to NAT Other peer nodes behind (e.g., home computers, NAS).Bounce Server It’s not a special node, it’s the same as other peer nodes, the only difference is that it has a public IP, andKernel-level IP forwarding is turned on, you can forward traffic from the VPN to other clients.

Subnet

A set of private IPs, for example 10.4.1.1-255 or 192.168.1.1/24, typically behind a NAT, such as an office LAN or home network.

NAT

The private IP address of the subnet is provided by the router, and the private subnet device cannot be directly accessed through the public network, and the network address translation needs to be performed through NAT. The router keeps track of the outgoing connection and forwards the response to the correct internal IP.

Public Endpoint

Public IP address of the node: Port, for example 123.124.125.126:1234, or use the domain name directly some.domain.tld:1234。 If the peers are not in the same subnet, the public endpoints of the nodes must use a public IP address.

Private key

The WireGuard private key for a single node, generated by:wg genkey > example.key。

Public key

The WireGuard public key for a single node, generated by:wg pubkey < example.key > example.key.pub。

DNS

Domain name servers, which resolve domain names to the IP of VPN clients and prevent DNS requests from leaking out of the VPN.

How WireGuard works

How Relay Server works

The Bounce Server is the same as a normal peer, it can be used in NAT Behind VPN clients act as relay servers between each other, forwarding any VPN subnet traffic received to the correct peer. In fact, WireGuard does not care how traffic is forwarded, this is determined by the system kernel iptables Rule processing.

If all peers are publicly reachable, relay servers do not need to be considered, only if there are peers behind NAT.

In WireGuard, the client and server are basically equal, the difference is only who actively connects to whom。 Both parties listen on a UDP port, and whoever actively connects is the client. The actively connected client needs to specify the public network address and port of the peer, while the passively connected server does not need to specify the address and port of other peers. If both the client and the server are behind NAT, a relay server needs to be added, and both the client and the server designate the relay server as the peer node, and their traffic will enter the relay server first and then forward to the peer.

WireGuard supports roaming, which means that no matter whose address changes on both sides, WireGuard will remember its new address when it sees the other talking from the new address (like mosh, but in both directions). So both parties should always be online and communicate frequently enough (such as configuration persistent-keepalive), the IP on both sides is not fixed or affected.

How Wireguard routes traffic

WireGuard can be used to build very complex structuresNetwork topologyHere are a few typical topologies:

Point-to-point

This is the simplest topology, where all nodes are either on the same LAN or directly accessed through the public network, so that they are connected WireGuard Can be connected directly to the peer without the need for trunk hopping.

Hub-and-spoke

One end is located behind NAT, and the other end is directly exposed through the public network

In this case, the simplest solution is to use the exposed end of the public network as the server, specify the public network address and port of the server, and then pass through persistent-keepalive option Maintain a persistent connection so that NAT remembers the corresponding mapping.

Both ends are behind NAT and connected through a relay server

In most cases, when both communicating parties are behind NAT, NAT will do source port randomization, and direct connection may be difficult. You can add a relay server, both communicating partners use the relay server as a peer, and then maintain a long connection, and traffic will be forwarded through the relay server.

brief summary

In the world of WireGuard, there is no server and client, all nodes are Peer。 The common way for everyone to use WireGuard is to find a node as a transit node, that is, a VPN gateway, and then all nodes are connected to this gateway, and all nodes communicate through this gateway. In this architecture, for ease of understanding, we can think of the gateway as a server, and other nodes as clients, but in fact there is no distinction between servers and clients. An example schema is shown in the following figure:

The disadvantages of this architecture are quite obvious:

• When there are more and more peers, the VPN gateway becomes a bottleneck for vertical scaling.
• The cost of forwarding traffic through a VPN gateway is high, after all, traffic from cloud servers is expensive.
• Forwarding traffic through a VPN gateway introduces high latency.

Full mesh

✔️ focus：

The focus of this Wireguard follow-up is to implement a full mesh network.
Whether it’s a VPN network or a K8S network.

The book continues from above, what kind of architecture is the fully connected model? Suppose there are five nodes, each node establishes a WireGuard tunnel with other nodes, the architecture is shown in the figure:

The immediate advantage of this architecture is speed! Any one peer and all other peers are directly connected without transit traffic. So how to achieve a fully connected mode in the case of WireGuard? In fact, this problem is not difficult, the difficulty lies in the cumbersome level of configuration, but there are already many open source tools to help automate the configuration of WireGuard Full Mesh, and I will detail my implementation of WireGuard’s Full Mesh network through a tool such as NetMaker later.

Why do you need a full mesh?

Taking me as an example, I took advantage of Double 11 to buy (薅) a cloud server with an average price of 80 yuan per year for 1C2G from Ali, Tencent, Baidu, Huawei, and Tianyi Cloud, then:

1. On the one hand, these servers can be combined into a fully interconnected intranet through WireGuard Full mesh;
2. On the other hand, you can use K8S network plugins (such as Flannel, Cilium, etc.) to form a cross-cloud K8S cluster with WireGuard;
3. Local home networks, mobile devices and computers can be fully interconnected with the cloud network;
4. Further, you can use your home NAS and nodes of computers and cloud servers to form WireGuard tunnels, and then local AllowedIPs The addition of pod network blocks and service network blocks is equivalent to the two-way connection solution between the K8S local and development environments, which can greatly improve development efficiency;
5. Further, even devices at home can join a K8S cluster on the cloud as one of the nodes.
6. …

It’s still very tempting~ 😍😍😍

Summary of key principles and implementations

• When a packet is sent, the list of allowed IPs appears as oneRouting table, and when receiving packets, the behavior of the allowed IP list is oneAccess Control Lists (ACLs)。
• WireGuard only has the concept of peers, and in principle there is no difference between server and client
• In WireGuard, the client and server are basically equal (they are peers), the difference is only who actively connects to whom
• Define which address range the local node should route. If it is a regular client, set it to a single IP of the node itself (specified with CIDR, for example, 10.88.60.2/32); If it is a relay server, set it to a routable subnet range.
• The relay server must define all clients as peers, and no clients other than the relay server can define a node behind NAT as a peer because the route is unreachable. For those clients that route traffic only for themselves, simply treat the relay server as a peer, and other nodes that need direct access.
• If the peer is behind a NAT or does not have a stable public network access address, the endpoint is ignored.

Resources

• WireGuard official website
• WireGuard tutorial: How WireGuard works by Michelangel Young
• Wireguard full mesh configuration guide by Michelangel Young