（重定向自networkengineering.stackexchange）
我的网络上有两个 Raspberry Pi——我们称它们为 Pi 和 Rho。
我正在尝试通过它们之间的 ssh 隧道设置端口转发，以便应用程序可以连接到 Rho 上的端口并从侦听 Pi 上的端口的服务器获取结果（我的最终目标实际上是设置端口转发，例如不同网络上的主机可以通过到 Rho 的 ssh 连接访问 Pi 上的 Samba 共享，而我不必完全打开到 Pi 的防火墙端口）。
我局域网中 Pi 的 IP 是192.168.42.69，而 Rho 的192.168.42.112IP是- 这些是我从本地网络通过 ssh 连接到它们的 IP。
为了对此进行测试，我SimpleHTTPServer在 Pi 的端口 8000 上启动了一个最小的 Python 服务器（带有），并sudo ssh -L 140:localhost:8000 root@192.168.42.69 -N在 Rho 上运行。当我curl localhost:140或curl 127.0.0.1:140在 Rho 上时，我得到了我期望的响应。但是，当我curl 192.168.42.112:140在 Rho 上时，连接被拒绝；下面的详细输出：
$ curl -vvv 192.168.42.112:140
* Expire in 0 …我有一个家庭实验室，其中有一些 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 …