主页 / computer / 问题 / 1692987
Accepted
scubbo
Asked: 2021-12-15 01:25:33 +0800 CST

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

  • 772

我有一个家庭实验室设置，其中包含一些使用Avahi进行服务公告的树莓派——我可以通过 ssh 连接到它们，ssh pi@<hostname>.local而不必记住单独的 IP 地址。特别要注意，这不仅适用于我的笔记本电脑，也适用于 Pis 本身——也就是说，如果我通过 ssh 访问pi1，我可以成功ssh [email protected]。

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

这是为什么？我（公认的基本）对 VPN 的理解是，它们通过使您的连接表现得“好像”它源自 VPN 服务器来运行。如果是这种情况，为什么我会通过 VPN 获得与 VPN 服务器本身不同的 ssh 行为？或者，如果不是这样，那它有什么不正确的？

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

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

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

ssh networking

1 个回答

  1. Best Answer

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

    不管有没有，这都不会影响 mDNS (Avahi)。这些.local名称由单独的 mDNS 解析器解析，而不是使用标准的单播 DNS 解析器，而 mDNS 的全部意义在于它可以在没有 DNS 服务器的情况下工作；它通过向整个本地子网广播查询数据包来工作。

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

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

    这是为什么？我（公认的基本）对 VPN 的理解是，它们通过使您的连接表现得“好像”它源自 VPN 服务器来运行。如果是这种情况，为什么我会通过 VPN 获得与 VPN 服务器本身不同的 ssh 行为？或者，如果不是这样，那它有什么不正确的？

    更一般地说，VPN 通过将您与 VPN 服务器一起连接到网络来运行。您可以说它们在 Internet 上形成了一个虚拟 LAN。它们不一定会伪装您的连接或让您看起来“好像”在连接 VPN 服务器 - 如果需要，可以单独完成。（伪装不是 VPN 特有的功能，它与物理 LAN 中使用的 NAT 完全相同。）

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

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

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

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

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

    （缺点是，他们还会看到彼此的 mDNS 广播——ARP 广播、Dropbox 广播、UPnP/SSDP 广播、NetBIOS 广播和 WS-Discovery 广播，以及一大堆背景噪音。）

    • 4

相关问题