Wireguard 配置文件中的 Endpoint 和 AllowedIPs 字段有啥区别？

Posted 2023-02-15

【中文标题】Wireguard 配置文件中的 Endpoint 和 AllowedIPs 字段有啥区别？

【英文标题】：What is the difference between Endpoint and AllowedIPs fields in Wireguard config file?Wireguard 配置文件中的 Endpoint 和 AllowedIPs 字段有什么区别？

【发布时间】：2021-04-03 06:50:18

【问题描述】：

我对 Wireguard 的理解是服务端和客户端的接口（虽然看起来听不清？）各自有自己的.conf 文件。例如考虑以下.conf 文件。

[Interface]
PrivateKey = some_key_1
Address = 10.193.130.174/16


[Peer]
PublicKey = some_key_2
PresharedKey = some_key_3
AllowedIPs = 10.129.130.1/32
Endpoint = 54.91.5.130:1952

如何判断这是客户端还是服务器 .conf 文件（如果可能的话）？这可能是一个非常简单的问题，但是[Peer] 的Endpoint 和AllowedIPs 字段之间有什么区别？我从CryptoKey Routing 推断，一旦interface 接收到一个数据包，它就会使用interface 私钥对其进行解密，并根据所有peers 中的AllowedIPs 检查发件人IP，如果凭据实际上与peer 它接受它。另一方面，如果interface 想要发送一个数据包，它会使用peer 公钥对其进行加密，但它会将其发送到Endpoint 还是AllowedIPs 之一？

编辑 1： 我确实使用了 man wg，而 Endpoint 的定义对我来说仍然很模糊。不过，AllowedIPs 字段似乎更容易掌握。

编辑 2： 经过进一步研究，我认为AllowedIPs 字段指定了对等方可用于接收流量或向其发送流量的 IP 地址。如果有人能确认或更正这一点，我将不胜感激。

【参考方案1】：

是的，每个接口都有自己的配置文件。 WireGuard 没有内置的“客户端”或“服务器”角色——每个节点都被视为“对等点”。

如果您有两个对等点，对等点 A 和对等点 B，对等点 A 的配置文件将在 [Interface] 部分中包含其自己的本地接口的设置，并在 @ 部分中包含其与对等点 B 的远程连接的设置987654322@ 部分。同样，对等 B 的配置文件将在 [Interface] 部分中具有其自己的本地接口的设置，在 [Peer] 部分中具有其与对等 A 的远程连接的设置。所以 Peer A 配置中的 [Interface] 部分对应于 Peer B 配置中的 [Peer] 部分；并且 Peer B 配置中的 [Interface] 部分对应于 Peer A 配置中的 [Peer] 部分。

---

端点（[Peer] 配置部分）是远程对等方的“真实”IP 地址和端口，位于 WireGuard *** 之外。此设置告诉本地主机如何连接到远程对等方以设置 WireGuard 隧道。

在示例配置中，Endpoint = 54.91.5.139:1952 用于远程对等点，通过该对等点的虚拟 WireGuard 隧道路由的任何数据包实际上都将被加密，包装在一组新的 UDP 数据包中，并通过 Internet（或某些其他“真实”网络，例如您的公司网络）到54.91.5.139 UDP 端口1952。

除非你也在 WireGuard 之外的本地主机上做一些花哨的路由，如果你尝试从本地主机发送 ping 数据包到这个端点（例如ping 54.91.5.139），或者如果你尝试访问其他一些服务通过此端点地址从本地主机访问远程对等点（例如，在 Web 浏览器中导航到 http://54.91.5.139/），您将不会使用 WireGuard 隧道——您将使用常规互联网（或其他“真实”网络）连接。

AllowedIPs（[Peer] 配置部分）是本地主机应通过 WireGuard 隧道路由到远程对等方的 IP 地址集。这个设置告诉本地主机什么进入隧道。

在示例配置中，AllowedIPs = 10.129.130.1/32 表示远程对等方，本地主机上发往10.129.130.1 的任何数据包都不会直接通过您的常规 Internet（或其他“真实”网络）连接发送，而是首先发送发送到虚拟 WireGuard 隧道。 WireGuard 将对它们进行加密，将它们包装在一组新的 UDP 数据包中，然后通过 Internet（或其他“真实”网络）将它们发送到对等端的端点 54.91.5.139。从那里，对等方将解包和解密数据包，并尝试将它们转发到10.129.130.1。

因此，如果您尝试从本地主机发送 ping 数据包到10.129.130.1（例如ping 10.129.130.1），或者尝试访问10.129.130.1 的其他服务（例如在网络浏览器中导航到http://10.129.130.1），您将使用 WireGuard 隧道。

相反，就像您提到的，对于从该远程对等方通过隧道到达的数据包，如果它们在解包和解密后具有AllowedIPs 指定的块之外的源 IP（例如源IP 是10.1.1.1 而不是10.129.130.1)，本地主机会丢弃它们。

地址（[Interface] 配置部分）是本地主机的虚拟 IP 地址，在 WireGuard *** 中。此设置会影响进出 WireGuard 隧道的数据包的路由，因此不应是可在 *** 外部路由的“真实”IP 地址。

在示例配置中，Address = 10.193.130.174/16，WireGuard *** 中本地主机的虚拟 IP 地址为10.193.130.174。因此，本地主机通过 WireGuard 隧道发送的来自本地套接字的任何数据包都将具有10.193.130.174 的源地址，并且它从隧道接收到的目标地址为10.193.130.174 的任何数据包都将被路由回本地套接字（除非你在 WireGuard 之外做一些花哨的路由）。

假设主机的“真实”网络地址是10.10.10.10。如果从主机运行ping 10.129.130.1，主机将生成源地址为10.193.130.174，目标地址为10.129.130.1 的ping 数据包，并通过WireGuard 隧道发送。 WireGuard 将加密这些数据包，并用源地址为10.10.10.10，源端口为51820（WireGuard 默认，因为配置中未指定ListenPort）的UDP 数据包包装它们，目标地址为@ 987654359@，目的端口为1952。然后它将这些 UDP 数据包发送到“真实”网络。

当远程对等点在 IP 地址 54.91.5.139 和 UDP 端口 1952 上侦听“真实”网络接口时，接收到这些数据包，它将解包和解密它们。然后它将以原始形式在自己的网络堆栈上重新排队，作为源地址为10.193.130.174 和目标地址为10.129.130.1 的ICMP 数据包。

如果原始主机收到来自该远程对等方的 ping 回复，则最初会从“真实”网络接口作为 UDP 数据包接收，源地址为54.91.5.139，源端口为@ 987654366@，目的地址10.10.10.10，目的端口51820。 WireGuard 会将这些数据包解包并解密回其原始形式，作为源地址为10.129.130.1 和目标地址为10.193.130.174 的ICMP 数据包，然后将它们重新排队。由于虚拟 WireGuard 接口的 IP 地址是 10.193.130.174（通过 Address 设置配置），本地主机将知道将这些数据包路由回本地套接字。

---

请注意，为Address 设置（在我们的示例中为/16）指定网络掩码会影响本地主机做出的关于应将哪些流量发送到隧道中的路由决策（以及如何处理由隧道），以一种与AllowedIPs 设置冗余或交叉目的的方式。在我们的示例中，Address = 10.193.130.174/16，通常会导致发往10.193.x.x 范围内任何地址的所有流量都路由到本地主机上的此 WireGuard 接口（不包括接口自己的地址10.193.130.174，这将被路由到环回接口）。

但是，我们示例中唯一对等点的AllowedIPs 设置不包括10.193.x.x 范围内的任何内容。因此，如果我们在主机上运行ping 10.193.0.1，主机将生成源地址为10.193.130.174、目标地址为10.193.0.1 的ping 数据包，并通过WireGuard 隧道发送。但由于该目标地址不适合任何已配置对等方的AllowedIPs，因此 WireGuard 会丢弃这些数据包。

所以通常最简单的方法是在 Address 设置中省略网络掩码（对于 IPv4 地址，或使用 /32，效果相同），并仅在每个对等点上使用 AllowedIPs 设置来控制什么是路由到它。通常，只有当您有许多不同的对等点使用相同的虚拟子网时（或者如果您在 WireGuard 之外进行一些奇特的路由），您才会指定网络掩码。

---

关于Endpoint还有一点需要了解的是，您只需将其设置在WireGuard隧道的一侧（但如果双方都有静态IP，则可以在两侧设置）。如果您在 Peer A 的配置中为 Peer B 设置 Endpoint，但在 Peer B 的配置中为 Peer A 省略它，则 Peer A 将能够与 Peer B 启动和设置隧道，而 Peer B 不必知道 Peer提前 A 的端点。

如果对等点 A 具有动态分配的公共 IP 地址，这是理想的选择；但缺点是对等点 B 将无法启动隧道——它必须等待对等点 A 连接到它。如果您有时需要 Peer B 发起与 Peer A 的连接，您可以通过在 Peer A 的配置中包含 Peer B 的 PersistentKeepalive 设置来缓解这种情况——这将指示 Peer A 主动伸出并连接到 Peer B N 秒（其中 N 是您在 PersistentKeepalive 设置中输入的值）。

【讨论】：

这是一个绝妙的回应！我必须重复几次才能确保我理解正确。只有一件事：本地主机的[Address]字段中的10.193.130.174/16意味着它可以使用10.193.x.x范围的地址，不是吗？我问是因为您提到本地主机将专门使用 10.193.130.174。

或者也许正如你提到的，本地主机只能使用 10.193.130.174 向 *** 的其他成员发送数据包，而一旦它收到来自其他成员的数据包，只要他们有 10.193.xx 形式在他们的目标IP地址中，本地主机没问题，它会保留数据包（即，将其发送到它自己的套接字）。

我还有一个问题：在我看来，只有端点才是实用的，而不是Address 和AllowedIPs。据我了解，Address 和AllowedIPs 基本上是将数据包路由到公共 IP 的标志或标准。我对么？因为如果Address 和AllowedIPs 足以传递数据包，为什么还要endpoints？

Re Address = 10.193.130.174/16，/16 网络掩码只是一个路由快捷方式，表明本地主机可以直接路由到其他 10.193.x.x 地址，而不必通过另一个路由器发送数据包——但是通常那些其他10.193.x.x 地址将是 *** 中的其他对等点，而不是主机本身。无论网络掩码如何，主机本身都会使用10.193.130.174（除非您正在做一些非常复杂的事情）。

请注意，使用域名作为端点也可以。

【参考方案2】：

端点是wireguard 可以通过云连接的URL。所以它应该包含公共 IP 地址和端口号。

Allowed-ips 是将路由到对等方的地址列表。确保指定至少一个包含 WireGuard 连接的内部 IP 地址的地址范围。

所以 Endpoint 有公共 IP 地址，但 Allowed-ips 是地址列表（Wireguard 连接的内部 IP 地址）

【讨论】：

Endpoint的意义是什么？至于内部 IP 地址，您是指 *** 内部的 IP 地址吗？

Endpoint 的意义是具有域而不是公共 IP 地址的 Wireguard 端点。由于安全问题，我们可以使用域而不是公共 IP 地址。 *** 内部的内部 IP 地址。是的

但是在回答中你说 Endpoint 有公共 IP...我很困惑，对不起。

域可用于 Wireguard 端点。 Wireguard 中有两种端点。一个是带有公共IP地址和端口号的端点，另一个是带有域的端点的意义。

【参考方案3】：

对于路德维希先生的回答，我真的没什么可补充的。 WireGuard 的设计有点简单。尽管如此，这里是我当前设置的一个示例，包括“服务器”端的 nftables 规则，允许所有“客户端”对等方 ping 我的 LAN 上的机器。

服务器配置（Ubuntu），存储在/etc/wireguard/wg0.conf。本地局域网地址192.168.2.0/24，这个特定的服务器地址在局域网接口上是192.168.2.1，在***（WireGuard）接口上是192.168.3.1（wg0）。分配给 WireGuard *** 的地址是192.168.3.0/24：

[Interface]
Address = 192.168.3.1/24
#SaveConfig = true
ListenPort = 51820
PrivateKey = +N3K<redacted>

# Peer configurations
[Peer]
PublicKey = h/tr<redacted>
AllowedIPs = 192.168.3.0/24

客户端（或对等）配置 (Windows)，存储在 Windows 的官方 WireGuard 客户端上（不确定文件或注册表当前所在的位置）。本地 *** 地址为192.168.3.2:

[Interface]
PrivateKey = gIIB<redacted>
Address = 192.168.3.2/24

[Peer]
PublicKey = od4j<redacted>
AllowedIPs = 192.168.3.0/24, 192.168.2.0/24
Endpoint = <MyFreeDdnsDomainOn>.duckdns.org:51820
PersistentKeepalive = 25

Ubuntu（服务器）端的

nftables规则，存储在/etc/nftables.conf，包括我的防火墙规则：

define wan = "eth0"
define lan = "br0"
define lo = "lo"
define *** = "wg0"

table ip nat 
        chain PREROUTING 
                # priority dstnat = -100.
                type nat hook prerouting priority dstnat; policy accept;
        

        chain INPUT 
                # priority srcnat = 100.
                type nat hook input priority 100; policy accept;
        

        chain OUTPUT 
                # priority dstnat = -100.
                type nat hook output priority -100; policy accept;
        

        # For all packets to WAN (eth0), after routing, replace the source address
        # with the primary IP of WAN interface (masquerade).
        # Also necessary to enable masquerade on LAN for WireGuard (***).
        chain POSTROUTING 
                # priority srcnat = 100.
                type nat hook postrouting priority srcnat; policy accept;
                oifname $wan counter masquerade
                oifname $lan counter masquerade
        


# Allow all outgoing, but drop incoming and forwarding packets by default:
table ip filter 
        chain INPUT 
                type filter hook input priority filter; policy drop;
                # Boilerplate acceptance policy.
                iifname $lo counter accept
                iifname $lan counter accept
                iifname $*** counter accept
                # Accept already established and related connections.
                iifname $wan ct state established,related counter accept
                # Drop invalid packets.
                iifname $wan ct state invalid counter drop
                # Pass traffic to protocol-specific chains:
                # Only allow new connections (established and related should already be handled)
                # For TCP, additionally only allow new SYN packets since that is the only valid
                # method for establishing a new TCP connection.
                iifname $wan ip protocol udp ct state new counter jump UDP
                iifname $wan tcp flags & (fin | syn | rst | ack) == syn ct state new counter jump TCP
                iifname $wan ip protocol icmp ct state new counter jump ICMP
                # Drop anything that's fallen through to this point.
                counter drop
        

        chain FORWARD 
                type filter hook forward priority filter; policy drop;
                # Forward filtering boilerplate rules.
                iifname $wan oifname $lan ct state established,related counter accept
                iifname $*** oifname $lan counter accept
                iifname $lan oifname $*** counter accept
                iifname $lan oifname $wan counter accept
        

        chain OUTPUT 
                type filter hook output priority filter; policy accept;
        

        # Custom per-protocol chains:
        chain ICMP 
        

        # Acceptable TCP traffic:
        chain TCP 
                # Example:
                #iifname $wan tcp dport 51413 counter accept
        

        # Acceptable UDP traffic:
        chain UDP 
                # Allow WireGuard
                iifname $wan udp dport 51820 counter accept