💾 Archived View for thrig.me › tech › wireguard captured on 2024-12-17 at 10:45:11. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
Some wireguard documentation mostly for me to get gooder at it, having not ever done much with VPN and generally using SSH for remote access—yes, you can tunnel DNS over a SSH connection using a TCP channel, but that's a different story.
Some basics about network masks
Manually setup a do-nothing tunnel
OpenBSD wireguard server setup and ruminations
Why not a VPN? For one, I had SSH, and was doing unix systems administration, so did not much need remote VPN services. Another point was that VPN software prior to wireguard could be a trifle complicated to setup—what's a left and a right server??—and I was never in a position to support a VPN service for users who would need a VPN. So, mostly all SSH, not much VPN until wireguard had been out for a few years.
Clients owned by other users, or clients that you do not trust may need stricter firewall rules on the server so that an attacker cannot leverage client access into access to other systems on the network. In this case, it may make sense to use distinct wg* devices for each client, or to better isolate the clients from one another via firewall rules, and to restrict what services the clients can access on the server. Rate limiting and logging may also be necessary to detect nefarious activity (or a buggy system or user struggling to do something). Firewalls may not do much if all the attacks take place over HTTPS to other systems that support HTTPS, and HTTPS traffic is allowed by the firewall. Still, you may not want to give an untrusted client open access to an internal SMTP server, as cleaning up after a spam flood is not pretty, and it may be easier to allow a few ports, and deny all else by default.