Live data from Hacker News

Our User-Mode WireGuard Year

fly.io

131–140 of 169 posts

Re: Our User-Mode WireGuard Year

#132

> being able to pop a shell on a running app was table-stakes for the platform. Tangent: that's debatable IMO. In my company's current AWS infrastructure, there's no shell access to either the production containers or the host machines. I did write a script to create an ephemeral container that lets me (and future staff) run a shell inside the production network. And the thing I usually do in that shell is run psql;…

> In my company's current AWS infrastructure, there's no shell access to either the production containers or the host machines. I did write a script to create an ephemeral container that lets me (and future staff) run a shell inside the production network.

I'm a fan of this approach, it is hard improve upon the security of a server that doesn't exist.

I recently setup an AWS serverless (mainly ECS Fargate) stack for a project and took this approach of spinning up an ephemeral EC2 server as part of a "breakglass" runbook for the rare cases where such access is needed.

This, combined with Tailscale userspace networking [0] (so the "breakglass" servers can run on a private subnet and are never exposed to the internet), Pulumi [1] (for managing the lifecycle of the "breakglass" instances) and Yubikey based MFA for short lived credentials [2] (required to spin up the server via Pulumi), I found to work well.

This approach is also useful for ensuring that whenever a "breakglass" server is started it is using the latest AMI version (Pulumi's `aws.ec2.get_ami_output()` is useful for this) and runs the usual security updates on startup. The ssh keypair for the server can also be created (and later destroyed) on the fly so there is no need to manage any long term ssh credentials.

[0] https://tailscale.com/kb/1113/aws-lambda/

[1] https://www.pulumi.com/

[2] https://aws.amazon.com/blogs/security/enhance-programmatic-a...

Re: Our User-Mode WireGuard Year

#133
post #71
post #64

I was using wireguard-go on FreeBSD jail running on top of an APU2C2 board. Torrenting from my laptop caused wireguard-go cpu usage to spike to high loads and 30-50% CPU usage. Loading wireguard-kmod on the host machine plus some devfs rules dropped the CPU load to 0s. Not sure what happened there. The processor seems to score less than an RPi4 on Geekbench.

I use one of these as a firewall (running OPNSense) and they're very nice but the CPU is indeed _slow_. It's plenty good enough for everything the firewall does but booting it up takes minutes and that's saying something for FreeBSD.

Pure FreeBSD boots in less than a minute from the SDCard. Have you tried plugging in a serial cable to check what service is slowing down the boot?

Re: Our User-Mode WireGuard Year

#134
post #123

Earlier quoted context omitted.

What’s even funnier is that if I read it right, it’s ipv6 only, and WSL in Windows doesn’t support IPV6 routing over WireGuard. The kernel is missing some important CONFIG flags when it was compiled to route the packets properly.

It's running its own TCP stack in userspace though so the hosting kernel's routing abilities aren't an issue. I am both impressed and horrified, and I mean that in the best possible way.

> I am both impressed and horrified, and I mean that in the best possible way.

This sentence style sounded familiar in my head. Looking at the username. Oh, of course, that's him!

Re: Our User-Mode WireGuard Year

#135

Back in the day (nearly 30 years ago) people would run a user-mode stack to obtain Internet connectivity via a (dial-up) Unix shell account. The program was "slirp" which was named after SLIP/CSLIP, but then upgraded to support PPP once that became a thing. https://en.wikipedia.org/wiki/Slirp

SLIP was a problem for us when I worked at an ISP in 1995. Cheapsakes would buy our barebones "shell access only" package and then run SLIP on our shell server. We eventually wrote a cron job to kill their processes when we found them. Sneaky ones just renamed the binary.

Man I miss the old internet when things were more playful and that was the extent of harm being done. Not that I condone cheapskates stealing your bandwidth.

Maybe it's just rosy nostalgia.

Re: Our User-Mode WireGuard Year

#137
post #64

I was using wireguard-go on FreeBSD jail running on top of an APU2C2 board. Torrenting from my laptop caused wireguard-go cpu usage to spike to high loads and 30-50% CPU usage. Loading wireguard-kmod on the host machine plus some devfs rules dropped the CPU load to 0s. Not sure what happened there. The processor seems to score less than an RPi4 on Geekbench.

> The processor seems to score less than an RPi4 on Geekbench.

The apu2 is an embedded AMD quad core 1GHz SoC consuming 5W. It is not a powerful system by any means and not surprised rivaled by a >1GHz quad core Arm.

Re: Our User-Mode WireGuard Year

#138
post #32

> The Consul cluster would hold an Entmoot Hah! That one got me. They know their audience :)

Help me out. This threw me for a loop and Google wasn't helpful.

Weird. For me, every Google result for [entmoot] is appropriate and basically gives the answer to your question I would have given. It's a Lord of the Rings reference.

Re: Our User-Mode WireGuard Year

#139
post #64

I was using wireguard-go on FreeBSD jail running on top of an APU2C2 board. Torrenting from my laptop caused wireguard-go cpu usage to spike to high loads and 30-50% CPU usage. Loading wireguard-kmod on the host machine plus some devfs rules dropped the CPU load to 0s. Not sure what happened there. The processor seems to score less than an RPi4 on Geekbench.

> The processor seems to score less than an RPi4 on Geekbench. The apu2 is an embedded AMD quad core 1GHz SoC consuming 5W. It is not a powerful system by any means and not surprised rivaled by a >1GHz quad core Arm.

The AMD Jaguar cores came out in 2013. On the other hand, the Cortex A53 came out in 2012 so it's still a bit embarrassing for AMD. That was before the AMD renaissance, though.

Re: Our User-Mode WireGuard Year

#140

Back in the day (nearly 30 years ago) people would run a user-mode stack to obtain Internet connectivity via a (dial-up) Unix shell account. The program was "slirp" which was named after SLIP/CSLIP, but then upgraded to support PPP once that became a thing. https://en.wikipedia.org/wiki/Slirp

SLIP was a problem for us when I worked at an ISP in 1995. Cheapsakes would buy our barebones "shell access only" package and then run SLIP on our shell server. We eventually wrote a cron job to kill their processes when we found them. Sneaky ones just renamed the binary.

I was that guy. I didn't even know ISPs didn't like it.

I thought that's just how you got into the interwebs without running that obnoxious, buggy faux winsock client.

Post reply on HN