在我开始之前。我的网络知识非常有限，所以希望我能清楚地解释我的情况。
故事
我们目前在 AWS 中有一个非常基本的站点实现。我们遵循最佳实践，将所有私有资源（数据库、缓存等）放置在我们的私有子网中，并允许公共子网实例使用 ec2 安全组访问这些资源。
但是我们有以下要求：
- 需要从我们的开发环境访问私有子网中的私有资源（例如数据库）
- 访问我们网站的管理页面。目前，这主要是通过使用应用程序中的环境变量来保护的，该变量包含可以访问管理网站的 IP 地址的允许列表。随着时间的推移，我们的想法是将管理部分与客户端网站分开，并在仅可通过 VPN 访问的单独设置中进行配置
因此，在研究了这个问题之后，我决定尝试一下 Wireguard。它似乎是这个领域的新手，有很多承诺围绕性能等
最终的胜利是设置分割隧道，只通过 VPN 路由所需的流量，这样我们就不会为数据传输等产生 AWS 费用。
玩了几个小时后我发现了以下内容文章为内部资源设置分割 VPN，看到它按预期工作，我非常兴奋（还四处搜索，找到了一些关于 IP 表的优秀资源）然而，当我尝试使用 VPN 访问管理面板时，我的问题就开始了。我为 wireguard 实例分配了一个公共 IP，将 IP 添加到站点上的白名单环境数组中，以为这样就行了。然而，我很快发现我无法路由域名，因为不支持。毕竟，它说的是允许的 IP，而不是允许的域
之后，我尝试使用设置允许所有流量通过客户端界面AllowedIPs = 0.0.0.0/0 ::/0，但发现没有任何效果。然后我添加了一个 DNS 条目以指向 wireguard 服务器 DNS ( 1.1.1.1)，然后我就可以再次浏览了。然后我继续尝试连接到管理站点（wireguard 服务器 IP 已添加到站点的白名单配置中），然后我可以不是访问它。但是，如果我从 wireguard 服务器实例 curl 管理员 url，我就可以访问它。
查看服务器上的日志后，我发现我正在使用 ISP 的公共 IP，这就是我无法访问管理页面的原因。如果我route get从我的机器对我的应用程序 IP 执行 a，我可以看到它确实在使用我机器上的隧道接口。
问题
- 如何让我的机器在连接时“使用”Wireguard实例的IP地址
- 如何解析域以使用分割隧道连接到应用程序。
理想情况下，这些问题不需要在对等机器上进行大量设置。这应该是对等主机上的简单配置上传，因为我们无法控制本地机器或它们使用的操作系统（有些使用 mac，有些使用 windows，等等）
一些配置
这是我在尝试允许所有人通过 VPN 之前的配置
服务器 wg0.conf 文件
[Interface]
## My VPN server private IP address ##
Address = 10.0.10.2/32
# IP forwarding
PreUp = sysctl -w net.ipv4.ip_forward=1
# IP masquerading
PreUp = iptables -t mangle -A PREROUTING -i wg0 -j MARK --set-mark 0x30
PreUp = iptables -t nat -A POSTROUTING ! -o wg0 -m mark --mark 0x30 -j MASQUERADE
PostDown = iptables -t mangle -D PREROUTING -i wg0 -j MARK --set-mark 0x30
PostDown = iptables -t nat -D POSTROUTING ! -o wg0 -m mark --mark 0x30 -j MASQUERADE
# firewall local host from wg peers
PreUp = iptables -A INPUT -i wg0 -m state --state ESTABLISHED,RELATED -j ACCEPT
PreUp = iptables -A INPUT -i wg0 -j REJECT
PostDown = iptables -D INPUT -i wg0 -m state --state ESTABLISHED,RELATED -j ACCEPT
PostDown = iptables -D INPUT -i wg0 -j REJECT
# firewall wg peers from other hosts
PreUp = iptables -A FORWARD -o wg0 -m state --state ESTABLISHED,RELATED -j ACCEPT
PreUp = iptables -A FORWARD -o wg0 -j REJECT
PostDown = iptables -D FORWARD -o wg0 -m state --state ESTABLISHED,RELATED -j ACCEPT
PostDown = iptables -D FORWARD -o wg0 -j REJECT
## My VPN server port ##
ListenPort = 51820
## VPN server's private key ##
PrivateKey = SomeServerPrivateKey
# Peer 1
[Peer]
PublicKey = SomePeerPublicKey
AllowedIPs = 10.0.10.1/32
对等配置文件（我的本地）
[Interface]
PrivateKey = SomePeerPrivateKey
Address = 10.0.10.1/32
#DNS = 1.1.1.1, 8.8.8.8
[Peer]
PublicKey = SomeServerPublicKey
AllowedIPs = 10.0.1.0/24
答案1
- 你的 iptables
MASQUERADE规则意味着你的客户端在通过 WireGuard 服务器连接时将使用其 IP 地址 - 将要通过 WireGuard 连接的每个远程主机的 IP 地址（或地址块）放入客户端的
AllowedIPs设置中
假设您要连接的管理站点的 IP 地址是10.1.2.3。添加10.1.2.3到客户端的AllowedIPs设置中：
AllowedIPs = 10.0.1.0/24, 10.1.2.3
现在，当您尝试访问10.0.1.0/24块中的任何内容或10.1.2.3从客户端连接到管理站点（）时，您的客户端将通过 WireGuard 发送该流量。
您在 WireGuard 服务器上设置的 iptables 规则将标记从其 WireGuard 接口进入服务器的所有数据包，并在这些数据包离开时重写它们的源地址（只要它们不通过 WireGuard 接口离开）以使用服务器自己的 IP 地址（具体而言，是它们离开的接口的 IP 地址）：
iptables -t mangle -A PREROUTING -i wg0 -j MARK --set-mark 0x30
iptables -t nat -A POSTROUTING ! -o wg0 -m mark --mark 0x30 -j MASQUERADE
您可以通过在 WireGuard 服务器上运行以下命令来验证您的客户端是否正在使用 WireGuard 服务器的 IP 地址连接到您的管理站点：
sudo tcpdump -niany 'host 10.1.2.3'
当你尝试从客户端连接到管理站点时，你应该会看到类似以下来自 tcpdump 的输出，表明当连接转发到管理站点 () 时，客户端的 WireGuard IP 地址 ( 10.0.10.1) 已被重写为使用服务器物理以太网接口的 IP 地址（10.0.1.99在此示例中）10.1.2.3：
12:34:56.123456 IP 10.0.10.1.44444 > 10.1.2.3.80: Flags [S], seq ...
12:34:56.123457 IP 10.0.1.99.44444 > 10.1.2.3.80: Flags [S], seq ...
12:34:56.123458 IP 10.1.2.3.80 > 10.0.1.99.44444: Flags [S.], seq ...
12:34:56.123459 IP 10.1.2.3.80 > 10.0.10.1.44444: Flags [S.], seq ...
12:34:56.123460 IP 10.0.10.1.44444 > 10.1.2.3.80: Flags [.], ack ...
12:34:56.123461 IP 10.0.1.99.44444 > 10.1.2.3.80: Flags [.], ack ...
如果 WireGuard 服务器通过 Internet 连接到管理站点，并且你已203.0.113.123为 WireGuard 服务器分配了一个公共 IP 地址（例如），则 AWS 将使用该公共 IP 将流量从 WireGuard 服务器重写到 Internet；因此从管理站点的角度来看，该连接似乎来自该公共 IP（203.0.113.123）。
但是，如果管理站点也托管在 AWS 中，并且您使用管理站点的私有 IP 地址连接到它，则该连接将显示为来自 WireGuard 服务器的私有 IP 地址 ( 10.0.1.99)。