this post was submitted on 27 Mar 2024
34 points (88.6% liked)

Selfhosted

40438 readers
589 users here now

A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.

Rules:

  1. Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.

  2. No spam posting.

  3. Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.

  4. Don't duplicate the full text of your blog or github here. Just post the link for folks to click.

  5. Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).

  6. No trolling.

Resources:

Any issues on the community? Report it using the report flag.

Questions? DM the mods!

founded 2 years ago
MODERATORS
 

I want to move away from Cloudflare tunnels, so I rented a cheap VPS from Hetzner and tried to follow this guide. Unfortunately, the WireGuard setup didn't work. I'm trying to forward all traffic from the VPS to my homeserver and vice versa. Are there any other ways to solve this issue?

VPS Info:

OS: Debian 12

Architecture: ARM64 / aarch64

RAM: 4 GB

Traffic: 20 TB

you are viewing a single comment's thread
view the rest of the comments
[–] AlexPewMaster 1 points 8 months ago (1 children)

How would that kind of a setup look like?

[–] [email protected] 4 points 8 months ago* (last edited 8 months ago) (1 children)

Variant 1:

  • SSH tunnel established outgoing from home server to VPS_PUBLIC_IP:22, which makes an encrypted tunnel that "forwards" traffic from VPS_PUBLIC_IP:443 to HOME_LOCALHOST:443.
  • Full reverse proxy listening on HOME_LOCALHOST:443 and does everything (TLS termination, host routing, 3rd-party auth etc.)
  • Instead of running home proxy on the host you can ofc run it inside a container, just need to also run the ssh tunnel from inside that container.

Pro: very secure, VPS doesn't store any sensitive data (no TLS certificates, only a SSH public key) and the client connections pass through the VPS double-encrypted (TLS between client browser and home proxy, wrapped inside SSH).

Con: you don't get the client's IP. When the home apps receive the connections they appear to originate at the home end of the SSH tunnel, which is a private interface on the home server.

Variant 2 (in case you need client IPs):

  • SSH tunnel established same way as variant 1 but listens on VPS_LOCALHOST:PORT.
  • Simple reverse proxy on VPS_PUBLIC_IP:443. It terminates the TLS connections (decrypts them) using each domain's certificate. Adds the client IP to the HTTP headers. Forwards the connection into VPS_LOCALHOST:PORT which sends it to the home proxy.
  • Full reverse proxy at home set up same way as variant 1 except you can listen to 80 and not do any TLS termination because it's redundant at this point – the connection has already been decrypted and will arrive wrapped inside SSH.

Pro: by decrypting the TLS connection the simple proxy can add the client's IP to the HTTP headers, making it available to logs and apps at home.

Con: the VPS needs to store the TLS certificates for all the domains you're serving, you need to copy fresh certificates to the VPS whenever they expire, and the unencrypted connections are available on the VPS between the exit from TLS and the entry into the SSH tunnel.

Edit: Variant 3? proxy protocol

I've never tried this but apparently there's a so called proxy_protocol that can be used to attach information such as client IP to TLS connections without terminating them.

You would still need a VPS proxy and a home proxy like in variant 2, and they both need to support proxy protocol.

The frontend (VPS) proxy would forward connections in stream mode and use proxy protocol to add client info on the outside.

The backend (home) proxy would terminate TLS and do host routing etc. but also it can unpack client IP from the proxy protocol and place it in HTTP headers for apps and logs.

Pro: It's basically the best of both variant 1 and 2. TLS connections don't need to be terminated half-way, but you still get client IPs.

Please note that it's up to you to weigh the pros and cons of having the client IPs or not. In some circumstances it may actually be a feature to not log client IPs, for example If you expect you might be compelled to provide logs to someone.

[–] AlexPewMaster 1 points 8 months ago (1 children)

Very interesting... How do I get started?

[–] [email protected] 1 points 8 months ago (1 children)

The SSH tunnel is just one command, but you may want to use autossh to restart it if it fails.

If you choose variant 2 you will need to configure a pass-through reverse proxy on the VPS that does TLS termination (uses correct certificates for each domain on 443). Look into nginx, caddy, traefik or haproxy.

For the full home proxy you will once again need a proxy but you'll additionally need to do host routing to direct each (sub)domain to the correct app. You'll probably want to use the same proxy as above to avoid learning two different proxies.

I would recommend either caddy (both) or nginx (vps) + nginx proxy manager (home) if you're a beginner.

[–] AlexPewMaster 1 points 8 months ago (1 children)

How do I make the SSH tunnel forward traffic? It can't be as easy as just running ssh user@SERVER_IP in the terminal.

(I only need variant 1 btw)

[–] [email protected] 1 points 8 months ago* (last edited 8 months ago) (1 children)

You also add the -R parameter:

ssh -R SERVER_IP:443:HOME_PROXY_IP:HOME_PROXY_PORT user@SERVER_IP

https://linuxize.com/post/how-to-setup-ssh-tunneling/ (you want the "remote port forwarding"). ssh -R, -L and -D options are magical, more people should learn about them.

You may also need to open access to port 443 on the VPS. How you do that depends on the VPS service, check their documentation.

[–] AlexPewMaster 1 points 8 months ago (1 children)

Hi, whenever I try to enter the ports 80 and 443 at the beginning of the -R parameter, I get this error: Warning: remote port forwarding failed for listen port 80. How do I fix this?

[–] [email protected] 1 points 8 months ago

Ah yes. Ports below 1024 are normally privileged and only superuser can use them (and the account you're using to ssh in is not and should not be root).

This link has several possible solutions: https://unix.stackexchange.com/questions/10735/allowing-a-regular-user-to-listen-to-a-port-below-1024