{"id":662,"date":"2021-07-15T14:54:30","date_gmt":"2021-07-15T09:24:30","guid":{"rendered":"https:\/\/www.lguruprasad.in\/blog\/?p=662"},"modified":"2021-07-15T15:48:05","modified_gmt":"2021-07-15T10:18:05","slug":"updating-a-docker-based-wireguard-server-when-connected-to-it-remotely","status":"publish","type":"post","link":"https:\/\/www.lguruprasad.in\/blog\/2021\/07\/15\/updating-a-docker-based-wireguard-server-when-connected-to-it-remotely\/","title":{"rendered":"Updating a docker-based Wireguard server when connected to it remotely via the same VPN"},"content":{"rendered":"\n

I have a WireGuard<\/a> server running on a Raspberry Pi 4B at my home, exposed to the internet via a static IP address and port forwarding. I set it up using the Linuxserver.io WireGuard docker container<\/a>, which is straightforward to use and manage.<\/p>\n\n\n\n

As I am in a different city now, I had been postponing the updates to the docker container since it is risky to do so remotely. Any issue in the upgrade process could lock me out of my home network till I am physically present in my home.<\/p>\n\n\n\n

As I hate deferring updates, I decided to apply the update remotely. To prepare for that, I logged into the Raspberry Pi via the WireGuard VPN and set up a remote forwarding SSH tunnel<\/a> on a server of mine hosted in the cloud, using a command like,<\/p>\n\n\n\n

$ ssh -R 2222:127.0.0.1:22 username@remote.server.address -N<\/code><\/pre>\n\n\n\n
This command forwards the 2222<\/code> port on the remote server to 127.0.0.1:22<\/code> on the Raspberry Pi, thereby allowing access to it from the remote server. The -N<\/code> flag prevents the execution of any remote command (like say, starting the user’s shell) and is useful for just forwarding ports.<\/p>\n\n\n\n
Then I logged in directly to that server and logged in to the Raspberry Pi using the forwarded port on that server. Now I could destroy and re-create the WireGuard container without the fear of being locked out since I was connected to the device using SSH and not the WireGuard VPN itself. So, I ran the following command.<\/p>\n\n\n\n
$ ssh -p2222 -o UserKnownHostsFile=\/dev\/null -o StrictHostKeyChecking=no -o CheckHostIP=no username@127.0.0.1<\/code><\/pre>\n\n\n\n
The UserKnownHostsfile=\/dev\/null<\/code> option prevents the saving of the remote host’s SSH key in the ~\/.ssh\/known_hosts<\/code> file, the StrictHostKeyChecking=no<\/code> option prevents the checking of the remote host key, and the CheckHostIP=no<\/code> option prevents the checking of the remote host’s IP address. These options disable a lot of important security measures that SSH provides by default \u26a0\ufe0f. But since we are connecting to a known host through a forwarded host, and don’t want to save any local data about it, these options are fine to use.<\/p>\n\n\n\n
This command my remote SSH session, and I was worried that I had missed something important and was locked out. So, I disconnected the SSH session using the escape sequence (<enter>~.<\/code>) and reconnected to my cloud server and then to the Raspberry Pi. It worked and I heaved a sigh of relief and was glad to have pulled this off without any issues. I verified that updated WireGuard container was running without any issues and that I was able to connect to the VPN. \ud83d\ude0c<\/p>\n","protected":false},"excerpt":{"rendered":"
I have a WireGuard server running on a Raspberry Pi 4B at my home, exposed to the internet via a static IP address and port forwarding. I set it up using the Linuxserver.io WireGuard docker container, which is straightforward to use and manage. As I am in a different city now, I had been postponing […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_s2mail":"","activitypub_content_warning":"","activitypub_content_visibility":"","activitypub_max_image_attachments":4,"activitypub_interaction_policy_quote":"anyone","activitypub_status":"","footnotes":""},"categories":[12,14,286],"tags":[314,308,316,315,313],"class_list":["post-662","post","type-post","status-publish","format-standard","hentry","category-foss","category-gnulinux","category-technology","tag-docker","tag-linuxserver-io","tag-remote-port-forwarding","tag-ssh","tag-wireguard"],"_links":{"self":[{"href":"https:\/\/www.lguruprasad.in\/blog\/wp-json\/wp\/v2\/posts\/662","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.lguruprasad.in\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.lguruprasad.in\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.lguruprasad.in\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.lguruprasad.in\/blog\/wp-json\/wp\/v2\/comments?post=662"}],"version-history":[{"count":6,"href":"https:\/\/www.lguruprasad.in\/blog\/wp-json\/wp\/v2\/posts\/662\/revisions"}],"predecessor-version":[{"id":668,"href":"https:\/\/www.lguruprasad.in\/blog\/wp-json\/wp\/v2\/posts\/662\/revisions\/668"}],"wp:attachment":[{"href":"https:\/\/www.lguruprasad.in\/blog\/wp-json\/wp\/v2\/media?parent=662"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.lguruprasad.in\/blog\/wp-json\/wp\/v2\/categories?post=662"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.lguruprasad.in\/blog\/wp-json\/wp\/v2\/tags?post=662"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}