Netcup VPS 更新内核后 SSH 失联：防火墙拦截 DHCP 导致 IPv4 丢失

给一台 Netcup VPS 做 Debian 13 的常规系统更新，更新过程中安装了新的 Linux 内核。整个升级过程没有明显报错，按照正常流程完成后执行重启：

apt update
apt full-upgrade
reboot

没想到重启之后服务器突然无法通过 SSH 连接，看起来就像系统没有正常启动。

由于故障恰好发生在内核更新之后，最开始很容易把问题归到新内核上。但后面的排查证明，Linux 内核实际上已经正常启动，SSH 服务也没有异常。

真正的问题出在网络层：这台服务器的 IPv4 使用 DHCP 获取，而 Netcup SCP 防火墙的入站白名单中缺少 DHCP 回包规则，导致重启后无法正常取得公网 IPv4。

最终补充 DHCP 的 UDP 67 → 68 入站规则，并在重新启用防火墙后再次重启验证，IPv4 和 SSH 均恢复正常。

这类问题的迷惑性比较强，所以记录一下完整排查过程。

一、SSH 失联，不代表服务器没有启动

SSH 已经无法连接时，继续从公网反复尝试意义不大。Netcup SCP 提供了网页控制台，可以直接查看服务器本身的运行状态。

进入 VNC / Console 后，Debian 登录界面可以正常显示。

这至少说明系统已经完成了主要启动过程：

GRUB
  ↓
Linux Kernel
  ↓
systemd
  ↓
Debian 用户空间
  ↓
登录终端

登录后首先确认正在运行的内核：

uname -r

输出显示系统已经运行在刚安装的新内核上。

如果真的是内核无法启动，通常不会顺利进入正常的 Debian 登录界面。因此到这里，新内核本身已经不是首要怀疑对象。

二、继续检查 SSH 服务

系统能够启动，但 SSH 仍然连接不上，下一步就是确认 sshd 是否正常。

systemctl status ssh --no-pager

服务状态显示：

active (running)

再检查监听状态：

ss -lntp | grep ssh

sshd 也正常监听配置中的管理端口。

到这里已经可以确认：

• Debian 正常启动；
• 新内核正常运行；
• SSH 服务正常；
• SSH 端口正常监听。

既然服务器内部一切正常，但公网仍然无法访问，排查方向就应该从“系统有没有启动”转向网络。

三、关键线索：网卡出现 169.254.x.x

检查当前网卡地址：

ip -br a

这时发现网卡没有获得正常的公网 IPv4，而是出现了类似：

169.254.x.x/16

继续检查 IPv4 路由：

ip route

正常的公网默认网关也没有出现。

再测试外部网络：

ping -c 3 1.1.1.1

返回类似：

Destination Host Unreachable

这时候问题已经非常明确：服务器不是没启动，而是没有取得正常的公网 IPv4 和对应的默认路由。

169.254.0.0/16 属于 IPv4 Link-Local 地址。简单理解，在正常 IPv4 配置没有成功建立时，系统可能出现这种只能用于本地链路通信的地址。

因此从外部 SSH 连接不上，只是网络故障带来的结果。

四、确认 IPv4 的获取方式

继续查看 Debian 网络配置：

cat /etc/network/interfaces

其中 IPv4 部分是：

auto ens3
iface ens3 inet dhcp

也就是说，这台服务器的公网 IPv4 并不是手工静态写入配置文件，而是通过 DHCP 获取。

再检查是否存在其他配置覆盖：

ls -la /etc/network/interfaces.d/

没有发现额外的网络配置文件。

与此同时，网卡本身能够正常被新内核识别并处于 UP 状态，因此也没有证据表明这是虚拟网卡驱动问题。

排查范围进一步缩小为：

DHCP 为什么没有正常完成？

五、检查 DHCP 客户端

系统中存在正常的 DHCP 客户端，实际使用的是 dhcpcd。

因此并不是简单的“系统没有安装 DHCP 客户端”。

为了排除 Netcup SCP 防火墙的影响，临时停用上游防火墙，然后让网络重新获取 IPv4。

随后日志中出现了正常的 DHCP 过程，内容类似：

ens3: offered <公网IPv4>
ens3: probing address <公网IPv4>
ens3: leased <公网IPv4>
ens3: adding route
ens3: changing default route

再次检查：

ip -br a
ip route

公网 IPv4 和默认路由均恢复。

测试外网：

ping -c 3 1.1.1.1

也重新正常。

SSH 随即恢复连接。

至此可以确定：Debian 网络配置、网卡和 DHCP 客户端本身都具备正常工作的条件，而 Netcup SCP 防火墙是否启用与故障是否出现存在直接对应关系。

六、检查 Netcup 防火墙规则

原来的 Netcup 防火墙采用的是白名单方式：只允许需要对公网开放的服务进入，其余入站流量由最终的隐式规则统一丢弃。

大致逻辑如下：

必要的 TCP/UDP 服务    ACCEPT
ICMP / ICMPv6         ACCEPT

其他 INCOMING         DROP
OUTGOING               ACCEPT

问题是其中没有针对 DHCP IPv4 回包的入站规则。

DHCPv4 的通信端口为 UDP 67 和 UDP 68。简化来看：

VPS UDP 68
    ↓
DHCP Server UDP 67

DHCP Server UDP 67
    ↓
VPS UDP 68

当前防火墙允许全部 OUTGOING，因此 VPS 发出的 DHCP 请求没有被阻止。

但 DHCP Server 返回的数据包属于入站 UDP：

Source Port: 67
Destination Port: 68

如果这类流量没有提前匹配到 ACCEPT，最终就会落到：

INCOMING → DROP

这与实际观察到的现象完全吻合。

七、Netcup 官方文档怎么说

为了避免只凭现象下结论，后续又查阅了 Netcup 官方防火墙文档。

官方说明中有两个关键点。

第一，Netcup 防火墙的连接跟踪可以自动识别服务器主动建立的 TCP 连接，并接受相应的返回流量；但这一机制并不以同样方式应用于 UDP，因此使用 UDP 服务时需要同时考虑请求和响应方向。

第二，官方文档专门提供了 DHCP 示例，其中 IPv4 DHCP 的入站规则就是：

INGRESS
UDP
Source Port: 67
Destination Port: 68
ACCEPT

如果用户另外创建了自定义 EGRESS 规则，使隐式出站策略从 ACCEPT 变成 DROP，那么还需要相应允许：

EGRESS
UDP
Source Port: 68
Destination Port: 67
ACCEPT

但如果没有额外限制 EGRESS，隐式出站仍然是 ACCEPT，就不需要为了 DHCP 单独增加这一条出站规则。

需要特别说明的是，并不是所有 Netcup VPS 都一定需要增加 DHCP 规则。

是否需要这条规则，首先取决于服务器的 IPv4 是否通过 DHCP 获取。如果 IPv4 使用静态配置，自然不存在同样的 DHCP 获取过程。

八、最终修复：放行 UDP 67 → 68

进入 Netcup SCP：

Firewall Policies
→ Create Firewall Policy

新建一个用于 DHCP IPv4 的策略。

例如：

名称：
DHCP IPv4 放行

描述：
允许 IPv4 DHCP 回包，避免 DHCP 配置的服务器无法取得 IPv4

添加以下规则：

也就是：

DHCP Server UDP 67
        ↓
VPS UDP 68

源端口 67，目标端口 68，不要填反。

创建完成后，将该 Policy 分配给需要使用它的服务器并保存。

九、为什么这次只增加 INCOMING 就够了

这里需要结合当前防火墙的隐式规则来看。

当前服务器是：

INCOMING → DROP
OUTGOING → ACCEPT

所以 DHCP 请求：

VPS UDP 68
→ DHCP Server UDP 67

已经可以正常发出。

真正缺少的是返回方向：

DHCP Server UDP 67
→ VPS UDP 68

因此只增加一条 INCOMING 规则即可。

如果以后主动创建了 EGRESS 白名单规则，需要注意 Netcup 的隐式 EGRESS 也会变成 DROP。届时 DNS、NTP、DHCP 等 UDP 客户端流量都需要按照实际用途重新考虑请求和返回方向。

十、修复后一定要真正重启验证

完成规则以后，先重新启用 Netcup 防火墙。

确认当前网络仍然正常后，再执行：

reboot

原因很简单：这次故障原本就是在重启重新初始化网络以后出现的。

系统重新启动后检查：

uname -r
ip -br a
ip route

需要确认：

• 新内核正常启动；
• 网卡获得正常公网 IPv4；
• 默认 IPv4 路由正常；
• IPv6 配置正常；
• SSH 可以重新建立新连接。

实际重新启动验证后，防火墙保持启用状态，公网 IPv4 可以正常获得，SSH 也能够正常连接。

这才算完成了整个故障闭环。

十一、这次为什么特别容易误判

整个时间顺序刚好是：

apt full-upgrade
        ↓
安装新内核
        ↓
reboot
        ↓
SSH 失联

从表面上看，非常像：

新内核把服务器更新坏了。

但把系统启动和网络状态拆开检查后，实际过程是：

Debian 正常完成更新
        ↓
新内核正常启动
        ↓
SSH 服务正常启动
        ↓
网卡正常识别
        ↓
IPv4 需要通过 DHCP 获取
        ↓
DHCP 返回流量未被当前入站白名单允许
        ↓
公网 IPv4 没有正常建立
        ↓
出现 169.254.x.x
        ↓
默认 IPv4 路由异常
        ↓
公网 SSH 无法连接

所以“更新内核后失联”和“内核导致失联”是两回事。

排障时如果只盯着刚刚发生的更新，很容易走错方向。

十二、以后遇到类似问题怎么快速判断

如果 VPS 在重启后突然 SSH 失联，推荐先通过服务商提供的 VNC / Console 登录，而不是立即回滚内核或者重装系统。

可以依次检查：

uname -r
systemctl status ssh --no-pager
ss -lntp | grep ssh
ip -br a
ip route

判断思路很简单：

系统登录界面正常
        ↓
内核正常
        ↓
SSH 正常
        ↓
检查网卡 IP
        ↓
检查默认路由

如果这时看到：

169.254.x.x

就应该优先检查：

• IPv4 是静态配置还是 DHCP；
• DHCP 客户端是否正常；
• 网卡配置有没有加载；
• 默认路由是否建立；
• 服务商防火墙是否允许 DHCP 所需流量。

总结

这次故障最开始表现为：

Debian 更新并重启后，服务器 SSH 失联。

但经过 VNC、SSH 服务、网卡地址、路由和 DHCP 一层层排查后，最终确认问题并不在 Linux 新内核。

真正需要修复的是 Netcup SCP 防火墙中缺少的 DHCP IPv4 入站规则：

INCOMING
UDP
Source Port: 67
Destination Port: 68
ACCEPT

补充规则、重新启用防火墙并实际重启验证后，IPv4 和 SSH 均恢复正常。

这次最大的经验不是记住 67 和 68 两个端口，而是：

“服务器重启后 SSH 失联”只能说明公网访问出了问题，并不能直接证明系统没有启动。

先通过 Console 确认系统状态，再检查 SSH、IP 地址和默认路由，往往比直接回滚内核更有效。

而如果看到 169.254.x.x，就应该尽快把排查重点转向 IPv4 配置和 DHCP。