为什么无法通过 VPN 解析 Avahi“.local”域？

Question

我有一个家庭实验室，其中有一些 Raspberry Pi，它们使用Avahi进行服务公告 - 我可以通过 ssh 连接到它们，ssh pi@<hostname>.local而不必记住各个 IP 地址。特别要注意的是，这不仅可以在我的笔记本电脑上运行，还可以在 Pi 本身上运行 - 也就是说，如果我通过 ssh 连接到pi1，我就可以成功ssh pi@pi2.local。

我最近设置了一个在其中一台 Pi 上运行的Wireguard VPN，这样我即使不在家也可以访问我的家庭实验室。在我的笔记本电脑上使用此 VPN 时，我可以使用 ssh 到 pi ssh pi@<LAN-IP-address-of-pi>，但不能使用ssh pi@<hostname>.local。

这是为什么？我对 VPN 的（诚然是基本的）理解是，它们的运行方式是让您的连接“就像”源自 VPN 服务器一样。如果是这种情况，为什么我通过 VPN 获得的 ssh 行为与通过 VPN 服务器本身获得的 ssh 行为不同？或者说，如果事实并非如此，那又怎么会不正确呢？

我的直觉是 DNS 解析不通过 VPN - 当我比较dig pi.local我的 VPN 笔记本电脑和 VPN 服务器的结果时，我得到不同的结果（不共享整个有效负载，因为我不太了解网络和安全性以了解哪些内容可以安全共享，哪些内容不安全）：

• 从我的笔记本电脑上，该;SERVER行引用8.8.8.8（我相信这是 Google 拥有的标准 DNS 服务器，它会正确地“不知道”我的 Pi 在 LAN 上的 IP 地址）
• 从 VPN 服务器，该行引用我的 LAN pi-hole;SERVER的 LAN IP 地址

但有趣的是，这两个响应实际上都不包含ANSWER部分或 Pi 的实际 IP 地址。

Answer 1

\n

我的直觉是 DNS 解析不通过 VPN

\n

\n

无论是否影响，都不会影响 mDNS (Avahi)。名称.local由单独的 mDNS 解析器解析，而不是使用标准的单播 DNS 解析器，mDNS 的全部要点在于它无需 DNS 服务器即可工作；它的工作原理是向整个本地子网广播查询数据包。

\n

（从技术上讲，是多播，但由于它是链接范围的，您可以假装它与本地广播相同。）

\n

即使引用了 Pi-Hole，您实际上也不应该从 中得到任何“ANSWER”响应。dig whatever.local如果您从 Pi-Hole 收到响应，则该响应不是 Avahi/mDNS \xe2\x80\x93，而只是常规 DNS。（家庭路由器通过从 DHCP 租用请求收集主机名来实现本地 DNS；但它们通常不会收集 mDNS 广告，即使您碰巧拥有.local作为 DNS 域 \xe2\x80\x93 的 DNS 域，而您不应该这样做。）

\n

\n

这是为什么？我对 VPN 的（诚然是基本的）理解是，它们的运行方式是让您的连接“就像”源自 VPN 服务器一样。如果是这种情况，为什么我通过 VPN 获得的 ssh 行为与通过 VPN 服务器本身获得的 ssh 行为不同？或者说，如果事实并非如此，那又怎么会不正确呢？

\n

\n

更一般地说，VPN 的运行方式是将您与 VPN 服务器一起连接到网络。你可以说它们形成了一个跨互联网的虚拟局域网。它们不一定会伪装您的连接，或者让您看起来像是在连接 VPN 服务器 \xe2\x80\x93（如果需要的话，可以单独完成）。（伪装不是 VPN 特定的功能，它与物理 LAN 中使用的 NAT 完全相同。）

\n

（除了 OSI 层的区别之外，这就是 VPN 和代理之间的真正区别。代理服务器的主要目的是中继请求，以便它们“好像”来自代理。VPN 的主要目的是构建虚拟网络。）

\n

然而，大多数 VPN 类型不会直接将您连接到 VPN 服务器的现有网络，而是创建一个新网络。您有两个独立的网络 \xe2\x80\x93，VPN 创建的“LAN”和物理 LAN \xe2\x80\x93，VPN 服务器充当中间的路由器。就像物理路由器具有eth0 eth1 eth2LAN/WAN 一样，您的 VPN 服务器在eth0（LAN）和wg0（WireGuard VPN）之间进行路由。

\n

正如由路由器分隔的两个物理子网一样，两者可以在设备之间交换常规（单播）数据包，但路由器不会在子网之间中继本地广播，也不会中继 mDNS 使用的链路范围多播。因此，当您的 VPN 客户端发出 mDNS 多播查询 \xe2\x80\x93 时，它只会到达 VPN 客户端和 VPN 服务器之间的“本地”子网。它永远不会通过 eth0 或其他任何方式从服务器的 wg0 接口转发出去。为了实现这一点，VPN 服务器可能需要在“中继”或“反射器”模式下运行自己的 avahi 守护进程，在该模式下，它将收到的 mDNS 查询代理到其他接口并将回复发回。

\n

此外，许多 VPN 连接实际上并不模拟以太网等“具有广播功能”的接口，这使得广播和组播数据包的使用从一开始就不可能。WireGuard 特别形成了一种“点对多点”网络，它更像是底层 \xe2\x80\x93 下的一堆一对一连接，所有这些连接都隐藏在单个 wg0 接口后面，但在内部它使用AllowedIPs来决定将每个数据包发送到哪个对等点，并且对于广播或多播也不例外。大致相同的情况也适用于默认“tun”模式的 OpenVPN（或大多数使用“tun”接口的其他模式）。

\n

但其他一些VPN，例如“tap”模式下的OpenVPN，以及Tinc或ZeroTier等软件，确实模拟了具有第2层寻址的类似以太网的网络，允许它们以更传统的方式处理多播和广播。事实上，它们大多只是模拟常规以太网，允许 VPN 服务器桥接VPN和 LAN 接口，而不是在它们之间进行路由。如果您设置“桥接”VPN，则连接的 VPN 客户端实际上将成为与本地设备相同的 LAN 子网的一部分，并且将自动能够看到彼此的 mDNS 广播。

\n

（缺点还在于，他们会看到彼此的 mDNS 广播 \xe2\x80\x93 和 ARP 广播、Dropbox 广播、UPnP/SSDP 广播、NetBIOS 广播、WS-Discovery 广播，以及大量背景噪音。）

\n