我有一个设备（白兔交换机），在刷新过程中使用 tftp://0.0.0.0/firmware.tar 下载固件。我使用此设备和我的笔记本电脑建立了一个本地网络，TFTP 服务器为该文件提供服务。虽然可以使用路由器分配给我的笔记本电脑的正确 IP 地址使用同一 LAN 中的另一台机器下载该文件，但 0.0.0.0 地址不起作用。
闪烁的说明中提到： The flashing procedure will use the server address reported by DHCP as IP address for the TFTP transfer.
我可以看到交换机正在尝试从 0.0.0.0 下载固件。有什么办法可以避免这种情况吗？我无法更改交换机端的任何参数。
我正在尝试将我的电脑上的文件夹共享到连接到家庭网络的所有设备。我使用的是 Windows 11。
这是主机设置。
Windows 11 版本：
我已启用网络发现以及文件和打印机共享：
我已关闭密码保护的共享：
SMB Direct 已安装：
以下服务正在运行：
使用ipconfig，我的私有 IP 是：
IPv4 Address. . . . . . . . . . . : 192.168.1.87
我有一个与以下用户共享的文件夹Everyone：
从同一台 PC，我可以 ping 到192.168.1.87：
ping 192.168.1.87
Pinging 192.168.1.87 with 32 bytes of data:
Reply from 192.168.1.87: bytes=32 time<1ms TTL=128
Reply from 192.168.1.87: bytes=32 time<1ms TTL=128
Reply from 192.168.1.87: bytes=32 time<1ms TTL=128
Reply from 192.168.1.87: bytes=32 time<1ms TTL=128
Ping statistics for 192.168.1.87:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms
但是当我打开浏览器（尝试使用 Firefox 和 Edge）时，如果我导航到http://192.168.1.87，我会看到：
同样，连接到同一网络的其他设备也无法访问它。
我错过了哪些步骤来启用 Windows 11 文件夹共享？
在我位于 NAT 路由器后面的家庭网络中，我有一个 owncloud 服务器，名字很有创意，叫“owncloud”。它应保持私密，无法通过互联网访问。如果同步仅在我在家时有效，那就没问题了。
问题：当我不在家时，我的手机尝试连接到“ownloud”（例如在国外 Wifi 上）——是否会发生 Wifi 中的一些坏人创建一个同名的服务器，嗅探我的用户名/密码（他可以这样做吗？），甚至通过欺骗自己的云服务器来操纵数据？
为了能够创建 SSL 连接并摆脱浏览器警告（正常的 letsencrypt 仅适用于公共服务器），我阅读了有关使用动态 DNS 提供程序并指向内部 IP（如 192.168.2.xxx）的信息 - 并通过 DNS 记录执行 letsencrypt 身份验证。https: //dev.to/ietxaniz/how-to-implement-https-in-local-networks-using-lets-encrypt-4eh
问题：同样，在家外，手机会尝试连接到不存在的 IP。或者可能存在但指向不同的服务器。这样做是否存在安全问题？
最重要的是 - 如果是的话，有什么方法可以解决这个问题，而不是将整个服务器公开托管在我真正拥有的域上？
在我的 MacOS 上访问域时出现问题*.app。我知道这不是 WiFi/Internet 问题，因为网络上的其他设备可以访问该域。
我已经解决了这个问题，它指向 DNS 解析。然而，这不是 WiFi 配置的问题，因为我配置了不同的 DNS 服务器，但没有解决方案。
当我运行时scutil --dns，它显示有一个将.app域指向本地名称服务器的配置。
➜ ~ git:(main) ✗ scutil --dns
DNS configuration
resolver #1
nameserver[0] : 1.1.1.1
nameserver[1] : 1.0.0.1
flags : Request A records
reach : 0x00000002 (Reachable)
...
resolver #8
domain : app
nameserver[0] : 127.0.0.1
flags : Request A records, Request AAAA records
reach : 0x00030002 (Reachable,Local Address,Directly Reachable Address)
DNS configuration (for scoped queries)
resolver #1
nameserver[0] : 1.1.1.1
nameserver[1] : 1.0.0.1
if_index : 14 (en0)
flags : Scoped, Request A records
reach : 0x00000002 (Reachable)
我相信这是我几年前做的配置，但我现在无法记住或识别它来自哪里。
问题是，我如何删除app解析器或确定什么可以将其添加到我的系统范围的 DNS 配置中？
附言：我研究过
dnsmasq我过去使用过的方法，但无法确切地确定或排除它是罪魁祸首。
我已通过家庭网络连接将两个 HDD 连接并映射到我的笔记本电脑。HDD 连接到扩展坞，扩展坞连接到集线器。当通过在文件资源管理器中在两个驱动器之间进行拖放来在两个驱动器之间传输数据时，速度非常慢，大约为 1-3MB/s。我假设这是因为它将数据从一个 HDD 传输到我的 Wifi 笔记本电脑，然后再通过 Wifi 传输回另一个 HDD，这显然很慢。有没有办法绕过我的笔记本电脑并通过网络直接在两个驱动器之间传输？我的设置如下：
我有一个 Linksys 路由器和 eufy 安全系统。
当我不在家时，我的 eufy 摄像头的实时画面（包括门铃）没有向应用程序发送数据，我向他们的支持热线报告了此事。他们的建议是确保 TCP 端口 443 和 80 处于打开状态，UDP 端口 0-65535（在我看来范围很大）。
设置规则后，我和妻子的手机都显示网络“已连接但未连接互联网”。我不明白端口，是不是手机的请求被转发到摄像头集线器而不是互联网？我的笔记本电脑仍然连接良好。
我在 Linksys 端口转发中设置的规则如下：
| 应用 | 外部端口 | 内部端口 | 协议 | IP 地址 |
|---|---|---|---|---|
| 尤菲 | 443 | 443 | TCP | 192.168.1.71 |
| 应用 | 起始-结束端口 | 协议 | IP 地址 |
|---|---|---|---|
| 尤菲 | 0-65535 | UDP | 192.168.1.71 |
最近我问了一个关于路由器 DNS 缓存的问题，现在我又想问一些其他的问题：
假设 Bob 和 Alice 共享一个 LAN，该路由器具有本地 DNS 缓存。
Bob 访问一个新域名，该域名由 DNS 提供商解析，并存储在路由器的缓存中。
现在，如果 Alice 稍后访问同一个域，她是否可以使用缓存中 Bob 的早期信息？
换句话说，路由器的 DNS 缓存是在所有用户之间共享，还是仅供每个单独的用户共享？
几乎所有现代浏览器和路由器都具有DNS 缓存，它可以临时存储最近访问的域的 IP 地址，从而避免重复的 DNS 查找，从而实现更快的访问。
但是如果它们不匹配会发生什么？如果一个域名指向浏览器和路由器上的不同 IP 地址。谁优先？
我在本地网络中无法发现 Spotify Connect。我很确定这是多播的问题，但我很难找到如何解决这个问题。
我的 Raspberry Pi 上运行着LibreSpot（我的扬声器也连接到它）。它通过有线连接连接到提供互联网连接的本地（非无线）路由器（路由器 A）。此路由器 A 还通过有线连接连接到（无线）路由器 B。
我的大多数本地设备（手机、笔记本电脑等）都连接到路由器 B。问题是这些设备无法在 Spotify 中看到 librespot 服务（无论是在我的手机上还是在笔记本电脑上）。
我以前通过直接向 librespot 提供用户名和密码来查找 librespot 设备，然后它就可以在我的手机上被发现，但这种方式已被弃用，我再也无法使用。正确的解决方案是让 librespot 通过客户端通过 zeroconf 进行身份验证。
路由器 A 子网为 192.168.88.XXX，路由器 B 子网为 192.168.1.XXX。
Librespot 的 zeroconf 服务器正在 192.168.88.226 和端口 37901 上运行。它肯定正在运行，因为当我在浏览器中运行此 URL 时，它提供了基本信息：
{
accountReq: "PREMIUM",
activeUser: "",
availability: "",
brandDisplayName: "librespot",
clientID: "[id]",
deviceID: "[id]",
deviceType: "Speaker",
groupStatus: "NONE",
libraryVersion: "0.5.0",
modelDisplayName: "librespot",
productID: 0,
publicKey: "[redacted]",
remoteName: "RPi",
resolverVersion: "1",
scope: "streaming",
spotifyError: 0,
status: 101,
statusString: "OK",
supported_capabilities: 1,
supported_drm_media_formats: [ ],
tokenType: "default",
version: "2.9.0"
}
所以我认为这是一个多播问题，它没有正确广播到路由器 B 的子网。我相信如果我将我的 Pi 连接到路由器 B，它可以正常工作，但我更愿意保持我的网络原样。
我不知道如何调试甚至修复它。我是否需要以某种方式设置路由器 B 来转发零配置多播？我是否需要以不同的方式设置 LibreSpot？
谢谢您的指导。
我正在努力建立跨两个 VLAN 的连接。除非我先发起 ping，否则不同 VLAN 上的两个设备不会相互通信（SSH、traceroute 等）。Ping 最初也会超时，有时甚至根本不起作用（不一致）。有问题的网络如下：
我有一台具有第 3 层功能的 HPE 1920S 交换机，可托管两个 VLAN（VLAN 100 和 300）。每个 VLAN 都有自己的网关（名为 ASUS1 和 ASUS2，型号为 DSL-AC88U）。VLAN 100 上的所有设备都配置为使用 ASUS1（192.168.1.2）作为网关，同样，VLAN 300 上的所有设备都配置为使用 ASUS2（192.168.4.2）作为网关。每个路由器都托管一个 DHCP 服务器。两个 DHCP 服务器都已作为 DHCP 中继添加到交换机上，并具有各自的 IP。每个路由器都启用了防火墙。ASUS1 还在 TUN 配置中提供 OpenVPN 服务器，我使用它（windows1 使用）远程连接到网络。
我已在交换机上启用两个 VLAN 之间的路由。我还添加了以下静态路由：
OpenVPN 客户端配置文件
ASUS1 路由器
转变
ASUS2路由器
我已确认以下几点：
为了进行诊断，我包含了各种转储，以显示我在设备之间进行的跟踪路由、ping 和 SSH 尝试。我还按顺序包含了它们，因为我认为这很重要，因为跟踪路由和 ping 的行为会因一次尝试而异。
第一个转储显示了我从 10.8.0.2 上的 VPN 客户端 (windows1) 分别到 192.168.1.19、192.168.4.20 和 192.168.4.21 的跟踪路由尝试。请注意跨越 VLAN 时最后一跳上的第一个星号。
(base) PS C:\Users\myuser> tracert -d 192.168.1.19
Tracing route to 192.168.1.19 over a maximum of 30 hops
1 141 ms 141 ms 143 ms 10.8.0.1
2 143 ms 142 ms 142 ms 192.168.1.19
Trace complete.
(base) PS C:\Users\myuser> tracert -d 192.168.4.20
Tracing route to 192.168.4.20 over a maximum of 30 hops
1 142 ms 142 ms 142 ms 10.8.0.1
2 143 ms 143 ms 143 ms 192.168.1.3
3 * 142 ms 142 ms 192.168.4.20
Trace complete.
(base) PS C:\Users\myuser> tracert -d 192.168.4.21
Tracing route to 192.168.4.21 over a maximum of 30 hops
1 142 ms 142 ms 142 ms 10.8.0.1
2 143 ms 143 ms 145 ms 192.168.1.3
3 * 141 ms 141 ms 192.168.4.21
Trace complete.
第二个转储显示了我从 192.168.4.20 到 192.168.1.19 的跟踪路由和 ping 尝试。第一个跟踪路由以“!H”和两个星号结束。第二个跟踪路由无法解析，我发送了键盘中断。ping 成功，但数据包丢失率为 33%。ping 后，最后一次跟踪路由尝试成功。
[email protected]:~$ sudo traceroute -d 192.168.1.19
[sudo] password for myuser:
traceroute to 192.168.1.19 (192.168.1.19), 30 hops max, 60 byte packets
1 _gateway (192.168.4.2) 0.464 ms 0.515 ms 0.649 ms
2 192.168.4.3 (192.168.4.3) 3.674 ms 5.102 ms 11.126 ms
3 192.168.4.3 (192.168.4.3) 14.924 ms !H * *
[email protected]:~$ sudo traceroute -d 192.168.1.19
traceroute to 192.168.1.19 (192.168.1.19), 30 hops max, 60 byte packets
1 _gateway (192.168.4.2) 0.488 ms 0.504 ms 0.640 ms
2 192.168.4.3 (192.168.4.3) 2.594 ms 3.597 ms 4.354 ms^C
[email protected]:~$ ping 192.168.1.19
PING 192.168.1.19 (192.168.1.19) 56(84) bytes of data.
64 bytes from 192.168.1.19: icmp_seq=2 ttl=63 time=0.410 ms
64 bytes from 192.168.1.19: icmp_seq=3 ttl=63 time=0.462 ms
^C
--- 192.168.1.19 ping statistics ---
3 packets transmitted, 2 received, 33.3333% packet loss, time 2080ms
rtt min/avg/max/mdev = 0.410/0.436/0.462/0.026 ms
[email protected]:~$ sudo traceroute -d 192.168.1.19
traceroute to 192.168.1.19 (192.168.1.19), 30 hops max, 60 byte packets
1 192.168.4.3 (192.168.4.3) 1.671 ms 2.486 ms 3.258 ms
2 192.168.1.19 (192.168.1.19) 0.477 ms 0.464 ms 0.451 ms
第三个转储显示了从 192.168.4.21 到 192.168.19 的 SSH 连接最初如何超时，但在 ping 之后最终开始工作。在 ping 开始工作之前，请注意“重定向主机（新下一跳：192.168.4.3）”警告。
(base) [email protected]:~$ ssh [email protected] -p [redacted]
ssh: connect to host 192.168.1.19 port [redacted]: Connection timed out
(base) [email protected]:~$ sudo traceroute -d 192.168.1.19
[sudo] password for myuser:
traceroute to 192.168.1.19 (192.168.1.19), 30 hops max, 60 byte packets
1 _gateway (192.168.4.2) 0.373 ms 30.085 ms 30.066 ms
2 192.168.4.3 (192.168.4.3) 2.299 ms 3.130 ms 3.890 ms
3 * * *
4 * * *
5 * * *
6 * * *
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 * *^C
(base) [email protected]:~$ ping 192.168.1.19
PING 192.168.1.19 (192.168.1.19) 56(84) bytes of data.
From 192.168.4.2: icmp_seq=2 Redirect Host(New nexthop: 192.168.4.3)
64 bytes from 192.168.1.19: icmp_seq=2 ttl=63 time=0.632 ms
64 bytes from 192.168.1.19: icmp_seq=3 ttl=63 time=0.483 ms
64 bytes from 192.168.1.19: icmp_seq=4 ttl=63 time=0.389 ms
64 bytes from 192.168.1.19: icmp_seq=5 ttl=63 time=0.395 ms
^C
--- 192.168.1.19 ping statistics ---
5 packets transmitted, 4 received, 20% packet loss, time 4132ms
rtt min/avg/max/mdev = 0.389/0.474/0.632/0.098 ms
(base) [email protected]:~$ sudo traceroute -d 192.168.1.19
traceroute to 192.168.1.19 (192.168.1.19), 30 hops max, 60 byte packets
1 192.168.4.3 (192.168.4.3) 1.483 ms 2.294 ms 3.037 ms
2 192.168.1.19 (192.168.1.19) 0.439 ms 0.405 ms 0.385 ms
(base) [email protected]:~$ ssh [email protected] -p [redacted]
The authenticity of host '[192.168.1.19]:[redacted] ([192.168.1.19]:[redacted])' can't be established.
ED25519 key fingerprint is SHA256:[redacted].
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])? ^C
最后的转储显示 10.8.0.2 和 192.168.4.21 之间的 SSH 和跟踪路由尝试均失败。两者之间的跟踪路由如第一次转储中所示有效，但尝试之间显然发生了一些变化……
(base) PS C:\Users\myuser> ssh [email protected]
ssh: connect to host 192.168.4.21 port 22: Connection timed out
(base) PS C:\Users\myuser> tracert -d 192.168.4.21
Tracing route to 192.168.4.21 over a maximum of 30 hops
1 142 ms 142 ms 142 ms 10.8.0.1
2 143 ms 143 ms 143 ms 192.168.1.3
3 * * * Request timed out.
4 * * * Request timed out.
5
我的问题是：如何让 SSH 和 traceroute 通过 VPN 以及现场两个设备但位于不同 VLAN 上时能够持续工作，而无需先 ping 一下，就好像它们在同一个子网上一样？