From: Matt Birkholz Date: Mon, 16 Jun 2025 00:42:50 +0000 (-0600) Subject: Remove all mention of OpenVPN; draft instructions for WireGuard™. X-Git-Url: https://birchwood-abbey.net/git?a=commitdiff_plain;h=01e3f7ac93702c37569c1b6ebed1f072751ad362;p=Network Remove all mention of OpenVPN; draft instructions for WireGuard™. --- diff --git a/README.org b/README.org index ed8b63a..ed6a884 100644 --- a/README.org +++ b/README.org @@ -106,7 +106,7 @@ into [[file:private_ex/vars-abbey.yml][=private_ex/vars-abbey.yml=]]. Birchwood Abbey's front door is a Digital Ocean Droplet configured as A Small Institute Front. Thus it is already serving a public web site with Apache2, spooling email with Postfix and serving it with -Dovecot-IMAPd, and hosting a VPN with OpenVPN. +Dovecot-IMAPd, and hosting a VPN with WireGuard™. ** Install Emacs @@ -3042,8 +3042,7 @@ Institutional sub-commands: - new :: Create system accounts for a new member. - old :: Disable system accounts for a former member. - pass :: Set the password of a current member. -- client :: Produce an OpenVPN configuration (=.ovpn=) file for a - member's device. +- client :: Register WireGuard™ public keys for a member's device. Liturgical sub-commands: @@ -3311,8 +3310,8 @@ Ansible. ** IoT Devices A wireless IoT device (smart TV, Blu-ray deck, etc.) cannot install -Debian nor even an OpenVPN app from F-Droid. And it shouldn't. As an -untrustworthy bit of kit, it should have no access to the cloister, +Debian nor even the WireGuard™ For Android app. And it shouldn't. As +an untrustworthy bit of kit, it should have no access to the cloister, merely the Internet. It need not appear in the Ansible inventory. IoT devices trusted enough to be patched to the cloister Ethernet (IP @@ -3593,136 +3592,144 @@ special configuration. Any Wi-Fi access point, e.g. as found in a cable modem, will work with zero configuration. The abbey's networks, however, are /not/ accessible except via the cloister VPN. -Connections to the cloister VPN are authorized by OpenVPN -configuration (=.ovpn=) files generated by the ~./abbey client...~ -command (aka [[file:Institute/README.org::*The Client Command][The Client Command]]). These are secret files, kept -readable only by their owners and are deleted after use. They are -copied to new OpenVPN clients using secure (~ssh~) connections. +Connections to the cloister VPN are authorized by the ~./abbey +client...~ command (aka [[file:Institute/README.org::*The Client Command][The Client Command]]), which registers a new +client's public key and installs new WireGuard™ configurations on the +servers. Private keys are kept on the clients (e.g. in +=/etc/wireguard/private-key=). + +*** Campus Desktops and Servers + +Wireless Debian desktops (with NetworkManager) as well as servers +(/without/ NetworkManager) are configured to automatically connect to +the cloister Wi-Fi and VPN, and so can be used much like a wired +desktop machine. They are typically connected to a large TV and +auto-login to an unprivileged account named ~house~, i.e. anyone in +the house. Our campus desktops include an 8GB Core i3 NUC (Intel®'s +Next Unit of Computing) and an 8GB Raspberry Pi 4 with SSD storage +running Pop!_OS and Raspberry Pi OS desktops, respectively. They are +authorized to connect to the campus VPN via the following process. + + - The administrator first creates a =wifi= file like the following + (in which the wireless network device is named ~wlan0~). + #+BEGIN_SRC conf + auto wlan0 + iface wlan0 inet dhcp + wpa-ssid "Birchwood Abbey" + wpa-psk "PASSWORD" + #+END_SRC + + - Then the =wifi= file is installed and the network interface + brought up. + #+BEGIN_SRC sh + sudo cp wifi /etc/network/interfaces.d/ + sudo ifup wlan0 + #+END_SRC + + - Next, the administrator generates a pair of WireGuard™ keys. + #+BEGIN_SRC sh + sudo apt install wireguard + wg genkey | sudo tee /etc/wireguard/private-key >/dev/null + sudo cat /etc/wireguard/private-key | wg pubkey >server.pub + #+END_SRC + + - The client's name and public key are then registered via the + ~./abbey client~ command, and the resulting details are copied to + the client. + #+BEGIN_SRC sh + scp sysadm@new-w:server.pub ./ + ./abbey client campus new `cat server.pub` + scp campus.conf sysadm@new-w: + #+END_SRC + + - The details are copied to =/etc/wireguard/wg0.conf= on the client + and the service started. + #+BEGIN_SRC sh + sudo cp campus.conf /etc/wireguard/wg0.conf + sudo systemctl start wg-quick@wg0 + systemctl status wg-quick@wg0 + #+END_SRC + + - The client can then be unplugged from the cloister Ethernet, and + connect to the campus Wi-Fi (if not already). + + - Finally the connection to the VPN is tested and, if OK, is + "enabled" (to start at boot time). + #+BEGIN_SRC sh + ping -c1 core + sudo wg show + sudo systemctl enable wg-quick@wg0 + #+END_SRC -*** Debian Servers - -Wireless Debian servers (without NetworkManager) are connected to the -cloister VPN via the following process. - - - Create a new client certificate and OpenVPN configuration for the - new abbey server. - - Copy the =campus.ovpn= file to the new machine. - - On the new machine: - - Install the ~openvpn-systemd-resolved~ package. - - Copy =campus.ovpn= to =/etc/openvpn/cloister.conf=. - - Start the OpenVPN service. - - Check that the cloister VPN was connected. - - Logout and unplug the cloister Ethernet. - - Test the cloister VPN connection (and private name resolution) - with ~ping -c1 core~. - -And these are the commands: - -#+BEGIN_SRC sh -./abbey client campus new -scp campus.ovpn sysadm@new-w: -ssh sysadm@new-w -sudo apt install openvpn-systemd-resolved -sudo cp campus.ovpn /etc/openvpn/cloister.conf -sudo systemctl start openvpn@cloister -systemctl status openvpn@cloister -ping -c1 core -sudo systemctl enable openvpn@cloister -rm campus.ovpn -logout -rm campus.ovpn -#+END_SRC - -It may be necessary to reboot before the final tests. - -*** Debian Desktops - -Wireless Debian desktops (with NetworkManager) include our 8GB Core i3 -NUC (Intel®'s Next Unit of Computing) and our 8GB Raspberry Pi 4. -They run the Pop!_OS and Raspberry Pi OS desktops respectively. They -are connected to the cloister VPN via the following process. - - - Create a new client certificate and OpenVPN configuration for the - new abbey desktop, a =campus.ovpn= file. - - Create a =wifi= file that looks like this (assuming the wireless - network device is named ~wlan0~). - - : auto wlan0 - : iface wlan0 inet dhcp - : wpa-ssid "Birchwood Abbey" - : wpa-psk "PASSWORD" - - - Copy the =wifi= and =campus.ovpn= files to the new machine. - - On the new machine: - - Install the ~openvpn-systemd-resolved~ package. - - Copy =wifi= to =/etc/network/interfaces.d/=. - - Bring up the Wi-Fi interface. - - Copy =campus.ovpn= to =/etc/openvpn/cloister.conf=. - - Start the OpenVPN service. - - Check that the cloister VPN was connected. - - Logout and unplug the cloister Ethernet. - - Test the cloister VPN connection (and private name resolution) - with ~ping -c1 core~. - -And these are the commands: +*** Private Desktops -#+BEGIN_SRC sh -./abbey client campus new -scp wifi campus.ovpn sysadm@new-w: -ssh sysadm@new-w -sudo apt install openvpn-systemd-resolved -sudo cp wifi /etc/network/interfaces.d/ -sudo ifup wlan0 -sudo cp campus.ovpn /etc/openvpn/cloister.conf -sudo systemctl start openvpn@cloister -systemctl status openvpn@cloister +Member notebooks are private machines not remotely administered by the +abbey. These machines roam, and so are authorized to connect both to +the cloister VPN or to the public VPN. They are authorized to do so +via the following process. + + - The owner of the Debian desktop machine should have already + connected to the campus Wi-Fi using the GUI of NetworkManager. + + - The owner thus begins by generating a pair of WireGuard™ keys on + the client, sending the public key to the administrator. + #+BEGIN_SRC sh + sudo apt install wireguard + wg genkey | sudo tee /etc/wireguard/private-key >/dev/null + sudo cat /etc/wireguard/private-key | wg pubkey >dick.pub + ( echo "Subject: new client named dick" + echo + cat dick.pub ) | sendmail sysadm@small.example.org + #+END_SRC + + - The administrator runs the ~./abbey client~ command and replies + with the generated configurations. + #+BEGIN_SRC sh + ./abbey client debian dick dick `cat dick.pub` + ( echo "Subject: dick now authorized" + echo + cat campus.conf + echo -------- + cat public.conf + ) | sendmail dick + #+END_SRC + + - The owner saves the configuration details in =campus.conf= and + =public.conf=, then installs them and starts the campus VPN + service. + #+BEGIN_SRC sh + sudo cp campus.conf /etc/wireguard/wg0.conf + sudo vp public.conf /etc/wireguard/wg1.conf + sudo systemctl start wg-quick@wg0 + systemctl status wg-quick@wg0 + #+END_SRC + + - Finally the owner checks that the client has successfully + connected to the campus VPN and, if it has, enables the service. + #+BEGIN_SRC sh + systemctl status wg-quick@wg0 + ping -c1 core + sudo systemctl enable wg-quick@wg0 + #+END_SRC + +The owner will want to test the public VPN connection as well by +taking the Debian desktop off the campus Wi-Fi and getting it Internet +access some other way (perhaps tethered to a cell phone). Then the +following commands will switch to the public VPN and test it. + +#+BEGIN_SRC h +sudo systemctl stop wg-quick@wg0 +sudo systemctl start wg-quick@wg1 ping -c1 core -sudo systemctl enable openvpn@cloister -rm wifi campus.ovpn -logout -rm wifi campus.ovpn #+END_SRC -It may be necessary to reboot before the final tests. - -As configured above, the wireless Debian desktops make automatic, -persistent connections to the cloister Wi-Fi and VPN, and so can be -used much like a wired desktop machine. They are typically connected -to a large TV and auto-login to an unprivileged account named ~house~, -i.e. anyone in the house. - -*** Private Desktops - -Member notebooks are private machines not remotely administered by the -abbey. These machines roam, and so are authorized to connect to the -cloister VPN or the public VPN. This is how they are connected to the -VPNs: - - - Create a new client certificate and OpenVPN configurations for the - new abbey desktop, =campus.ovpn= and =public.ovnp= files. - - Copy the =campus.ovpn= and =public.ovpn= files to the new machine. - - On the new machine: - - Install the ~openvpn-systemd-resolved~ and - ~network-manager-openvpn-gnome~ packages. - - Open the desktop Settings > Network > VPN + > Import from - file... and choose =~/campus.ovpn=. - - Open the Routes dialogues for both IPv4 and IPv6 and choose - "Use this connection only for resources on its network.". - - Save the new VPN. - - Do the same with the =~/public.ovpn= file. - - Connect the appropriate VPN and test it (and private name - resolution) with ~ping -c1 core~. - - Expunge (delete /and/ empty the trash) the =~/campus.ovpn= and - =~/public.ovpn= files. - -We assume the desktop is running NetworkManager, which is the case in -all our Debian desktops from Pop!_OS and Ubuntu to Mint and Raspberry -Pi OS. +This leaves ~wg-quick@wg0~ enabled. The campus VPN is re-connected if +the machine reboots. Note that a new member's notebook does not need to be patched to the cloister Ethernet nor connected to the cloister Wi-Fi. It can be -authorized "remotely" simply by copying the =.ovpn= files securely, -e.g. using ~ssh~ to any "known host" on the Internet. +authorized "remotely" simply by copying the =.conf= text files to the +machine by whatever means is available. The members of [[file:Institute/README.org][A Small Institute]] are peers, and enjoy complete, individual privacy. The administrator does /not/ expect to have "root @@ -3740,47 +3747,42 @@ password is included in =Secret/become.yml=. *** Android -Android phones and tablets are connected to the cloister VPN via the -following process. Note that they do not appear in the set of -~campus~ hosts, are not configured by Ansible, and do not appear in -the host inventory. - - - Create a new client certificate and campus/public OpenVPN - configurations for the new abbey Android. - - Copy the =campus.ovpn= and =public.ovpn= files to a USB drive. - - On the Android machine: - - Connect to the cloister Wi-Fi. - - Install [[https://f-droid.org][F-Droid]] and use it to install OpenVPN. - - Connect the USB drive, perhaps with an OTG (On The Go) adapter, - and open the =campus.ovpn= file. The file should be opened with - the OpenVPN app, which will appear to ask for confirmation before - creating the new VPN. - - Open the =public.ovpn= file and create a second VPN. - -The =.ovpn= files must be transferred to the Android via a secure -medium: the ~scp~ command, a USB drive, a cloud download, or perhaps -an encrypted email. In the following commands, the files are copied -to a USB drive labeled ~Transfers~. After insertion into the Android, -its "storage" is viewed with the Files app, which should launch -OpenVPN when a =.ovpn= file is opened. +Android phones and tablets are authorized to connect to the cloister +and public VPNs via the following process. Note that they do not +appear in the set of ~campus~ hosts, are not configured by Ansible, +and do not appear in the host inventory. + + - The owner of the Android device creates a WireGuard™ key pair with + the WireGuard™ for Android app, and texts the public key to the + administrator. + + - The administrator runs the ~./abbey client~ command and replies + with the generated configurations. + #+BEGIN_SRC sh + ./abbey client android dicks-razr dick + ( echo "Subject: dicks-razr now authorized" + echo + cat campus.conf + echo -------- + cat public.conf + ) | sendmail owner + #+END_SRC + + - The owner enters the details of the two WireGuard™ subnets into + the app, creating two tunnels. These are turned on and off + depending on whether the Android is connecting to the campus or + public VPN. -#+BEGIN_SRC sh -./abbey client android dicks-tablet dick -cp campus.ovpn public.ovpn /media/sysadm/Transfers/ -rm campus.ovpn public.ovpn -#+END_SRC ** Create Wireless Domain Name A wireless machine is assigned a Wi-Fi address when it connects to the -cloister Wi-Fi, and a "VPN address" when it connects to Gate's OpenVPN -server. The VPN address can be discovered by running ~ip addr show -dev ovpn~ on the machine, or inspecting =/etc/openvpn/ipp.txt= on -Gate. Once discovered, a private domain name, -e.g. ~new.small.private~, can be associated with the VPN address, e.g -~10.84.138.7~. The administrator adds a line like the following to -=private/db.domain= and increments the serial number at the top of the -file. +cloister Wi-Fi, and a host number when it is registered. Given the +host number (e.g. 7), a private domain name +(e.g. ~new.small.private~) can be associated with that host number on +the cloister VPN subnet, e.g ~10.84.138.7~. The administrator adds a +line like the following to =private/db.domain= and increments the +serial number at the top of the file. #+BEGIN_SRC conf new IN A 10.84.138.7 @@ -3802,11 +3804,11 @@ resolvectl query new.small.private. resolvectl query 10.84.138.7 #+END_SRC -A wireless device with no Ethernet interface and unable to run OpenVPN -gets just a Wi-Fi address. It can be given a private domain name -(e.g. ~new.small.private~) associated with the Wi-Fi address -(e.g. ~192.168.10.225~), but a reverse lookup on a machine connected -to the Wi-Fi may yield a name like ~new.lan~ (provided by the access -point) while elsewhere (e.g. on the cloister Ethernet) the IP address -will not resolve at all. (There is no "reverse mapping" to be added -to =private/db.campus_vpn=.) +A wireless device with no Ethernet interface and unable to run +WireGuard™ gets just a Wi-Fi address. It can be given a private +domain name (e.g. ~thing.small.private~) associated with its Wi-Fi +address (e.g. ~192.168.10.225~), but a reverse lookup on a machine +connected to the Wi-Fi may yield a name like ~thing.lan~ (provided by +the access point) while elsewhere (e.g. on the cloister Ethernet) the +IP address will not resolve at all. (There is no "reverse mapping" to +be added to =private/db.campus_vpn=.)