Ubuntu GNOME 远程桌面排障实录：为何只见 tcp6 监听，IPv4 却能连接？
本文由 AI 辅助整理，依据实际命令输出、服务日志及官方文档核对。记录范围是一次 GNOME Remote Desktop 远程登录故障：已完成凭据修复，并验证 RDP 协商与 TLS 握手成功；尚未记录 Windows 客户端完整进入桌面的验收结果。文中账号统一使用示例名 demo，不包含密码。
一、现场现象与结论
Ubuntu 已开启 Remote Login（远程登录），3389 端口也在监听，但远程桌面连接仍失败。排查时最容易产生的疑问是：为什么监听列表只见 tcp6、[::]:3389 或 *:3389，没有单独一行 0.0.0.0:3389？是不是 IPv4 没开？
本次结论有两层：
- 没有单独显示 IPv4 监听，不等于不能接收 IPv4。 Linux 的 IPv6 套接字可以同时接收 IPv4 映射地址；本机与跨网段的 IPv4 TCP 测试都已成功。
- 真正阻止这次 RDP 连接的是服务没有可用凭据。 日志明确出现“Credentials are not set, denying client”。重新设置系统级 RDP 凭据并重启服务后，协议协商与 TLS 握手恢复。
| 项目 | 本次观测 |
|---|---|
| 目标系统 | /etc/os-release 显示 Ubuntu 26.04.1 LTS |
| 目标地址 | 192.168.18.237 |
| 诊断客户端 | 192.168.10.220 |
| 目标路由 | 经 192.168.10.1 到达目标 |
| 服务进程 | gnome-remote-desktop-daemon --system |
| TCP 3389 | 本机 IPv4、诊断客户端 IPv4 均成功 |
| 系统级服务 | active (running) |
| 用户级同名服务 | inactive (dead) |
| 修复后 UFW 状态 | inactive；本次没有关闭防火墙 |
| 最终技术验证 | RDP 协商成功，TLSv1.3 握手成功 |
两个地址属于不同的 /24 网段，本次验证的是这条经过路由的路径，不是所有客户端和所有网络都一定可达。
二、为什么没有单独的 IPv4 监听行？
2.1 工具显示的是套接字类型，不是全部可接入协议
应用创建监听套接字时，可以选择：
- AF_INET：IPv4 套接字，例如绑定 0.0.0.0:3389。
- AF_INET6：IPv6 套接字，例如绑定 [::]:3389。
netstat 显示 tcp6，通常表示这是 IPv6 地址族的 TCP 套接字。它并没有额外承诺“拒绝所有 IPv4 客户端”。ss 的 * 则是通配地址的显示形式，单看星号也不能确定是否只接收 IPv6。
Linux 支持一个绑定 IPv6 通配地址的套接字同时处理 IPv6 和 IPv4。这种情况下，程序只需要一个监听套接字，列表自然不必再出现独立的 IPv4 行。相关机制见 Linux ipv6(7)。
2.2 决定是否双栈的是 IPV6_V6ONLY
对绑定 [::] 的 IPv6 套接字，关键选项是 IPV6_V6ONLY：
| 套接字选项 | 含义 |
|---|---|
| IPV6_V6ONLY=1 | 只处理 IPv6 |
| IPV6_V6ONLY=0 | 允许 IPv6，也允许 IPv4 映射地址 |
可把两种实现理解为：
双栈单套接字：
IPv4 客户端 ─┐
├─ AF_INET6、绑定 [::]:3389、V6ONLY=0 ─ RDP 服务
IPv6 客户端 ─┘
分开监听：
IPv4 客户端 ─── AF_INET、绑定 0.0.0.0:3389 ─┐
├─ RDP 服务
IPv6 客户端 ─── AF_INET6、绑定 [::]:3389 ───┘
两种实现都可能支持 IPv4。不能要求所有服务必须同时列出 tcp 和 tcp6 两行。套接字选项语义见 IPV6_V6ONLY 手册。
2.3 IPv4 映射地址不是“把网络改成 IPv6”
双栈套接字接收 IPv4 连接时，应用可以用 IPv4-mapped IPv6 地址表示对端，例如：
192.168.10.220 → ::ffff:192.168.10.220
这里是套接字接口里的地址表示。客户端仍然可以发送普通 IPv4 报文，不需要开启原生 IPv6，不涉及为了这个连接额外配置 NAT64。
2.4 bindv6only=0 只是默认值
此前现场检查记录为：
sysctl net.ipv6.bindv6only
# net.ipv6.bindv6only = 0
该参数提供 IPV6_V6ONLY 的系统默认值。应用仍可对自己的套接字显式设置该选项。因此：
- 看到 0，是双栈可能成立的条件之一。
- 不能仅凭这个值断言某个具体服务一定接受 IPv4。
- 更不能靠修改这个默认值，保证已经存在的监听套接字立即改变行为。
内核定义见 Linux IP sysctl：bindv6only。
对本次故障，最有力的证据是强制 IPv4 的实际连接成功。未直接读取该进程套接字的 IPV6_V6ONLY 值，因此“采用双栈单套接字”是与监听表现、系统默认值和连接测试一致的解释；“IPv4 可连接”则是已验证事实。
三、先验证网络，再判断 RDP
3.1 Ubuntu 本机强制 IPv4 测试
此前在目标主机执行：
nc -4 -vz 127.0.0.1 3389
返回：
Connection to 127.0.0.1 3389 port [tcp/ms-wbt-server] succeeded!
- -4：明确使用 IPv4。
- -v：显示结果。
- -z：只探测连接，不发送常规业务数据。
注意应写 -vz，不能漏掉前面的短横线。本机成功说明本机 IPv4 TCP 路径可用，尚不能代替远端测试。
3.2 从另一台主机检查目标端口
本次诊断端执行：
ip route get 192.168.18.237
nc -4 -vz -w 4 192.168.18.237 22
nc -4 -vz -w 4 192.168.18.237 3389
路由查询显示经 192.168.10.1、源地址 192.168.10.220 到达目标，22 与 3389 均连接成功。Windows 可使用以下等价检查，但本次未记录该 Windows 命令的实测输出：
Test-NetConnection 192.168.18.237 -Port 3389
TcpTestSucceeded=True 只证明 TCP 建连，不代表 RDP 认证、桌面会话或图像传输已经成功。
本次进一步发送 RDP 协商请求时，修复前收到连接重置。这把排查方向从“是否能到端口”推进到“服务为什么接受 TCP 后拒绝协议”。
四、登录主机，区分系统级服务与用户级服务
通过 SSH 登录后检查：
cat /etc/os-release
systemctl status gnome-remote-desktop --no-pager
systemctl --user status gnome-remote-desktop --no-pager
ss -ltn
journalctl -u gnome-remote-desktop --since "1 hour ago" --no-pager -n 80
journalctl --user -u gnome-remote-desktop --since "1 hour ago" --no-pager -n 80
需要时使用 sudo 读取完整系统日志。
实际运行的是：
/usr/libexec/gnome-remote-desktop-daemon --system
系统级服务 active，而用户级同名服务 inactive。这两项并不矛盾。 本次使用的是系统级 Remote Login，不能把用户级服务未启动当成故障，也不能只改用户级配置就期待系统级服务生效。GNOME 支持不同运行模式，见 官方项目说明。
对应关系为：
| 操作目标 | 命令 |
|---|---|
| 系统级远程登录配置 | sudo grdctl --system status |
| 当前用户的远程桌面配置 | grdctl status |
| 系统级服务 | systemctl status gnome-remote-desktop |
| 用户级服务 | systemctl --user status gnome-remote-desktop |
SSH 排查中也纠正过一次用户名拼写。用户名错误导致的 SSH 认证失败是管理连接问题，与本次 RDP 凭据问题应分开处理。
五、决定性日志：服务没有可用的 RDP 凭据
系统日志多次出现：
[RDP] Credentials are not set, denying client
这说明服务在处理客户端时拿不到可用凭据，于是主动拒绝。它比“窗口连不上”或“只看到 tcp6”更接近故障原因。
修复前后，普通 status 输出都显示：
Username: (hidden)
Password: (hidden)
hidden 只是隐藏输出，不是证明凭据已经正确配置的充分证据。 本次没有为了确认而打印密码；判断依据是错误日志、设置命令成功，以及修复前后的协议行为变化。
另一个容易误判的日志是：
Init TPM credentials failed ... using GKeyFile as fallback
这条记录表示 TPM 初始化失败后转用 GKeyFile 后端，不能单凭它断言整个 RDP 服务启动失败。本次在该提示仍存在的情况下完成了凭据设置和后续握手，因此没有把修复 TPM 当作解决本次连接阻断的前置条件。
至于此前为何缺少可用凭据——没有设置、设置在错误作用域、存储问题或运行态未更新——现有证据不足以追溯确定，不在这里编造原因。
六、修复：设置系统级 RDP 凭据并重启服务
6.1 先确认本机版本支持的命令
grdctl --help
sudo grdctl --system status
本次安装版本提供：
set-credentials [<username> [<password>]]
支持省略密码后输入。以下命令以 demo 为示例用户名，应替换为自己希望用于 RDP 第一阶段认证的名称：
sudo grdctl --system rdp set-credentials demo
按照提示输入新 RDP 密码。不要把真实密码写进示例、截图、聊天记录或命令行参数。不同版本可能有交互差异，以安装版本的帮助信息为准。GNOME 的配置方法可参考官方配置文档。
本次实际执行使用本地密码对话框采集密码，通过 SSH 加密连接及标准输入交给相关命令；没有把真实密码作为命令行参数，也没有写入脚本文件。设置 RDP 密码本身当然会由远端服务持久保存到其凭据后端。
6.2 处理现场的服务重载提示
现场 systemctl 曾提示单元文件在磁盘上发生变化、需要 daemon-reload，因此本次执行了：
sudo systemctl daemon-reload
sudo systemctl restart gnome-remote-desktop
systemctl is-active gnome-remote-desktop
最后返回 active。
daemon-reload 用于重新读取 systemd 单元定义，不是设置 RDP 密码所必需的通用步骤。这里执行它是因为现场确有提示；随后重启远程桌面服务，使服务重新加载运行状态。重启可能中断现有远程桌面连接，本次通过 SSH 操作。
此次没有修改 IPv4/IPv6 系统参数，没有安装或切换到 xrdp，没有重建 TLS 证书，也没有增加端口转发规则。
6.3 防火墙核查
sudo ufw status verbose
实际返回 Status: inactive。这是观测到的既有状态，并非本次执行了关闭防火墙操作。UFW 未启用也不等于系统或上游完全没有其他过滤规则；本次能确定的是诊断客户端这条路径能够到达服务。
七、修复后的验证与尚未覆盖的部分
修复后，针对同一地址重新发送 RDP 协商请求，收到：
RDP response: 030000130ed00000000000020b080002000000
Selected security protocol: 2
TLS handshake: TLSv1.3
响应中的协议值 2 对应 HYBRID（基于 TLS 的 CredSSP/NLA 路径），定义见 Microsoft RDP Negotiation Response。本次探测完成 RDP 协商和 TLS 握手，没有继续执行 CredSSP 用户认证。
TLS 探测没有校验证书信任链和主机名，因此它证明的是服务能进行加密握手，不是证书身份已经验证。实际客户端连接时仍应按正常流程核对目标与证书。
| 验证层次 | 结果 |
|---|---|
| IPv4 TCP 连接 | 成功 |
| RDP 初始协商 | 修复前重置，修复后成功响应 |
| TLS 握手 | 成功，TLSv1.3 |
| RDP 用户凭据认证 | 未执行完整客户端验收 |
| Ubuntu 登录与桌面显示 | 未记录完整验收结果 |
Windows 客户端应连接 192.168.18.237，使用新设置的 RDP 用户名和密码。如果随后显示 Ubuntu 系统登录界面，再使用 Ubuntu 系统账户登录。
RDP 入口凭据与 Ubuntu 系统账户凭据属于不同层次。即使为了方便把用户名设成相同，也不意味着两个密码自动同步。不要用“SSH 能登录”推导“RDP 入口凭据一定正确”。
八、下次遇到类似问题的排查顺序
- 用 ss 确认端口和监听进程，不根据 tcp6 标签直接判断 IPv4 不可用。
- 在服务端用 nc -4 测试回环地址。
- 从实际客户端用 nc -4 或 Test-NetConnection 测试目标地址。
- TCP 不通时再检查监听范围、路由与过滤；TCP 通而 RDP 失败时查看协议和服务日志。
- 分清 Remote Login 的系统级作用域与用户级桌面共享作用域。
- 出现 Credentials are not set 时，核对并设置正确作用域的凭据。
- 按需重启服务，再逐层验证 RDP、TLS、认证和最终桌面。
这次故障的关键在于：监听列表描述了套接字，连接测试证明网络是否可用，服务日志解释应用为什么拒绝。 三类证据结合起来，才能避免为了一个 tcp6 标签去修改原本已经正常工作的 IPv4 配置。
浙公网安备 33010602011771号