PVE安装OpenWrt局域网DHCP分配问题排查

Posted on

从 brctl show br-lan 的输出可以看出，eth0 已经正确绑定到 br-lan 桥接接口，但 DHCP 仍然不工作。以下是进一步排查和解决方案：

关键问题定位

  1. 物理接口已绑定：

    • eth0 是 br-lan 的成员（对应 PVE 的 net0，桥接 vmbr0）。
    • 但客户端连接的可能是 net1（vmbr1），而 net1 未加入 OpenWrt 的 LAN 桥接。

  2. DHCP 未响应：

    • 虽然 dnsmasq 在运行，但可能因 防火墙规则 或 网络隔离 未处理请求。

解决方案

步骤 1：将 PVE 的 net1（vmbr1）加入 OpenWrt LAN

  • 方案 1：将 eth1 加入 br-lan（推荐）：

    1
    2
    3
    uci set network.lan.ifname='eth0 eth1'  # 同时绑定 eth0 和 eth1
    uci commit network
    /etc/init.d/network restart
    • 验证绑定：
      1
      brctl show br-lan
      应输出：
      1
      2
      br-lan          eth0
      br-lan          eth1

  • 方案 2：单独使用 net1 作为 LAN 口：

    1
    2
    3
    uci set network.lan.ifname='eth1'  # 仅用 eth1 作为 LAN
    uci commit network
    /etc/init.d/network restart

步骤 2：确认 PVE 桥接配置

  • 确保客户端设备连接到 vmbr1（net1）对应的物理网口。
  • 检查 PVE 主机桥接状态：
    1
    brctl show vmbr1
    应显示 net1 的物理网卡（如 enp4s0）。

步骤 3：强制重启 DHCP 服务

1
2
3
/etc/init.d/dnsmasq stop
/etc/init.d/dnsmasq start
logread | grep dnsmasq  # 查看日志是否有错误

步骤 4：关闭防火墙测试

1
2
3
4
5
uci set firewall.@defaults[0].input='ACCEPT'
uci set firewall.@defaults[0].output='ACCEPT'
uci set firewall.@defaults[0].forward='ACCEPT'
uci commit firewall
/etc/init.d/firewall restart

步骤 5：抓包验证

  • 在 OpenWrt 上抓包：
    1
    tcpdump -i br-lan -n port 67 or port 68 -vv
    • 如果看到 DHCP Discover 但无 Offer，说明 dnsmasq 未响应。
    • 如果无 Discover，说明物理链路有问题。

常见问题

现象 原因 修复
br-lan 无 eth1 net1 未绑定 uci set network.lan.ifname='eth1'
客户端无链路 PVE vmbr1 未接网线 检查物理连接
DHCP 日志报错 地址池冲突 uci set dhcp.lan.start=100

最终验证

  1. 客户端连接：
    • 确保设备连接到 vmbr1 对应的物理网口。
  2. IP 分配：
    1
    cat /tmp/dhcp.leases  # 查看已分配IP
  3. 网络连通性：
    1
    ping 192.168.2.1  # 从客户端测试网关

如果问题仍未解决，请提供以下信息：

1
2
ip link show   # 所有网卡状态
uci show firewall  # 防火墙规则

时间: 2025-04-20T21:14:49

👤 用户

通过PVE安装的openwrt作为主路由局域网无法分配DHCP

时间: 2025-04-20T20:54:36

🤖 DeepSeek (deepseek-chat)

在Proxmox VE (PVE) 上安装OpenWrt作为主路由时，如果局域网设备无法获取DHCP分配的IP地址，可能是由于以下几个原因导致的。请按照以下步骤排查和解决问题：

1. 检查OpenWrt的LAN接口配置

  • 登录OpenWrt的Web管理界面（默认IP通常是192.168.1.1）或通过SSH登录。
  • 进入 Network → Interfaces → LAN 配置页面，确认以下设置：
    • Protocol：设置为 Static Address（静态IP）。
    • IPv4 Address：设为你的局域网网关地址（如192.168.1.1）。
    • Netmask：通常为 255.255.255.0。
    • DHCP Server 选项卡：
      • 确保 Enable DHCP 已勾选。
      • Start 和 Limit 范围正确（如192.168.1.100-192.168.1.250）。
      • Lease time 可保持默认（如12h）。

2. 验证PVE的网络配置

  • OpenWrt虚拟机需要正确绑定到物理网卡（直通或桥接模式）：
    • 方案1：桥接模式（推荐新手）
      • 在PVE中，OpenWrt虚拟机的网络设备应绑定到桥接网卡（如vmbr0）。
      • 物理网卡（如eth0）需关联到vmbr0（PVE宿主机的 /etc/network/interfaces 配置示例）：
        1
        2
        3
        4
        5
        auto vmbr0
        iface vmbr0 inet manual
            bridge-ports eth0
            bridge-stp off
            bridge-fd 0
    • 方案2：PCI直通（高性能）
      • 将物理网卡直通给OpenWrt虚拟机，需在PVE中启用IOMMU并配置直通。

3. 检查防火墙规则

  • OpenWrt默认的防火墙规则通常允许DHCP流量，但如果你修改过规则，需确保：
    • LAN区域的防火墙设置（Network → Firewall）允许DHCP（端口67/UDP）和DNS（端口53）流量。
    • 可尝试临时关闭防火墙测试：
      1
      2
      3
      uci set firewall.@defaults[0].input='ACCEPT'
      uci commit firewall
      /etc/init.d/firewall restart

4. 排查DHCP服务进程

  • 通过SSH登录OpenWrt，检查DHCP服务（dnsmasq）是否运行：
    1
    ps | grep dnsmasq
    • 如果没有运行，重启服务：
      1
      /etc/init.d/dnsmasq restart
    • 查看DHCP日志：
      1
      logread | grep dhcp

5. 确认客户端连接

  • 确保客户端设备连接到OpenWrt的LAN口（或正确的VLAN）：
    • 如果使用PVE虚拟交换机，检查端口组和VLAN标签配置。
    • 尝试手动释放并续租IP（Windows示例）：
      1
      2
      ipconfig /release
      ipconfig /renew

6. 其他可能原因

  • IP冲突：确保OpenWrt的LAN IP不与局域网内其他设备冲突。
  • MTU问题：如果网络存在MTU不一致，可能导致DHCP失败。尝试在OpenWrt的LAN接口设置MTU为1500：
    1
    2
    3
    uci set network.lan.mtu=1500
    uci commit network
    /etc/init.d/network restart
  • PVE虚拟网卡模型：将OpenWrt虚拟机的网卡类型设置为 VirtIO（性能最佳）。

最终测试

  • 在客户端执行抓包（如Linux用tcpdump，Windows用Wireshark），过滤DHCP流量：
    1
    tcpdump -i eth0 port 67 or port 68 -vv
    如果看不到DHCP Offer包，说明问题在OpenWrt端；如果能看到但客户端无响应，可能是网络链路问题。

按照以上步骤逐步排查，通常可以定位到问题根源。如果仍有问题，请提供OpenWrt的/etc/config/network和/etc/config/dhcp配置文件内容以便进一步分析。

时间: 2025-04-20T20:54:36

👤 用户

root@iStoreOS:# ps | grep dnsmasq
6317 root 2160 S {dnsmasq} /sbin/ujail -t 5 -n dnsmasq -u -l -r /bin/
6371 dnsmasq 2528 S /usr/sbin/dnsmasq -C /var/etc/dnsmasq.conf.cfg01411c
18223 root 1124 S grep dnsmasq
root@iStoreOS:# logread | grep dhcp
root@iStoreOS:~# tcpdump -i eth0 port 67 or port 68 -vv
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
21:08:01.134900 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 576)
0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from 34:47:d4:7f:12:1f (oui Unknown), length 548, xid 0x234cda7e, Flags [none] (0x0000)
Client-Ethernet-Address 34:47:d4:7f:12:1f (oui Unknown)
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Discover
Client-ID Option 61, length 7: ether 34:47:d4:7f:12:1f
Vendor-Class Option 60, length 15: “udhcp 0.9.9-pre”
Parameter-Request Option 55, length 10:
Subnet-Mask, Default-Gateway, Domain-Name-Server, Hostname
Domain-Name, BR, Netbios-Name-Server, Netbios-Node
Netbios-Scope, Option 224
21:08:02.694974 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 576)
0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from 34:47:d4:7f:12:1f (oui Unknown), length 548, xid 0x234cda7e, Flags [none] (0x0000)
Client-Ethernet-Address 34:47:d4:7f:12:1f (oui Unknown)
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Discover
Client-ID Option 61, length 7: ether 34:47:d4:7f:12:1f
Vendor-Class Option 60, length 15: “udhcp 0.9.9-pre”
Parameter-Request Option 55, length 10:
Subnet-Mask, Default-Gateway, Domain-Name-Server, Hostname
Domain-Name, BR, Netbios-Name-Server, Netbios-Node
Netbios-Scope, Option 224
21:08:10.427113 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 576)
0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from 34:47:d4:7f:12:1f (oui Unknown), length 548, xid 0x48c9e175, Flags [none] (0x0000)
Client-Ethernet-Address 34:47:d4:7f:12:1f (oui Unknown)
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Discover
Client-ID Option 61, length 7: ether 34:47:d4:7f:12:1f
Vendor-Class Option 60, length 15: “udhcp 0.9.9-pre”
Parameter-Request Option 55, length 10:
Subnet-Mask, Default-Gateway, Domain-Name-Server, Hostname
Domain-Name, BR, Netbios-Name-Server, Netbios-Node
Netbios-Scope, Option 224
21:08:11.987093 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 576)
0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from 34:47:d4:7f:12:1f (oui Unknown), length 548, xid 0x48c9e175, Flags [none] (0x0000)
Client-Ethernet-Address 34:47:d4:7f:12:1f (oui Unknown)
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Discover
Client-ID Option 61, length 7: ether 34:47:d4:7f:12:1f
Vendor-Class Option 60, length 15: “udhcp 0.9.9-pre”
Parameter-Request Option 55, length 10:
Subnet-Mask, Default-Gateway, Domain-Name-Server, Hostname
Domain-Name, BR, Netbios-Name-Server, Netbios-Node
Netbios-Scope, Option 224

时间: 2025-04-20T21:08:23

🤖 DeepSeek (deepseek-chat)

从你的排查信息来看，OpenWrt 的 dnsmasq（DHCP 服务）正在运行，但客户端（MAC 34:47:d4:7f:12:1f）发送的 DHCP Discover 请求 没有被 OpenWrt 响应。以下是可能的原因和解决方案：

1. 检查 OpenWrt 的 LAN 接口绑定

  • 确保 dnsmasq 监听在正确的接口（如 eth0）：
    1
    uci show dhcp.lan
    输出应类似：
    1
    2
    dhcp.lan.interface='lan'  # 必须与LAN接口名称一致
    dhcp.lan.ignore='0'       # 必须为0（表示不忽略）
    • 如果 interface 不是 lan 或 ignore=1，修正并重启服务：
      1
      2
      3
      4
      uci set dhcp.lan.interface='lan'
      uci set dhcp.lan.ignore='0'
      uci commit dhcp
      /etc/init.d/dnsmasq restart

2. 确认 LAN 物理接口绑定

  • 检查 OpenWrt 的 LAN 接口是否绑定到正确的物理接口（如 eth0）：
    1
    uci show network.lan
    输出中应有：
    1
    network.lan.ifname='eth0'  # 必须与PVE中OpenWrt的网卡一致
    • 如果 ifname 错误（如绑定到 br-lan 但未正确桥接），需修正：
      1
      2
      3
      uci set network.lan.ifname='eth0'
      uci commit network
      /etc/init.d/network restart

3. 检查 PVE 虚拟网络配置

  • 确保 OpenWrt 虚拟机的网卡正确连接到 PVE 桥接接口（如 vmbr0）：
    • 在 PVE 中检查 OpenWrt 虚拟机的硬件配置：
      1
      qm config <VMID> | grep net
      输出示例：
      1
      net0: virtio=BC:24:11:XX:XX:XX,bridge=vmbr0,firewall=1
    • 如果桥接错误（如绑定到 vmbr1 但物理网卡在 vmbr0），需修正。

4. 验证 DHCP 地址池和子网

  • 检查 DHCP 分配的地址范围是否与 LAN 子网匹配：
    1
    uci show dhcp.lan
    关键参数：
    1
    2
    3
    4
    dhcp.lan.start=100         # 起始IP（如192.168.1.100）
    dhcp.lan.limit=150         # IP数量
    dhcp.lan.leasetime='12h'   # 租期
    dhcp.lan.netmask='255.255.255.0'
    • 如果子网不匹配（如 LAN 是 192.168.1.1/24 但 DHCP 池是 192.168.2.100-250），需修正：
      1
      2
      3
      4
      uci set dhcp.lan.start=100
      uci set dhcp.lan.limit=150
      uci commit dhcp
      /etc/init.d/dnsmasq restart

5. 防火墙或网络隔离问题

  • 临时关闭防火墙测试：
    1
    2
    3
    4
    5
    uci set firewall.@defaults[0].input='ACCEPT'
    uci set firewall.@defaults[0].output='ACCEPT'
    uci set firewall.@defaults[0].forward='ACCEPT'
    uci commit firewall
    /etc/init.d/firewall restart
    • 如果此时 DHCP 恢复，说明防火墙规则阻塞了 DHCP 流量（需检查 Network → Firewall → Traffic Rules）。

6. 检查客户端连接的物理链路

  • 确保客户端设备连接到 PVE 宿主机的正确物理网口：
    • 如果 OpenWrt 的 eth0 对应 PVE 的 enp3s0（物理网卡1），客户端必须连接到该网卡。
    • 用 ethtool 检查物理网卡状态：
      1
      ethtool eth0 | grep "Link detected"
      输出应为 Link detected: yes。

7. 抓包分析（关键步骤）

  • 在 OpenWrt 上抓包，确认 DHCP 请求是否到达：
    1
    tcpdump -i eth0 -n port 67 or port 68 -vv
    • 如果看到客户端的 DHCP Discover 但没有 DHCP Offer 响应，说明 dnsmasq 未处理请求。
    • 检查 dnsmasq 是否监听 eth0：
      1
      netstat -ulnp | grep dnsmasq
      输出应有：
      1
      udp        0      0 0.0.0.0:67              0.0.0.0:*                           1234/dnsmasq

8. 终极排查：手动启动 dnsmasq 调试

  • 停止服务并手动运行 dnsmasq 调试：
    1
    2
    /etc/init.d/dnsmasq stop
    dnsmasq -C /var/etc/dnsmasq.conf.cfg01411c --no-daemon --log-dhcp --log-queries
    • 观察日志是否显示处理 DHCP 请求：
      1
      2
      dnsmasq-dhcp: DHCPDISCOVER(eth0) 34:47:d4:7f:12:1f
      dnsmasq-dhcp: DHCPOFFER(eth0) 192.168.1.100 34:47:d4:7f:12:1f

总结

根据你的 tcpdump 结果，客户端发送了 DHCP Discover，但 OpenWrt 未响应。最可能的原因是：

  1. LAN 接口绑定错误（eth0 未正确关联到 dnsmasq）。
  2. PVE 桥接配置问题（虚拟机网卡未连接到正确桥接接口）。
  3. 防火墙/网络隔离（阻塞了 UDP 67/68 端口）。

请按上述步骤逐步检查，重点验证 LAN 接口绑定 和 PVE 桥接配置。

时间: 2025-04-20T21:08:23

👤 用户

root@iStoreOS:# uci show dhcp.lan
dhcp.lan=dhcp
dhcp.lan.interface=’lan’
dhcp.lan.start=’100’
dhcp.lan.leasetime=’12h’
dhcp.lan.dhcpv4=’disabled’
dhcp.lan.force=’1’
dhcp.lan.limit=’116’
root@iStoreOS:# uci show network.lan
network.lan=interface
network.lan.proto=’static’
network.lan.device=’br-lan’
network.lan.ipaddr=’192.168.2.1’
network.lan.netmask=’255.255.255.0’

root@iStoreOS:# uci show dhcp.lan
dhcp.lan=dhcp
dhcp.lan.interface=’lan’
dhcp.lan.start=’100’
dhcp.lan.leasetime=’12h’
dhcp.lan.dhcpv4=’disabled’
dhcp.lan.force=’1’
dhcp.lan.limit=’116’
root@iStoreOS:# uci show network.lan
network.lan=interface
network.lan.proto=’static’
network.lan.device=’br-lan’
network.lan.ipaddr=’192.168.2.1’
network.lan.netmask=’255.255.255.0’

时间: 2025-04-20T21:12:16

🤖 DeepSeek (deepseek-chat)

从你的 uci show 输出可以看出，DHCPv4 被显式禁用了（dhcp.lan.dhcpv4='disabled'），这是导致局域网设备无法获取 IP 地址的直接原因。以下是完整的修复步骤：

1. 启用 DHCPv4 服务

1
2
3
uci set dhcp.lan.dhcpv4='server'  # 启用DHCPv4服务
uci commit dhcp
/etc/init.d/dnsmasq restart

2. 验证 LAN 接口和桥接配置

你的配置显示：

  • LAN 接口：绑定到 br-lan（软件桥接），IP 为 192.168.2.1/24。
  • DHCP 池：从 192.168.2.100 开始，分配 116 个 IP（到 192.168.2.215）。

需确认 br-lan 是否包含正确的物理接口（如 eth0）：

1
uci show network | grep -E "lan.ifname|br-lan.members"

如果输出为空或未包含物理接口（如 eth0），需手动绑定：

1
2
3
uci set network.lan.ifname='eth0'  # 将物理接口加入LAN
uci commit network
/etc/init.d/network restart

3. 检查 PVE 虚拟机网络设置

确保 OpenWrt 虚拟机的网卡已正确绑定到 PVE 桥接设备（如 vmbr0）：

1
qm config <VMID> | grep net

示例输出：

1
net0: virtio=BC:24:11:XX:XX:XX,bridge=vmbr0
  • 如果桥接错误（如绑定到 vmbr1），需在 PVE 中修正虚拟机配置。

4. 验证防火墙规则

临时关闭防火墙测试：

1
2
3
4
5
uci set firewall.@defaults[0].input='ACCEPT'
uci set firewall.@defaults[0].output='ACCEPT'
uci set firewall.@defaults[0].forward='ACCEPT'
uci commit firewall
/etc/init.d/firewall restart

如果 DHCP 恢复，需检查防火墙规则是否放行 UDP 67/68 端口。

5. 最终测试

  • 客户端手动释放/续租 IP：
    1
    2
    3
    4
    # Windows
    ipconfig /release && ipconfig /renew
    # Linux
    dhclient -r && dhclient
  • OpenWrt 抓包确认 DHCP 响应：
    1
    tcpdump -i br-lan -n port 67 or port 68 -vv
    正常应看到 DHCP Offer 和 DHCP Ack 报文。

关键点总结

问题 修复命令
DHCPv4 禁用 uci set dhcp.lan.dhcpv4='server'; uci commit
物理接口未绑定 uci set network.lan.ifname='eth0'; uci commit
PVE 桥接错误 在 PVE 中修正虚拟机网卡绑定

完成上述步骤后，DHCP 应正常分配 IP。如果仍有问题，请提供以下信息：

1
2
brctl show br-lan    # 查看桥接成员
ip link show        # 检查网卡状态

时间: 2025-04-20T21:12:16

👤 用户

root@pve:~# qm config 100 | grep net
boot: order=scsi0;net0
net0: virtio=BC:24:11:39:09:48,bridge=vmbr0
net1: virtio=BC:24:11:F1:F5:BE,bridge=vmbr1,firewall=1

时间: 2025-04-20T21:13:10

🤖 DeepSeek (deepseek-chat)

从你的 PVE 虚拟机配置 和 OpenWrt 网络配置 来看，存在 网卡绑定和桥接不匹配 的问题，导致 DHCP 无法正常工作。以下是具体分析和解决方案：

问题诊断

  1. PVE 虚拟机配置：

    • net0：桥接到 vmbr0（MAC: BC:24:11:39:09:48）
    • net1：桥接到 vmbr1（MAC: BC:24:11:F1:F5:BE）
    • 但 OpenWrt 的 br-lan 未绑定任何物理接口（eth0 或 eth1），导致 DHCP 请求无法到达。

  2. OpenWrt 配置：

    • network.lan.device='br-lan'（软件桥接），但 br-lan 未包含实际网卡（如 eth0 或 eth1）。
    • dhcp.lan.dhcpv4='disabled'（已修复，但需确认物理链路）。

解决方案

步骤 1：将物理网卡绑定到 OpenWrt 的 br-lan

在 OpenWrt 中执行：

1
2
3
4
5
uci set network.lan.ifname='eth0'   # 假设 eth0 是 net0（vmbr0）
# 或
uci set network.lan.ifname='eth1'   # 如果 eth1 是 LAN 口（net1）
uci commit network
/etc/init.d/network restart

步骤 2：确认 PVE 桥接绑定

  • 如果 eth0 是 WAN 口（连接外网）：
    • 确保 net0（vmbr0）连接光猫/上级路由。
    • net1（vmbr1）作为 LAN 口，绑定到 OpenWrt 的 br-lan。
  • 如果 eth0 是 LAN 口：
    • 需调整 PVE 配置，将 net0（vmbr0）作为 LAN 口。

步骤 3：验证网卡绑定

1
brctl show br-lan

输出应类似：

1
2
bridge name     interfaces
br-lan          eth1    # 确认物理网卡已加入桥接

步骤 4：检查 DHCP 服务

1
2
3
uci set dhcp.lan.dhcpv4='server'
uci commit dhcp
/etc/init.d/dnsmasq restart

步骤 5：测试 DHCP

  • 客户端连接：
    • 确保设备连接到 vmbr1（LAN 口）对应的物理网卡。
  • 抓包验证：
    1
    tcpdump -i br-lan -n port 67 or port 68 -vv
    应看到 DHCP Offer 报文。

常见错误排查

现象 可能原因 修复方法
客户端无 DHCP 响应 br-lan 未绑定网卡 uci set network.lan.ifname='eth1'
PVE 虚拟机无网络 桥接错误（如 WAN/LAN 反接） 调整 qm set 100 -netX 绑定
DHCP 分配错误 IP 子网不匹配（如 192.168.1.x vs 192.168.2.x） 检查 uci show network.lan

最终确认

  1. OpenWrt 接口状态：

    1
    ip addr show br-lan

    应显示 192.168.2.1/24 且 UP。

  2. PVE 网络拓扑：

    • 确保 vmbr1（LAN）连接到交换机或 AP。
    • vmbr0（WAN）连接到光猫。

完成以上步骤后，DHCP 应正常分配 192.168.2.100-192.168.2.215 的 IP。如果仍有问题，请提供：

1
2
brctl show br-lan
ip link show

时间: 2025-04-20T21:13:10

👤 用户

root@iStoreOS:# brctl show br-lan
bridge name bridge id STP enabled interfaces
br-lan 7fff.bc2411390948 no eth0
dheth0
root@iStoreOS:#

时间: 2025-04-20T21:14:49

🤖 DeepSeek (deepseek-chat)

从 brctl show br-lan 的输出可以看出，eth0 已经正确绑定到 br-lan 桥接接口，但 DHCP 仍然不工作。以下是进一步排查和解决方案：

关键问题定位

  1. 物理接口已绑定：

    • eth0 是 br-lan 的成员（对应 PVE 的 net0，桥接 vmbr0）。
    • 但客户端连接的可能是 net1（vmbr1），而 net1 未加入 OpenWrt 的 LAN 桥接。

  2. DHCP 未响应：

    • 虽然 dnsmasq 在运行，但可能因 防火墙规则 或 网络隔离 未处理请求。

解决方案

步骤 1：将 PVE 的 net1（vmbr1）加入 OpenWrt LAN

  • 方案 1：将 eth1 加入 br-lan（推荐）：

    1
    2
    3
    uci set network.lan.ifname='eth0 eth1'  # 同时绑定 eth0 和 eth1
    uci commit network
    /etc/init.d/network restart
    • 验证绑定：
      1
      brctl show br-lan
      应输出：
      1
      2
      br-lan          eth0
      br-lan          eth1

  • 方案 2：单独使用 net1 作为 LAN 口：

    1
    2
    3
    uci set network.lan.ifname='eth1'  # 仅用 eth1 作为 LAN
    uci commit network
    /etc/init.d/network restart

步骤 2：确认 PVE 桥接配置

  • 确保客户端设备连接到 vmbr1（net1）对应的物理网口。
  • 检查 PVE 主机桥接状态：
    1
    brctl show vmbr1
    应显示 net1 的物理网卡（如 enp4s0）。

步骤 3：强制重启 DHCP 服务

1
2
3
/etc/init.d/dnsmasq stop
/etc/init.d/dnsmasq start
logread | grep dnsmasq  # 查看日志是否有错误

步骤 4：关闭防火墙测试

1
2
3
4
5
uci set firewall.@defaults[0].input='ACCEPT'
uci set firewall.@defaults[0].output='ACCEPT'
uci set firewall.@defaults[0].forward='ACCEPT'
uci commit firewall
/etc/init.d/firewall restart

步骤 5：抓包验证

  • 在 OpenWrt 上抓包：
    1
    tcpdump -i br-lan -n port 67 or port 68 -vv
    • 如果看到 DHCP Discover 但无 Offer，说明 dnsmasq 未响应。
    • 如果无 Discover，说明物理链路有问题。

常见问题

现象 原因 修复
br-lan 无 eth1 net1 未绑定 uci set network.lan.ifname='eth1'
客户端无链路 PVE vmbr1 未接网线 检查物理连接
DHCP 日志报错 地址池冲突 uci set dhcp.lan.start=100

最终验证

  1. 客户端连接：
    • 确保设备连接到 vmbr1 对应的物理网口。
  2. IP 分配：
    1
    cat /tmp/dhcp.leases  # 查看已分配IP
  3. 网络连通性：
    1
    ping 192.168.2.1  # 从客户端测试网关

如果问题仍未解决，请提供以下信息：

1
2
ip link show   # 所有网卡状态
uci show firewall  # 防火墙规则

时间: 2025-04-20T21:14:49

对话统计

  • 消息总数: 10 条
  • 处理状态: 成功转换