解决Windows系统下VNC Viewer无法连接到远程主机上的VNC Server的问题

本文详细记录了VNC连接问题的排查过程,从网络、防火墙到软件配置逐一检查,最终定位到VNC公钥指纹变化导致的连接失败,并提供了解决方案。

问题如下:

笔记本(IP:10.100.172.194)上装了VNC Viewer,台机(IP:10.100.100.103)上装了VNC Server,原本笔记本连接无线网,可以通过VNC远程连接到办公网的台机的桌面,自从台机重装了系统后,重新安装了VNC Server,就连不上了,连过去的时候报错 The connection was refused by the computer,见下图:

排查问题的过程:

       一般VNC连接有问题,最有可能的是服务器端的5900端口没有开放,VNC Server的消息中心里也会提示端口被阻断,可以自行在服务器端防火墙上添加一条入方向的规则,允许访问5900端口,或者对Windows防火墙不太熟悉的话,粗暴一点直接重装VNC Server,安装时自动将服务端口添加例外即可,但这次问题有点不一样,具体排查过程如下:

1、首先一看提示连接被拒绝,网络应该是通了,只是数据包被拒绝了,感觉应该是被防火墙什么的安全策略阻挡了,首先检查了自己主机的防火墙,从来不会在Windows自带的防火墙上配置阻断规则的,只检查了有没有开放VNC Server使用的5900端口,果然已经添加了,因为VNC Server也没报错,而且安装的时候已经添加了例外;然后猜想是不是安全管理员新增了安全策略,阻断了通过无线网络访问办公网的VNC Server的权限,然后发现同事通过无线使用VNC远程桌面是正常的,排除了这个可能。

2、网络没问题,但在笔记本上telnet台机的5900端口,确实不通,在台机上抓访问5900端口的包也没收到,但是netstat查看台机上的5900端口是开启的,于是怀疑可能是软件问题,检查了VNC Server的授权正常,设置也没什么问题,服务器的信息中心也没报错,不管了,果断使用重装大法,重装了笔记本的VNC Viewer和台机的VNC Server,发现还是没什么卵用。

3、接着是一波关键测试,排除一下软件的问题,用我笔记本的VNC viewer连接同事台机上的VNC Server,发现可以连接,说明笔记本的VNC Viewer没问题;用同事笔记本的VNC Viewer连接我主机上的VNC Server,发现也可以连接,说明我主机上VNC Server也么有问题。

WTF?是时候冷静下来思考一波了。。。

那么问题就回到这个关键的节点:重装台机系统,这个前后发生了什么?

终于找到了忽略的关键:VNC客户端首次与VNC服务器建立连接时会保存服务器发来的公钥指纹,之后与同一台服务器(这个同一台是用IP地址来标识的)建立连接时,就不会重新接收同一个服务器的公钥指纹了,默认使用已保存的指纹进行验证。

重装之前,笔记本使用VNC Viewer连接过台机,就保存了那个时候台机VNC Server发来的指纹。

然后台机重装系统后,也重装了VNC Server,其公钥指纹也发生了变化。

但是客户端还是默认使用旧的指纹去与跟服务器握手,然额服务器已经不认识它了,就说你是谁啊,反手就是一瓜子。

另一方面客户端保存的服务器公钥指纹是写在注册表里的,所以后来即便重装了客户端的VNC Viewer,其旧的指纹还是在,所以它还是屡教不改,用旧的信物去握手,又被踢回来了。

所以解决方法就来了:

1、打开笔记本上的注册表,Win+R打开运行框,输入regedit打开注册表编辑器,找到VNC Viewer保存服务器指纹的表项:

计算机\HKEY_CURRENT_USER\Software\RealVNC\vncviewer\KnownHosts。(这个是网上搜的)

2、然后将已保存的VNC Server服务器(这里即台机10.100.100.103)的两个旧的指纹数据右键删除即可。

3、删除之后需要重启笔记本,修改的注册表才会生效。

4、重启之后,世界和平~

接收保存新的公钥指纹,输入VNC Server的验证密码,成功连接远程桌面。

        这个问题已经有好几周了,开始搞了一下没搞好,后来没怎么用,也没去解决,今天下决心排查了一下,总算解决了,感觉神清气爽,还是要冷静下来,慢慢分析才行~

### 解决方案概述 当遇到 `connection refused` 的问题时,可能的原因多种多样,包括但不限于服务器未运行、防火墙阻止连接请求、服务端口配置错误等。以下是针对该问题的具体分析和解决方案。 --- #### 1. **检查目标主机的服务状态** 如果远程服务器上的特定服务(如 SSH 或其他网络服务)未启动,则会触发 `connection refused` 错误。可以通过以下命令验证服务是否正在监听指定端口: ```bash ss -tuln | grep <port> ``` 其中 `<port>` 是尝试连接的目标端口号。如果没有找到对应条目,则说明服务未正常运行或未绑定到相应端口[^1]。 --- #### 2. **确认防火墙设置** 即使服务已启动,也可能因防火墙规则而无法访问。在 Linux 系统中,可以使用以下方法临时禁用防火墙以测试连通性: 对于基于 `iptables` 的系统: ```bash sudo iptables -F ``` 对于现代的 `firewalld` 配置环境: ```bash sudo systemctl stop firewalld ``` 完成上述操作后再次尝试建立连接;若成功则表明原因为防火墙拦截所致[^2]。 --- #### 3. **调整SSH参数优化连接体验** 由于提到从Ubuntu客户端向Fedora服务器发起ssh连接存在延迟现象,在排除基本功能性障碍之后还可以考虑修改部分选项提高效率。例如关闭GSS-API认证机制能够有效减少握手过程中的耗时情况: ```bash ssh -o GSSAPIAuthentication=no user@yourserver ``` 此做法特别适用于那些不依赖Kerberos身份验证场景下的跨平台交互需求。 --- #### 4. **排查本地DNS解析性能瓶颈** 长时间等待主机名解析亦可能导致看似“拒绝”的假象。建议编辑 `/etc/ssh/ssh_config` 文件加入如下内容从而绕过不必要的名称查找环节: ```plaintext Host * AddressFamily inet ConnectTimeout 10 ``` 以上更改旨在强制使用IPv4地址形式的同时限定总的超时期限为十秒钟以内。 --- #### 5. **进一步诊断工具的应用** 假如前述措施均未能奏效,则可借助更专业的手段深入探究根本原因。比如运用tcpdump捕获实时流量数据包以便定位具体哪个阶段出现了异常中断状况: ```bash sudo tcpdump -i any port <target_port> -nn ``` 或者利用telnet直接探测目的IP与端口可达性: ```bash telnet yourserver <port> ``` 一旦发现三次握手失败迹象即可参照相关资料着手修复基础层面存在的缺陷。 --- ### 总结 综上所述,“computer connection refused”这一类报错往往涉及多方面因素共同作用的结果。需依次按照上述路径逐一核查直至锁定确切诱因为止。同时提醒注意平时维护良好习惯譬如定期更新补丁版本以及合理规划网络安全策略等等都是预防此类事件发生的关键所在。 ---
评论 17
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

看星星的小王子

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值