Instruction 06-wireguard-fundamentals-and-deployment: Reading

WireGuard is a layer-3 encrypted tunnel. It transports IP packets between peers over UDP, but it does not assign users, issue certificates, provide application authentication, or automatically make a remote network routable. Every peer owns a private key and shares only its public key. A peer configuration therefore resembles a compact mapping between cryptographic identities and network prefixes.

The local Interface section contains the local private key and usually a tunnel address. A listening port is normally required on a stable server, while a roaming client can often use an automatically selected source port. Each Peer section identifies one remote system by public key. Endpoint tells the local system where to send the first encrypted packet. A stable client endpoint does not normally need to be configured on the server because the server can learn the client's current endpoint from authenticated traffic.

AllowedIPs is central to correct design. For outbound traffic, it helps select the peer that should receive a destination prefix. For inbound traffic, it limits which inner source addresses are valid for that peer. A server should generally assign a unique /32 IPv4 tunnel address to each remote-access peer rather than giving every peer the complete tunnel subnet. Overlapping entries can produce surprising peer selection and should be avoided unless the design has been carefully analyzed. AllowedIPs is not a substitute for an explicit authorization policy around services reachable through the tunnel.

PersistentKeepalive is not a generic performance setting. A value such as 25 seconds is useful when a peer behind NAT must keep an idle mapping available for unsolicited return traffic. Stable peers with direct reachability usually do not need it. Keepalive traffic also creates periodic metadata, so it should be enabled only where operationally necessary.

A split-tunnel client lists only the private destinations that belong in the tunnel. A full-tunnel client uses default prefixes, commonly 0.0.0.0/0 and ::/0, and requires deliberate planning for forwarding, DNS, IPv6, packet-filter policy, egress translation, and loss of access if the tunnel fails. Route symmetry matters in both designs: the destination network must know how to return traffic to the tunnel client, or an approved translation design must provide that return path.

A disciplined production deployment separates preparation from activation. First allocate nonconflicting addresses, document ownership, generate keys on the systems that will use them, exchange only public keys, and stage configurations with restrictive file permissions. Next validate peer key relationships, destination prefixes, endpoint resolution, UDP reachability, forwarding requirements, and return routes. Activate one peer during a maintenance window, confirm a recent handshake and bidirectional traffic, and then expand gradually. The laboratory deliberately stops before activation: it creates representative configuration artifacts under the class directory and verifies them without changing interfaces, routes, packet-filter state, services, or system configuration.