我有一个家庭实验室，里面有几个树莓派，它们使用阿瓦希用于服务公告 - 我可以使用 ssh 连接到它们，ssh pi@<hostname>.local而不必记住各个 IP 地址。特别要注意的是，这不仅适用于我的笔记本电脑，也适用于 Pis 本身 - 也就是说，如果我通过 ssh 连接到pi1，我可以成功。ssh [email protected]
我最近建立了一个Wireguard VPN在其中一个 Pi 上运行，这样即使出门在外，我也可以访问我的家庭实验室。当我在笔记本电脑上使用此 VPN 时，我能够使用 ssh 连接到 pi ssh pi@<LAN-IP-address-of-pi>，但是不是和ssh pi@<hostname>.local。
这是为什么？我对 VPN 的理解（虽然是基本的）是，它们的工作原理是让您的连接表现得“好像”它源自 VPN 服务器。如果是这样，为什么我通过 VPN 获得的 ssh 行为与从 VPN 服务器本身获得的 ssh 行为不同？或者，如果不是这样，它怎么会不正确？
我的直觉是 DNS 解析不通过 VPN 进行 - 当我比较来自我的 VPN 笔记本电脑和 VPN 服务器的结果时dig pi.local，我得到了不同的结果（不共享整个有效负载，因为我对网络和安全了解不够，不知道什么是可以安全共享的，什么是不安全的）：
- 从我的笔记本电脑上看，该
;SERVER行引用8.8.8.8（我相信这是 Google 拥有的标准 DNS 服务器，它正确地“不知道”我的 Pi 在 LAN 上的 IP 地址） - 从 VPN 服务器来看，该
;SERVER行引用了我 LAN 的 LAN IP 地址pi 孔
不过有趣的是，这两个响应实际上都不包含ANSWER部分或 Pi 的实际 IP 地址。
答案1
我的直觉是 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 获得的 ssh 行为与从 VPN 服务器本身获得的 ssh 行为不同？或者，如果不是这样，它怎么会不正确？
更一般而言，VPN 的运作方式是连接您与 VPN 服务器一起连接到网络。您可以说它们在互联网上形成了一个虚拟 LAN。它们不无需伪装您的连接或使其看起来像您正在“像”VPN 服务器一样连接 - 如果需要，可以单独完成。（伪装不是 VPN 特有的功能，它与物理 LAN 使用的 NAT 完全相同。）
（除了 OSI 层区别之外，这就是 VPN 和代理之间的真正区别。代理服务器的主要目的是中继请求，使它们“好像”来自代理。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 广播以及大量背景噪音。）