# ip route add default dev wg0 table 2468 The most obvious usage of this is to give containers (like Docker containers, for example) a WireGuard interface as its sole interface. This opens up some very nice possibilities. (Note that this same technique is available to userspace TUN-based interfaces, by creating a socket file-descriptor in one namespace, before changing to another namespace and keeping the file-descriptor from the previous namespace open.) Namely, you can create the WireGuard interface in one namespace (A), move it to another (B), and have cleartext packets sent from namespace B get sent encrypted through a UDP socket in namespace A. This allows for some very cool properties. This socket always lives in namespace A – the original birthplace namespace.
WireGuard uses a UDP socket for actually sending and receiving encrypted packets. "I was created in namespace A." Later, WireGuard can be moved to new namespaces ("I'm moving to namespace B."), but it will still remember that it originated in namespace A. When a WireGuard interface is created (with ip link add wg0 type wireguard), it remembers the namespace in which it was created. WireGuard does something quite interesting. This means an administrator can have several entirely different networking subsystems and choose which interfaces live in each. Like all Linux network interfaces, WireGuard integrates into the network namespace infrastructure.
0 kommentar(er)
