一次Linux端口冲突问题排查记录

运维之美@

已于 2024-08-03 11:57:21 修改

阅读量283

点赞数 4

分类专栏： Linux 运维浏览器文章标签： linux 运维服务器

于 2024-08-03 11:56:21 首次发布

本文链接：https://blog.csdn.net/m0_37680131/article/details/140888158

版权

运维同时被 3 个专栏收录

29 篇文章 1 订阅

订阅专栏

Linux

11 篇文章 0 订阅

订阅专栏

浏览器

2 篇文章 0 订阅

订阅专栏

更多技术博客，请关注微信公众号：运维之美

一、问题现象

实施同学反馈说我们的服务部署到客户环境后，运行正常，但是后台页面就是无法打开，出现访问白屏问题
在这里插入图片描述

从console报错看是其中一个接口响应存在问题，第一个报错最开始没有关注，后续才发现其实已经指向了问题的根因。

二、问题定位

继续开始刨问题吧，按照一贯的方法，去网关入口查看请求的报错日志，顺便说下，我们的服务都是pod状态运行的，网关其实就是一个apisix作为入口和路由转发。

具体日志如下

"level":"ERROR","file":"route/emv_router/env_router.go[1115],
time:2023/06/31 14:51:00,msg:getRouterCtime
err:Get \ http//127.0.0.1:10086/route/ctime\":
net/http: HTTP/1.x tansport connection broken: 
malformed HTTP response \"SSH-2.0-0pensSH 8.2\"}

其中有一个关键日志"HTTP/1.x tansport connection broken: malformed HTTP response “SSH-2.0-0pensSH 8.2”

从日志上看这是一个http的请求，响应的是一个ssh的版本号,这种发现返回其实在最开始console上已经体现了

猜想：由于项目环境无法远程，此时已经有了基本的猜测，环境是客户提供给我们的，环境基本都是内网，防止通用的22端口受到攻击，做了安全j加固，应该是修改了22端口为10086，和业务端口冲突导致服务调用返回ssh响应

验证

到此时问题就简单了，让客户使用lsof命令检查下10086端口是否有监听就好了

lsof -i:10086返回结果
在这里插入图片描述
果然是ssh端口占用的，那解决方式也简单，将ssh中的10086端口修改重启ssh就好了

下面我们telnet测试下ssh端口，可以看到返回的为ssh的版本号

[root@localhost ~]# telnet  192.168.34.45 22
Connecting to 192.168.34.45:22...
Connection established.
To escape to local shell, press 'Ctrl+Alt+]'.
SSH-2.0-OpenSSH_8.0

对于此类问题，经验丰富的小伙伴可能一眼就看出来问题原因了，但是初次遇到可能会一头懵逼。