Tailscale maybe? They have a mode where you can configure a site to site links, you could route the docker networks. https://tailscale.com/kb/1019/subnets

You could try using ssh reverse proxy and proxy the port to the vps.

Another way is to setup wireguard on the vps, connect the powerfull machine to it and keep it always connected there. ( This isn’t really a good options since then all traffic is moved thrkught the vps )

There is also grok I think that’s the name.

In general I think ssh reverse port proxy would be a decent way and then you can use a reverse proxy on the vps like nginx or caddy ( you need one that works on the host network )

You can do this with a site-to-site wireguard VPN. You will need to set up the proper routing rules on each termination. On the Internet facing side you will want to do DNAT (modifies destination, keeps source) to redirect the incoming traffic to your non- internet facing side through the tunnel. Then on the non- internet facing you need to set up Routing rules to ensure all traffic headed for public IPs is traversing the tunnel. Then back on the Internet facing side you need to SNAT (modify source, keep destination) the traffic coming through the tunnel headed for the Internet. Hopefully this helps. People saying this goes against standards are not really correct as this is a great application for NAT.

I’ve been looking at setting up something similar and plan on following this guide, and putting Traefik in front of it as a tcp reverse proxy .

https://blog.aiquiral.me/bypass-cgnat

Check if you can find yggdrasil useful

Or just tailscale(headscale), or wireguard

Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I’ve seen in this thread:

8 acronyms in this thread; the most compressed thread commented on today has 15 acronyms.

[Thread #474 for this sub, first seen 2nd Feb 2024, 07:35] [FAQ] [Full list] [Contact] [Source code]

It might help if you described what you’re actually trying to forward … and why the source IP matters.

ZeroTier would be my recommendation personally (it does what tailscale does but it’s been doing it longer and you can use whatever IP ranges you need vs some public IPv4 address space TailScale pools from).

Keeping the source IP intact means you’ll have troubles routing back the traffic through host B.

Basically host A won’t be able to access the internet without going through B, which could not be what you want.

Here’s how it works:

On host A:

• add a /32 route to host B public IP through your local ISP gateway (eg. 192.168.1.1)
• setup a wireguard tunnel between A and B
• host A: 172.17.0.1/30
• host B: 172.17.0.2/30
• add a default route to host B wireguard IP

On host B:

• setup wireguard (same config)
• add PAT rules to the firewall so to DNAT incoming requests on the ports you need to 172.17.0.1
• add an SNAT masquerade rule so all outbound request from 172.17.0.1 are NATed with host B public address.

This should do what you need. However, if I may comment it out, I’d say you should give up on carrying the source IP address down to host A. This setup I described is clunky and can fail in many ways. Also I can see no benefits of doing that besides having “pretty logs” on host A. If you really need good logs, I’d suggest setting up a good reverse proxy on host B and forwarding it’s logs to a collector on host A.

Allow me to cross-post my recent post about my own infrastructure, which has pretty much exactly this established: lemmy.dbzer0.com/post/13552101.

At the homelab (A in your case), I have tailscale running on the host and caddy in docker exposing port 8443 (though the port matters not). The external VPS (B in your case) runs docker-less caddy and tailscale (probably also works with caddy in docker when you run it in network: host mode). Caddy takes in all web requests to my domain and reverse_proxies them to the tailscale hostname of my homelab :8443. It does so with a wildcard entry (*.mydomain.com), and it forwards everything. That way it also handles the wildcard TLS certificate for the domain. The caddy instance on the homelab then checks for specific subdomains or paths, and reverse_proxies the requests again to the targeted docker container.

The original source IP is available to your local docker containers by making use of the X-Forwarded-For header, which caddy handles beautifully. Simply add this block at the top of your Caddyfile on server A:

{
        servers {
                trusted_proxies static 192.168.144.1/24 100.111.166.92
        }
}

replacing the first IP with the gateway in the docker network, and the second IP with the “virtual” IP of server A inside the tailnet. Your containers, if they’re written properly, should automatically read this value and display the real source IP in their logs.

Let me know if you have any further questions.

Preserve the source IP you say, why?

The thing is that if you could (without circumventing the standards) do so then that implies that IP isn’t actually a unique identifier, which is needs to be. It would also mean circumventing whitelists / blacklists would be trivial (it’s not hard by any means but has some specific requirements).

The correct way to do this, even if there might be some hack you could do to get the actual source IP through, is to put the source in a ‘X-Forwarded-For’ header.

As for ready solutions I use NetBird which has open source clients for Windows, Linux and Android that I use without issues and it’s perfectly self-hostable and easy to integrate with your own IDP.

deleted by creator