我有一個家庭實驗室設置，其中有一些使用的樹莓派阿瓦希對於服務公告 - 我可以透過 ssh 連接到他們，ssh pi@<hostname>.local而不必記住單獨的 IP 位址。特別要注意的是，這不僅可以在我的筆記型電腦上運行，還可以在 Pi 本身上運行 - 也就是說，如果我透過 ssh 連接到pi1，我就可以成功。ssh [email protected]
我最近設立了一個有線電視衛士VPN在其中一台 Pi 上運行，即使我不在家也可以訪問我的家庭實驗室。在我的筆記型電腦上使用此 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 伺服器，該
;SERVER行引用我的 LAN 的 LAN IP 位址皮孔
但有趣的是，這兩個回應實際上都不包含ANSWER部分或 Pi 的實際 IP 位址。
答案1
我的直覺是 DNS 解析不通過 VPN
無論是否影響，都不會影響 mDNS (Avahi)。名稱.local由單獨的 mDNS 解析器解析，而不是使用標準的單播 DNS 解析器，mDNS 的全部重點在於它無需 DNS 伺服器即可運作；它的工作原理是向整個本地子網路廣播查詢資料包。
（從技術上講，是多播，但由於它是連結範圍的，您可以假裝它與本地廣播相同。）
你實際上不應該得到任何dig whatever.local即使引用了 Pi-Hole，“ANSWER”也會做出回應。如果您從 Pi-Hole 收到回應，那不是 Avahi/mDNS，而只是常規 DNS。 （家庭路由器透過從 DHCP 租用請求收集主機名稱來實現本地 DNS；但它們通常不會收集 mDNS 廣告，即使您碰巧擁有.localDNS 網域 - 但您不應該這樣做。）
這是為什麼？我對 VPN 的（誠然是基本的）理解是，它們的運作方式是讓您的連線「就像」源自 VPN 伺服器一樣。如果是這種情況，為什麼我透過 VPN 獲得的 ssh 行為與透過 VPN 伺服器本身獲得的 ssh 行為不同？或者說，如果事實並非如此，那又怎麼會不正確呢？
更一般地說，VPN 的運作方式是連結你與 VPN 伺服器一起連接到網路。你可以說它們形成了一個跨互聯網的虛擬區域網路。他們不必須偽裝您的連接，或讓您看起來像是在連接「好像」VPN 伺服器——如果需要，可以單獨完成。 （偽裝不是 VPN 特有的功能，它與實體 LAN 中使用的 NAT 完全相同。）
（除了 OSI 層的區別之外，這就是 VPN 和代理之間的真正區別。代理伺服器的主要目的是中繼請求，以便它們「好像」來自代理。VPN 的主要目的是構建虛擬網路。）
大多數 VPN 類型不會直接將您連接到 VPN 伺服器現存的然而，網路卻創造了一個新的一。您有兩個獨立的網路 – VPN 建立的「LAN」和實體 LAN – 並由 VPN 伺服器充當作為路由器之間。就像實體路由器具有eth0 eth1 eth2LAN/WAN 一樣，您的 VPN 伺服器在eth0（LAN）和wg0（WireGuard VPN）之間進行路由。
就像由路由器分隔的兩個實體子網路一樣，兩個子網路可以在設備之間交換常規（單播）封包，但路由器不會中繼本地廣播在子網路之間，也不會中繼 mDNS 使用的連結範圍多播。因此，當您的 VPN 用戶端發出 mDNS 多播查詢時，它只會到達 VPN 用戶端和 VPN 伺服器之間的「本機」子網路。它永遠不會透過 eth0 或其他任何方式從伺服器的 wg0 介面轉發出去。為了實現這一點，VPN 伺服器可能需要在「中繼」或「反射器」模式下運行自己的 avahi 守護進程，在該模式下，它將收到的 mDNS 查詢代理到其他介面並將回復發回。
此外，許多 VPN 連接實際上並未模擬乙太網路等「具有廣播功能」的接口，這使得廣播和組播封包的使用從一開始就不可能。 WireGuard 特別形成了一種「點對多點」網絡，它更像是引擎蓋下的一堆一對一連接 – 所有這些連接都隱藏在單個 wg0 接口後面，但在內部它使用 AllowedIPs 來決定將每個資料包發送到哪個對等點，廣播或多播也不例外。大致相同的情況也適用於預設「tun」模式的 OpenVPN（或大多數使用「tun」介面的其他模式）。
但其他一些 VPN，例如「tap」模式下的 OpenVPN，以及 Tinc 或 ZeroTier 等軟體，做模擬具有第 2 層尋址的類似以太網的網絡，允許它們以更傳統的方式處理多播和廣播。事實上，它們大多只是模擬常規以太網，允許 VPN 伺服器橋VPN 和 LAN 接口，而不是它們之間的路由。如果您設定「橋接」VPN，則連線的 VPN 用戶端實際上將成為與本機裝置相同的 LAN 子網路的一部分，並且將自動能夠看到彼此的 mDNS 廣播。
（缺點還在於，他們會看到彼此的 mDNS 廣播、ARP 廣播、Dropbox 廣播、UPnP/SSDP 廣播、NetBIOS 廣播、WS-Discovery 廣播，以及大量背景噪音。）