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.
- I would like to avoid cloudflare.
You must log in or # to comment.
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.
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 .
Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I’ve seen in this thread:
Fewer Letters More Letters CGNAT Carrier-Grade NAT Git Popular version control system, primarily for code HTTP Hypertext Transfer Protocol, the Web IP Internet Protocol NAT Network Address Translation SSL Secure Sockets Layer, for transparent encryption TLS Transport Layer Security, supersedes SSL VPN Virtual Private Network VPS Virtual Private Server (opposed to shared hosting) nginx Popular HTTP server
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]
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.
Can you elaborate on the IP would not be unique part?
If you can fool the Internet that traffic coming from the VPS has the source IP of your home machine what stops you from assuming another IP to bypass an IP whitelist?
Also if you expect return communication, that would go to your VPS which has faked the IP of your home machine. That technique would be very powerful to create man in the middle attacks, i.e. intercepting traffic intended for someone else and manipulating it without leaving a trace.
IP, by virtue of how the protocol works, needs to be a unique identifier for a machine. There are techniques, like CGNAT, that allows multiple machines to share an IP, but really it works (in simplified terms) like a proxy and thus breaks the direct connection and limits you to specific ports. It’s also added on top of the IP protocol and requires specific things and either way it’s the endpoint, in your case the VPS, which will be the presenting IP.
