I have two machines running docker. A (powerful) and B (tiny vps).
All my services are hosted at home on machine A.
All dns records point to A.
I want to point them to B and implement split horizon dns in my local network to still directly access A. Ideally A is no longer reachable from outside without going over B.
How can I forward requests on machine B to A over a tunnel like wireguard without loosing the source ip addresses?
I tried to get this working by creating two wireguard containers.
I think I only need iptable rules on the WG container A but I am not sure.
I am a bit confused about the iptable rules needed to get wireguard to properly forward the request through the tunnel.
What are your solutions for such a setup?
Is there a better way to do this?
I would also be glad for some keywords/existing solutions.
Additional info:
Ideally I would like to not leave docker.
Split horizon dns is no problem.
I have a static ipv6 and ipv4 on both machines.
I also have spare ipv6 subnets that I can use for intermediate routing.
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.
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !selfhosted@lemmy.world
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:
Be civil: we’re here to support and learn from one another. Insults won’t be tolerated. Flame wars are frowned upon.
No spam posting.
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.
Don’t duplicate the full text of your blog or github here. Just post the link for folks to click.
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
No trolling.
Resources:
selfh.st Newsletter and index of selfhosted software and apps
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:
On host B:
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.