Best way to tunnel a public IPv4 address

[JC Denton]

So I've been reading this and thinking about how best to implement it for multiple services on the backend that may, or may not, be on the same system. My initial test of this was to have an internal router/firewall VM on the backend, but I'm realizing the rub there is that it'll likely be with double NAT and the backend service (e.g., NGINX or Postfix) would lose the real source address. So my current thought is to have each backend ride a Wireguard tunnel up to the host with the public IPv4 address. Then that box can forward on 25, 80, 443, and others as needed. Does that make seem sense or is there a better / more efficient way to do it?

Thanks in advance

[szatox]

[NeddySeagoon]

JC Denton,

If all the services you want to run are behind the same public IP address or same subnet, then port forwarding to the host (VM) running that service is all you need.
e.g. I have a hetzner bare metal host that does nothing on the bare metal except run KVMs.
I have a mail server and web server in KVMs that are reached by port forwarding of the public IP address.
It happens that all these installs are on the name physical hardware but that's not important. It works equally well if the installs are on different physical hardware too.

There is no tunnelling required. The same is true if I had a /29 subnet. Each service could then have its own IP.

Tunnelling would only be required if you wanted to run services at another site not behind the same IPv4 subnet.
Think VPN. When I use my works VPN, I get an IP address on my employers network tunnelled over the public internet.
From your question, I don't think that's what you want.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

[JC Denton]

I probably should have diagramed it out a bit.

[pingtoo]

I think you are OK with using your VPS as proxy. so I suggest use *socat* as port relay services should be sufficient for your purpose.

[Hu]

I think that socat is not a good choice here. As an application level proxy, it would introduce additional buffering that a NAT/VPN solution would not, and may not properly propagate subtleties of the TCP connection state.

Using a Docker container for a program as simple as socat is massive overkill. socat is available in Portage, has few dependencies, and all those dependencies are likely to be installed on a typical non-embedded system already. Using a Docker image for this means finding a trustworthy image, which seems like more trouble than just emerge --ask --verbose net-misc/socat.

Personally, I would do a single VPN connection between ESX/KVM and VPS provider, and let those two hosts handle NAT/routing, so that the individual VMs can remain unaware that there is anything complicated occurring. Since the ports do not conflict, the VPS system can NAT all 3 ports to the ESX/KVM system, and let KVM determine which VMs receive which ports.

[JC Denton]

[pingtoo]

Ah, here goes the VM vs docker debate, love it

[pingtoo]

[Hu]

[JC Denton]