Live data from Hacker News

WireGuard Bounce Server Setup

gitlab.com

61–70 of 80 posts

Re: WireGuard Bounce Server Setup

#61
post #13

This works if both sides has wireguard installed and are in the network, but is there a way to got this to work for any connections from the internet? eg. your VPS has ip 1.1.1.1, you want any traffic that goes to 1.1.1.1 to go to the wireguard interface on your PC, and any traffic set from the wireguard interface on your PC exits through 1.1.1.1. Bonus points if set it up in such so that the interface address on you…

That was kinda the article I was expecting to read, so I was very confused when it didn't actually go there.

Re: WireGuard Bounce Server Setup

#62
post #17
post #13

This works if both sides has wireguard installed and are in the network, but is there a way to got this to work for any connections from the internet? eg. your VPS has ip 1.1.1.1, you want any traffic that goes to 1.1.1.1 to go to the wireguard interface on your PC, and any traffic set from the wireguard interface on your PC exits through 1.1.1.1. Bonus points if set it up in such so that the interface address on you…

Yes this is relatively straightforward to accomplish via iptables pre&postrouting rules. I think the key insight is to realize that you're basically asking for NAT with DMZ: Internet -> [eth0] WG BOX [wg0] -> [wg0] HOME SERVER analogous to: Internet -> [eth0] ROUTER [eth1] -> [eth0] HOME SERVER

You probably want to have two (or more) interfaces (eni in aws lingo) on the wg server so that you dedicate one for this tunneled traffic.

Also you probably want to setup some sort of NAT instead of just routing packets directly.

Re: WireGuard Bounce Server Setup

#63

Earlier quoted context omitted.

Looks like the Business Source License [0]. Which does not qualify under the Open Source Definition [1], but they claim it meets "most" of the OSI criteria. 0: https://github.com/zerotier/ZeroTierOne/blob/master/LICENSE.... 1: https://mariadb.com/bsl-faq-adopting/#osl

> ... but they claim it meets "most" of the OSI criteria. As Frank Robinson [0] once said: > "[...] Close only counts in horseshoes [1] and hand grenades." -- [0]: https://en.wikipedia.org/wiki/Frank_Robinson [1]: https://en.wikipedia.org/wiki/Horseshoes (for the uninitiated)

Then again, "Good enough is good enough"

http://www.basicinstructions.net/basic-instructions/2019/8/1...

Re: WireGuard Bounce Server Setup

#64
post #56

> NOTE: Systemd has a nasty habit of delaying logins for 25 - 100 seconds while it waits for some service you never asked for to time out and fail, before it lets you have a prompt. If you experience this when logging in to a host via SSH, the delays are almost certainly due to either missing or non-functional forward/reverse DNS (the SSH server will perform these lookups when connections are received). You've got at…

Thank you. I haven't seen any apparent DNS problems; I fixed it, on a Debian host, by deleting the gnupg packages; probably deleting just gpgconf would have sufficed. That said, the IP addresses I used really would not show up in a DNS lookup. If I see it again, I will look for DNS lookup attempts. Dec 15 22:23:14 ip-99-99-99-100 sshd[1995]: pam_unix(sshd:session): session opened for user admin by (uid=0) Dec 15 22:2…

Could your issue be related to this SF post?

https://serverfault.com/questions/954844/chroot-gpg-agent-an...

Re: WireGuard Bounce Server Setup

#65
post #56

> NOTE: Systemd has a nasty habit of delaying logins for 25 - 100 seconds while it waits for some service you never asked for to time out and fail, before it lets you have a prompt. If you experience this when logging in to a host via SSH, the delays are almost certainly due to either missing or non-functional forward/reverse DNS (the SSH server will perform these lookups when connections are received). You've got at…

Thank you. I haven't seen any apparent DNS problems; I fixed it, on a Debian host, by deleting the gnupg packages; probably deleting just gpgconf would have sufficed. That said, the IP addresses I used really would not show up in a DNS lookup. If I see it again, I will look for DNS lookup attempts. Dec 15 22:23:14 ip-99-99-99-100 sshd[1995]: pam_unix(sshd:session): session opened for user admin by (uid=0) Dec 15 22:2…

The user manager directs things like user services. That can be things like starting pulseaudio on a desktop machine, for example, or gnupg on general systems so the user has a gnupg daemon available in their own UID space. This alleviates putting them into .rc or .profile files and making them hard to manage in case they fail.

In this case, GNUPG is trying and failing to start (likely misconfigured), this in turn means system failed to start the likely only user service configured, hence it fails the session setup. The session is still created (managed via logind) to provide a shell and PAM environment.

On a non-systemd this stuff would be managed by other scripts and tools that do essentially the same thing (minus being able to start user services).

It also creates a slice for the session, which enables systemd to kill all processes created in a session when the session ends (logout), minus some exceptions that can manage themselves (like Tmux). Helps against people who forget that they backgrounded and nohup'd a script (which isn't a good way to do things that are supposed to keep running).

If you want to see what services are available in your user session run 'systemctl --user'.

Re: WireGuard Bounce Server Setup

#66
post #65
post #56

Earlier quoted context omitted.

Thank you. I haven't seen any apparent DNS problems; I fixed it, on a Debian host, by deleting the gnupg packages; probably deleting just gpgconf would have sufficed. That said, the IP addresses I used really would not show up in a DNS lookup. If I see it again, I will look for DNS lookup attempts. Dec 15 22:23:14 ip-99-99-99-100 sshd[1995]: pam_unix(sshd:session): session opened for user admin by (uid=0) Dec 15 22:2…

The user manager directs things like user services. That can be things like starting pulseaudio on a desktop machine, for example, or gnupg on general systems so the user has a gnupg daemon available in their own UID space. This alleviates putting them into .rc or .profile files and making them hard to manage in case they fail. In this case, GNUPG is trying and failing to start (likely misconfigured), this in turn me…

Thank you.

In this case, gnupg was, both for that user and for that host, wholly unconfigured -- evidently it was just roped in by some package dependency. So, trying to run something that depended on the system or user having gnupg configured correctly (or at all) was wholly wrong.

Systemd killing my nohups does not seem like doing me a favor. If I had wanted the process killed when my connection dropped, I would not have nohup'd it. (Later in the article, I use nohup as intended.) How do I turn that off, without breaking other things? Or, failing that, what is the right way to get that behavior, without nohup?

And, what controls which services the session manager will try to run on behalf of a user who has not tried to customize anything? It would probably have been better to turn pushy gpg-agent off, in some sysyem-wide way, than to have entirely deleted it.

Re: WireGuard Bounce Server Setup

#67
post #60

> To connect between NATted hosts, you need control of a host that is not Um, no? https://github.com/samyk/pwnat

Thank you for this. I will try it.

I tried it... SEGFAULT in the client: Null pointer to a port-number arg. I supplied all of the optional arguments...

Re: WireGuard Bounce Server Setup

#68
>because Amazon techs and motivated hackers can peek at files you put there (yes, really, all of them! including your secret keys)

What did the author mean by this? I can understand amazon employees having the ability to peek at private data but what about "hackers"? is he referring to the fact that lightsail is containerized and not running on VMs?(just a guess)

Re: WireGuard Bounce Server Setup

#69
post #66
post #65

Earlier quoted context omitted.

The user manager directs things like user services. That can be things like starting pulseaudio on a desktop machine, for example, or gnupg on general systems so the user has a gnupg daemon available in their own UID space. This alleviates putting them into .rc or .profile files and making them hard to manage in case they fail. In this case, GNUPG is trying and failing to start (likely misconfigured), this in turn me…

Thank you. In this case, gnupg was, both for that user and for that host, wholly unconfigured -- evidently it was just roped in by some package dependency. So, trying to run something that depended on the system or user having gnupg configured correctly (or at all) was wholly wrong. Systemd killing my nohup s does not seem like doing me a favor. If I had wanted the process killed when my connection dropped, I would n…

Systemd doesn't kill nohups as long as the session exists. Hence your nohup works if you opened tmux or a graphical terminal and close it. But logging out terminates all processes belonging to that session that don't properly disassociate from the session.

You can run 'loginctl enable-linger' to disable this behaviour or set 'KillUserProcesses=no' in /etc/systemd/logind.conf

You can also use 'systemd-run --scope --user /usr/bin/yourscript.sh', this will explicitly keep the process running even when the session closes, even if lingering processes are killed. It'll also keep track of all processes created by that script, so if the script exits, it'll kill all processes that are left over and cleanup. It also meshes with other parts of systemd so `systemd-run --scope --user --on-calendar=daily /usr/bin/script' will run the script daily until you tell it to stop or the machine restarts (since it's not configured on disk). You can even keep the service if the script dies with '--remain-after-exit', which tells systemd to keep the service alive as long as processes for it exist or you terminate it manually.

If whatever your running in the background needs forking, you can create a service and start it under your user, that properly keeps it up and running.

Systemd understands a nohup as "don't terminate the process when the terminal closes", not as "don't terminate the process when the session ends" which can be different events depending on the setup (ie, graphical terminal or tmux).

The session manager will start any user services that are activated, your distro usually configures that in '/usr/lib/systemd/user'. Manually activated units are in '/etc/systemd/user' if they are system-wide and user config is in '$XDG_CONFIG_HOME/systemd/user' or '$HOME/.local/share/systemd/user'.

To turn it off you can deactivate it via 'systemctl --user disable gpg-agent' for the current user or 'systemctl --global disable gpg-agent' for all users. If it activates via socket activation you can either disable the socket 'systemctl --global disable gpg-agent.socket' or mask the service 'systemctl --global mask gpg-agent'. Masking the service prevents it from being started for any reason.

Re: WireGuard Bounce Server Setup

#70
post #27

Doesn't Ubuntu 20.04 have a kernel with Wireguard built in? You shouldn't need to use DKMS.

Even on my 20.04 box, I seem to have wireguard-dkms auto-installed in response to "apt install wireguard". Perhaps they are doing this to allow for faster wireguard module updates? Or perhaps this is just a bug. https://launchpad.net/bugs/1890201 https://launchpad.net/ubuntu/+source/wireguard/1.0.20200513-...

Using “apt install --no-recommends wireguard-tools” should do what you’re looking for.
Post reply on HN