☰

Win 10 是否不传递发往 Unix 套接字的数据包？

tag-icon • tag-icon windows virtual-machines ipxe
Win 10 是否不传递发往 Unix 套接字的数据包？

总之，我有一个 Linux pxe 服务器设置，现在需要在一些 Windows 10 笔记本电脑上使用，因此，为了最快、最高效的开发工作，我试图将已经构建的 Linux pxe 服务器简单地移动到我从 Windows 10 笔记本电脑上的 Virtualbox 启动的虚拟机中。早期迹象是积极的，我能够通过桥接连接将我的 dhcpd 服务传递到主机上的以太网，客户端（也是一个无头 Linux 系统）接收一个 IP 地址和下一个服务器地址，然后继续到 tftp 服务器获取 pxelinux.0 文件。这是我遇到问题的地方，发生了以下情况

  1. 客户端发送dhcp discover并通过win 10传到linux dhcpd服务器并接收ip地址。
  2. 客户端获取下一个服务器的 IP = tftp 服务器和下一个文件 = “pxelinux.0”
  3. 客户端等待 pxelinux.0 文件超时 - pxe 服务器上的 wireshark 显示从未收到该文件的 tftp 读取请求。

我已经证实的事情。

  • 服务启动 Dhcpd、nfs 和 tftp.socket 正在监听，并且 ss 命令也显示 tftp 正在监听
tftp.service - Tftp Server
     Loaded: loaded (/usr/lib/systemd/system/tftp.service; indirect; vendor pre>
     Active: inactive (dead)
TriggeredBy: ● tftp.socket
       Docs: man:in.tftpd
lines 1-5/5 (END)
systemctl status tftp.socket
● tftp.socket - Tftp Server Activation Socket
     Loaded: loaded (/usr/lib/systemd/system/tftp.socket; enabled; vendor prese>
     Active: active (listening) since Tue 2022-07-19 12:50:17 CDT; 23min ago
   Triggers: ● tftp.service
     Listen: [::]:69 (Datagram)
      Tasks: 0 (limit: 11004)
     Memory: 4.0K
        CPU: 252us
     CGroup: /system.slice/tftp.socket

Jul 19 12:50:17 fedora systemd[1]: Listening on Tftp Server Activation Socket.
lines 1-11/11 (END)
ss -lu
State   Recv-Q  Send-Q    Local Address:Port        Peer Address:Port  Process  
UNCONN  0       0               0.0.0.0:48494            0.0.0.0:*              
UNCONN  0       0         127.0.0.53%lo:domain           0.0.0.0:*              
UNCONN  0       0             127.0.0.1:323              0.0.0.0:*              
UNCONN  0       0               0.0.0.0:mdns             0.0.0.0:*              
UNCONN  0       0               0.0.0.0:hostmon          0.0.0.0:*              
UNCONN  0       0                     *:tftp                   *:*              
UNCONN  0       0                     *:tftp                   *:*              
UNCONN  0       0                 [::1]:323                 [::]:*              
UNCONN  0       0                  [::]:36714               [::]:*              
UNCONN  0       0                  [::]:mdns                [::]:*              
UNCONN  0       0                  [::]:hostmon             [::]:*
  • nfs exports 允许任何 ip 查看目录，无需 root 权限
correct/directory/to/tftpboot/  *(rw, no_root_squash)
correct/directory/to/image/root/ *(rw, no_root_squash)

所以对我来说，我已经准备好在 Linux 端接收和监听了，我的问题是：Windows 是否会更改/阻止来自或发往 unix 套接字的数据包？tftp.socket 是一个 unix 套接字，因此我不确定 Windows 是否阻止或转储了流量。我在 Windows 端进行了以下调查。

  1. 关闭所有 Windows 防火墙（没什么区别）
  2. 制定自定义规则以允许所有端口上的所有 udp 消息通过
  3. 检查 Windows 日志以查看是否有任何数据包被防火墙丢弃/阻止，这些日志中没有提到允许它通过或被阻止，这让我怀疑读取请求是否到达 Windows（至少以它可以识别的格式...）

最后一点让我不禁想问——作为桥接连接，客户端应该看到到 Linux 服务器 IP 地址的直接路径，以及以太网端口 MAC 地址之后的端口，这难道不正确吗？所以对我来说，我本以为 Windows 会完全脱离循环。但我不明白为什么在这种情况下，在虚拟机上我没有收到 tftp 读取请求，而在具有相同客户端的常规 Linux 服务器上，我只是开始收到 tftp 读取请求。任何建议提示或需要检查的事情都将不胜感激。

编辑：好的，我对 Windows 10 端进行了 wireshark 测试，确实看到了在没有过滤 IP 之后 TFTP 读取请求传来。 在此处输入图片描述

那么，有什么好方法可以查看该读取请求是否确实通过 Windows 到达虚拟机？此外，读取请求的目标 IP 地址是 192.9.200.10，即 Linux pxe 服务器，所以我原本以为它会绕过 Windows，我错了吗？

答案1

检查 TFTPd 日志，看看 TFTP 请求是否真的到达守护进程。如果到达，您还可以看到守护进程发送了一个应答，其中包括文件的名称及其大小。请求使用 UDP 端口 69 作为目标，使用“临时”UDP 端口作为源。守护进程应答（以及未来的数据传输）将通过该临时端口发送到客户端。被阻止的可能是 TFTP 服务器应答，而不是请求。

还要检查虚拟机 IP、网卡 IP 和客户端 IP 是否一致。

编辑1：

tftpd-hpa

日志保存在：

/var/log/daemon.log

通过添加参数来打开诊断日志记录-vvvv：

/etc/default/tftpd-hpa

如果你使用不同的服务器，你必须找到位置以及如何打开日志记录

其余部分听起来像这样：

  1. 处理 NIC 驱动程序时出现虚拟盒问题或
  2. 切换主机 NIC 时，可能确实会强制执行新开放的流量防火墙规则。

相关内容