What I want it for is so that I can have services exposed through my domain name, but operated on different internal servers.
What I want it for is so that I can have services exposed through my domain name, but operated on different internal servers.
If you want to NAT inbound connections, you can do it without NATing outbound connections. Essentially: you don't need to NAT, you just need to port forward.
Honestly, I think you should just suck it up and use different hostnames for different services, because running all of your services on one IP is really bad for security since it makes it much easier to enumerate every service you're running -- it only takes scanning 65k ports on one IP to find them all, rather than 65k ports on 2^64 IPs. That's the difference between megabytes and yottabytes of port scan traffic.
If you NATed outbound connections to also come from this IP then things get even worse because every outbound connection any of your machines make would immediately inform the server of the IP needed to make an inbound connection to you. That's a completely unnecessary security sacrifice.
But if you're gonna do it, you can do just that, without trying to run the network on some local IP range too.
Some ask "why bother with IPv6 if I'm still going to do that then?" and generally the two key advantages are the fe80:: address co-exists with the unique public address of each box so you don't need outbound masquerade NAT pools and the fe80:: address space is enormous+interface specific so you don't have to worry about unique internal space or conflicts with other networks. Or, if you have a static IPv6 assignment in a more "proper" hosted deployment instead of a dynamic home deployment, you can of course just do stateless NAT to the public addresses without worrying about IP scarcity.