My Scribbles

answer:

1. Edit the file /etc/systemd/system/multi-user.target.wants/tailscaled.service,
2. Add the line "LogLevelMax=3" in the [Service] section.
3. systemctl daemon-reload
4. systemctl restart tailscaled

Reference

In short,

sudo vim /etc/systemd/logind.conf

Find and uncomment the following lines, and change the values

HandleLidSwitch=lock
HandleLidSwitchExternalPower=lock
HandleLidSwitchDocked=ignore

Save and exit, and 

sudo systemctl restart systemd-logind

You might be surprised why I am using MSYS2 so much these days. In short, my new job doesn't allow me to use Linux at work. I cannot bear the CMD.EXE and PWSH.EXE, they might be great tools for someone else, but definitely not for me.

1. If you visit a shared folder like /c/vagrant, you will get the infamous Too many levels of symbolic links error message. Fortunately, we have a solution: add a new user Environment variable MSYS=nonativeinnerlinks. I assume you know how to add a user environment to the windows system. If it doesn't take effect, save your current work and reboot. I didn't reboot my Windows 11 VM, but I did have restarted the Windows terminal application to ensure the new MSYS2 terminal will work with the links!
2. If you prefer using Git for windows in MSYS2 but don't want to install GitBash because GitBash is also built on MSYS2, Install Git for windows inside MSYS2 will help you! BTW, git_bash_for_windows_is_based_on_msys2_why_not is another very good reference for this topic. I actually got the previous link from the latter article.
3. Change the home directory to /c/Users/your-name. If you copy from the following, don't forget to change david.wei to your Windows username.

   $ cat /etc/nsswitch.conf
   # Begin /etc/nsswitch.conf
   passwd: db
   group: db
   db_enum: cache builtin
   #db_home: cygwin desc
   db_home: env windows /c/Users/david.wei
   db_shell: cygwin desc
   db_gecos: cygwin desc
   # End /etc/nsswitch.conf
   

4. If you run cmd.exe in a msys2 terminal, that %PATH% environment will inherit from the PATH environment in the current bash session.
5. put export MSYS="winsymlinks:lnk" into your .bashrc to get a similar behaviour when you do ln -s Reference

tl;dr

The root cause is that the default route was not set to the router's IP address.

My journey to resolve the issue:

The issue is that port mapping can work with my raspberry pi while it couldn't work with a virtual machine in the same LAN. I firstly think it must be a bug from the router. I upgrade the router to its latest firmware, but it still doesn't work. I google back and forth, I learned much from all kinds of answers, but they were just not my case. I almost decided to give up.

Then I found the following answer from E. van Putten, he answered this question and nobody gave his answer a "Like"!!!

In case you landed on this page because you can't reach a server running inside a Xen Guest from the internet (but can connect locally), then read on...

1. The fritzbox can get confused by different OS'es appearing from the same MAC-address etc. (could happen while you are setting up / experimenting with Xen)
2. The fritzbox has seemingly duplicate entries in the list, but with different settings, you need to delete the portmap from the incorrect entry, cleanup the list and reapply the portmap settings.
3. It might be that your guest OS has no default gateway IP-address set. You'd expect a default gateway set to the local IP-address of your fritzbox. The symptoms of a missing default gateway is that your LAN PCs can access the server running inside the guest just fine, but external users from the internet cannot connect.

He gave three possible causes, and my case is the third one! here's my solution

opts = {
    :name => "yt-gateway",
    :ip => "192.168.178.173",
    :mem => "1024",
    :cpu => "1"
}
Vagrant.configure("2") do |config|
  config.vm.box = "bento/ubuntu-20.04"
  config.vm.hostname = opts[:name]
  config.vm.network :public_network, ip: opts[:ip], bridge: "eno1"
  config.vm.provision "shell", run: "always", inline: "route add default gw 192.168.178.1 || true"
  config.vm.provider "virtualbox" do |v|
    v.name = opts[:name]
    v.customize ["modifyvm", :id, "--memory", opts[:mem]]
    v.customize ["modifyvm", :id, "--cpus", opts[:cpu]]
    v.customize ["modifyvm", :id, "--name", opts[:name]]
  end
end

I love you E. van!

PiVPN should be easy to setup at any debian/ubuntu family distribution. However, my case wasn't.

1. The first issue I met is Can't call method "set" on an undefined value at /usr/share/perl5/Debconf/FrontEnd.pm line 126, line 5., and I found a useful anwser from https://github.com/pivpn/pivpn/issues/718, which is

apt-get install --reinstall debconf

it worked! though I don't know the root cause.

2. The second issue is rather weird, it simple stuck after showing ::: Backing up the openvpn folder... message. What's wrong with that on earth? Unfortunately, I couldn't find anything useful from google/stackoverflow.... I have to find out the root cause by myself.

ps -ef command shows there is a wget -qO- https://github.com/OpenVPN/easy-rsa/releases/download/v3.0.7/EasyRSA-3.0.7.tgz process running. Why it is running so long and looks never end? I copied the wget command and run it manually. aha, I found the cause!

wget https://github.com/OpenVPN/easy-rsa/releases/download/v3.0.7/EasyRSA-3.0.7.tgz
--2021-10-10 23:01:15--  https://github.com/OpenVPN/easy-rsa/releases/download/v3.0.7/EasyRSA-3.0.7.tgz
Resolving github.com (github.com)... 52.64.108.95
Connecting to github.com (github.com)|52.64.108.95|:443... connected.
HTTP request sent, awaiting response... 302 Found
Location: https://github-releases.githubusercontent.com/4519663/0fa24e00-72ba-11ea-9afe-6e5829eec4a4?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAIWNJYAX4CSVEH53A%2F20211010%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20211010T230115Z&X-Amz-Expires=300&X-Amz-Signature=1acb19fd17e7cb4f74c5695b194dc2040b13d9649da64b191a53591758471718&X-Amz-SignedHeaders=host&actor_id=0&key_id=0&repo_id=4519663&response-content-disposition=attachment%3B%20filename%3DEasyRSA-3.0.7.tgz&response-content-type=application%2Foctet-stream [following]
--2021-10-10 23:01:15--  https://github-releases.githubusercontent.com/4519663/0fa24e00-72ba-11ea-9afe-6e5829eec4a4?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAIWNJYAX4CSVEH53A%2F20211010%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20211010T230115Z&X-Amz-Expires=300&X-Amz-Signature=1acb19fd17e7cb4f74c5695b194dc2040b13d9649da64b191a53591758471718&X-Amz-SignedHeaders=host&actor_id=0&key_id=0&repo_id=4519663&response-content-disposition=attachment%3B%20filename%3DEasyRSA-3.0.7.tgz&response-content-type=application%2Foctet-stream
Resolving github-releases.githubusercontent.com (github-releases.githubusercontent.com)... 2606:50c0:8002::154, 2606:50c0:8003::154, 2606:50c0:8001::154, ...
Connecting to github-releases.githubusercontent.com (github-releases.githubusercontent.com)|2606:50c0:8002::154|:443... ^C

You could see, all of the IP addresses wget used are in IPV6 format while my network doesn't support IPV6 . So it is easy to fix. According to this question from stackoverflow, I added the following line at the end of /etc/wgetrc and the issue has gone!

inet4_only = on