endpoint - Wireguard 配置文件中的 Endpoint 和 AllowedIPs 字段有什么区别？

Question

我对 Wireguard 的理解是服务器和客户端的接口(interface)(虽然看起来听不清？)每个都有自己的 .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 文件(如果可能的话)？这可能是一个非常简单的问题，但是 Endpoint 的 AllowedIPs 和 [Peer] 字段之间有什么区别？我从 CryptoKey Routing 推断，一旦 interface 收到一个数据包，它就会使用 interface 私钥对其进行解密，并根据所有 AllowedIPs 的 peers 检查发件人 IP，并且如果它的凭证实际上接受了 0x104 与 0x104 匹配。另一方面，如果 peer 想要发送一个数据包，它会使用 interface 公钥对其进行加密，但它会将其发送到 peer 还是 Endpoint 之一？
编辑 1: 我确实使用了 AllowedIPs 并且 man wg 的定义对我来说仍然很模糊。尽管如此， Endpoint 字段似乎更容易掌握。
EDIT 2: 经过进一步研究，我认为 AllowedIPs 字段指定了对等方可用于接收流量或发送流量的 IP 地址。如果有人可以确认或更正这一点，我将不胜感激。

Answer 1

是的，每个接口(interface)都有自己的配置文件。 WireGuard 没有内置的“客户端”或“服务器”角色——每个节点都被视为一个“对等点”。
如果您有两个对等方，对等方 A 和对等方 B，则对等方 A 的配置文件将在 [Interface] 中具有其自己的本地接口(interface)的设置。部分，以及在 [Peer] 中与 Peer B 的远程连接的设置部分。类似地，对等点 B 的配置文件将在 [Interface] 中具有其自己的本地接口(interface)的设置。部分，以及在 [Peer] 中其与对等方 A 的远程连接的设置部分。所以[Interface] Peer A 配置中的部分对应于 [Peer] Peer B 配置中的部分；和 [Interface] Peer B 配置中的部分对应于 [Peer] Peer A 的配置部分。

端点 ( [Peer] 配置部分)是远程对等方的“真实”IP 地址和端口，位于 WireGuard VPN 之外。此设置告诉本地主机如何连接到远程对等方以设置 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 隧道——您将使用常规 Internet(或其他“真实”网络)连接。
允许的 IP ( [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 的其他服务(例如，在 Web 浏览器中导航到 http://10.129.130.1)，您将使用 WireGuard 隧道。
相反，就像你提到的，对于从这个远程对等点通过隧道的数据包，如果它们在解包和解密后具有由 AllowedIPs 指定的块之外的源 IP (例如，源 IP 是 10.1.1.1 而不是 10.129.130.1 )，本地主机将丢弃它们。
地址 ( [Interface] 配置部分)是 WireGuard VPN 中本地主机的虚拟 IP 地址。此设置会影响进出 WireGuard 隧道的数据包的路由，因此不应是可在 VPN 外部路由的“真实”IP 地址。
在示例配置中，其中 Address = 10.193.130.174/16 ，WireGuard VPN内本地主机的虚拟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的ping包和目的地址 10.129.130.1 ，并通过 WireGuard 隧道发送它们。 WireGuard 将加密这些数据包，并使用源地址为 10.10.10.10 的 UDP 数据包将它们包装起来。 ，源端口为51820 (WireGuard 默认值，因为在配置中没有指定 ListenPort)，目标地址是 54.91.5.139 ，目的端口是 1952 .然后它将这些 UDP 数据包发送到“真实”网络。
当远程对等方监听 IP 地址 54.91.5.139 处的“真实”网络接口(interface)时和 UDP 端口 1952 , 收到这些数据包，它会解包并解密它们。然后，它会将它们以原始形式在其自己的网络堆栈上重新排队，作为源地址为 10.193.130.174 的 ICMP 数据包。和10.129.130.1的目的地址.
如果原始主机收到来自该远程对等方的回复以进行 ping，则最初将从“真实”网络接口(interface)以 UDP 数据包的形式收到回复，源地址为 54.91.5.139。 , 1952的源端口，目的地址为 10.10.10.10 ，目的端口为 51820 . WireGuard 会将这些数据包解包并解密回其原始形式作为源地址为 10.129.130.1 的 ICMP 数据包。和10.193.130.174的目的地址，并将它们重新排队。由于虚拟WireGuard接口(interface)的IP地址是10.193.130.174 (通过 Address 设置配置)，本地主机将知道将这些数据包路由回本地套接字。

请注意，为 Address 指定网络掩码设置(在我们的示例中为 /16)影响本地主机做出的关于应该将哪些流量发送到隧道中(以及如何处理隧道接收到的流量)的路由决策，以一种可以冗余的方式，或与 AllowedIPs 相悖环境。在我们的示例中，Address = 10.193.130.174/16 ，这通常会导致所有流量都发往 10.193.x.x 中的任何地址。路由到本地主机上的这个 WireGuard 接口(interface)的范围(不包括接口(interface)自己的地址， 10.193.130.174 ，它将被路由到环回接口(interface))。
然而，AllowedIPs我们示例中唯一对等点的设置不包含 10.193.x.x 中的任何内容。范围。所以如果我们运行 ping 10.193.0.1在主机上，主机将生成源地址为 10.193.130.174 的 ping 数据包。和目的地址 10.193.0.1 ，并通过 WireGuard 隧道发送它们。但是由于该目标地址不适合 AllowedIPs WireGuard 将丢弃这些数据包。
所以通常最简单的方法是省略 Address 中的网络掩码。设置(对于 IPv4 地址，或使用 /32 ，具有相同的效果)，并且仅使用 AllowedIPs每个对等点上的设置以控制路由到它的内容。通常，仅当您有多个不同的对等点使用相同的虚拟子网时(或者如果您在 WireGuard 之外进行一些奇特的路由)，您才会指定网络掩码。

关于 Endpoint 的另一件事是您只需要在 WireGuard 隧道的一侧设置它(但如果两侧都有静态 IP，则可以在两侧设置)。如果您设置了 Endpoint对于 Peer A 的配置中的 Peer B，但您在 Peer B 的配置中为 Peer A 省略它，Peer A 将能够启动和建立与 Peer B 的隧道，而 Peer B 不必提前知道 Peer A 的端点。
如果对等方 A 具有动态分配的公共(public) IP 地址，则这是理想的；但缺点是 Peer B 将无法启动隧道——它必须等待 Peer A 连接到它。如果您有时需要对等方 B 发起与对等方 A 的连接，您可以通过包含 PersistentKeepalive 来缓解这种情况。在 Peer A 的配置中为 Peer B 设置——这将指示 Peer A 每 N 秒主动联系并连接到 Peer B(其中 N 是您在 PersistentKeepalive 设置中输入的值)。