【网络】连接服务器失败(错误原因:Connection refused)| error 111: (111) Connection refused 原因分析

服务器拒绝原因:

connect 发起TCP连接请求被拒绝是由于目标服务器上无对应的监听套接字(IP && PORT)。(没有监听、无法创建、监听别的IP\端口……)

有几个可能性:

  1. 服务器没启动或未监听端口(用TCP工具连一下你的服务器,看下服务器是否正常监听端口。如果是Windows开发者也可以使用Windows的CMD命令行telnet测试下,格式是 telnet 地址 端口);
  2. 地址错误;
  3. 端口错误;
  4. 类型错误;
  5. 内存不足;
  6. 被防火墙拦截。

摘自:ConnectionRefusedError: [Errno 111] Connection refused-https://blog.csdn.net/Up2Me1/article/details/105900585

Linux中,通过系统调用(system call) connect 连接指定服务器建立TCP连接。

connect 最常见的失败原因是 Connection refused。

假设服务器IP是192.168.44.148,并且还没有 进程监听端口12500:

此时若有TCP连接请求包到达192.168.44.148,则192.168.44.148的内核将 回复RST包 给客户端。

此时,在客户端一侧看来就是connect连接失败,被服务端拒绝连接。
 

下面内容摘自:https://blog.csdn.net/test1280/article/details/80642847

tcpdump抓取协议包:

[root@localhost ~]# tcpdump tcp port 12500 -i eth0 -s 0 -w jiang.cap
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
^C2 packets captured
2 packets received by filter
0 packets dropped by kernel


wireshark分析jiang.cap:

1)

客户端发起TCP连接建立请求

客户端调用 connect,发起TCP连接建立请求到服务端。

2)

服务端内核回复RST重置包

服务器内核收到要连接本机12500端口的请求,发现并未有对应的监听SOCKET,于是回复RST到客户端。

3)

客户端调用 connect 失败,错误原因:Connection refused

此时即使当前主机有进程监听12500端口,connect依然有可能被拒绝连接

略微修改下服务器代码(不使用地址通配INADDR_ANY):

// if (inet_aton("0.0.0.0", &(server_addr.sin_addr)) != 1)
// if (inet_aton("192.168.44.148", &(server_addr.sin_addr)) != 1)
 if (inet_aton("127.0.0.1", &(server_addr.sin_addr)) != 1)

此时,在服务器上虽然有进程监听12500端口,但是监听套接字的IP地址是127.0.0.1(在127.0.0.1地址上监听12500端口)。

如果我们在客户端主机(192.168.44.144)上向【192.168.44.148:12500】发起TCP连接请求,将会被拒绝:

socket connect error=111(Connection refused)!!!

被拒绝原因是在148服务器上不存在监听套接字【192.168.44.148:12500】,只有监听套接字【127.0.0.1:12500】。

总结:

connect 发起TCP连接请求被拒绝是由于目标服务器上无对应的监听套接字(IP && PORT)。

在哪个IP上监听哪个端口,^_^。

TCP中的RST标志(Reset)详解

转自https://blog.csdn.net/a_tu_/article/details/80389878

在谈RST攻击前,必须先了解TCP:如何通过三次握手建立TCP连接、四次握手怎样把全双工的连接关闭掉、滑动窗口是怎么传输数据的、TCP的flag标志位里RST在哪些情况下出现。下面我会画一些尽量简化的图来表达清楚上述几点,之后再了解下RST攻击是怎么回事。

1、TCP是什么?

TCP是在IP网络层之上的传输层协议,用于提供port到port面向连接的可靠的字节流传输。我来用土语解释下上面的几个关键字:

port到port:IP层只管数据包从一个IP到另一个IP的传输,IP层之上的TCP层加上端口后,就是面向进程了,每个port都可以对应到用户进程。

可靠:TCP会负责维护实际上子虚乌有的连接概念,包括收包后的确认包、丢包后的重发等来保证可靠性。由于带宽和不同机器处理能力的不同,TCP要能控制流量。

字节流:TCP会把应用进程传来的字节流数据切割成许多个数据包,在网络上发送。IP包是会失去顺序或者产生重复的,TCP协议要能还原到字节流本来面目

从上面我用PowerPoint画的TCP协议图可以看到,标志位共有六个,其中RST位就在TCP异常时出现,也是我这篇文章重点关注的地方。

2、通过三次握手建立连接

下面我通过A向B建立TCP连接来说明三次握手怎么完成的。

为了能够说清楚下面的RST攻击,需要结合上图说说:SYN标志位、序号、滑动窗口大小。

建立连接的请求中,标志位SYN都要置为1,在这种请求中会告知MSS段大小,就是本机希望接收TCP包的最大大小。

发送的数据TCP包都有一个序号。它是这么得来的:最初发送SYN时,有一个初始序号,根据RFC的定义,各个操作系统的实现都是与系统时间相关的。之后,序号的值会不断的增加,比如原来的序号是100,如果这个TCP包的数据有10个字节,那么下次的TCP包序号会变成110。

滑动窗口用于加速传输,比如发了一个seq=100的包,理应收到这个包的确认ack=101后再继续发下一个包,但有了滑动窗口,只要新包的seq与没有得到确认的最小seq之差小于滑动窗口大小,就可以继续发。

3、滑动窗口

滑动窗口毫无疑问是用来加速数据传输的。TCP要保证“可靠”,就需要对一个数据包进行ack确认表示接收端收到。有了滑动窗口,接收端就可以等收到许多包后只发一个ack包,确认之前已经收到过的多个数据包。有了滑动窗口,发送端在发送完一个数据包后不用等待它的ack,在滑动窗口大小内可以继续发送其他数据包。举个例子来看吧。

大家看上图,标志位为.表示所有的flag都为0。标志位P表示flag为PSH的TCP包,用于快速传输数据。

前三个包是三次握手,客户端表示自己的滑动窗口大小是65535(我的XP机器),服务器端表示滑动窗口是5840(屏幕宽了,没截出来)。从第四个包开始,客户端向服务器发送PSH包,数据长度是520字节,服务器发了ack确认包。注意此时win窗口大小发生了改变哈。以此类推。

倒数第二、三包,服务器在滑动窗口内连续向客户端发包,客户端发送的ack 124同时确认了之前的两个包。这就是滑动窗口的功能了。

如果谈到TCP攻击就需要注意,TCP的各种实现中,在滑动窗口之外的seq会被扔掉!下面会讲这个问题。

4、四次挥手的正常TCP连接关闭

先画张简单的正常关闭连接状态变迁图。

FIN标志位也看到了,它用来表示正常关闭连接。图的左边是主动关闭连接方,右边是被动关闭连接方,用netstat命令可以看到标出的连接状态。

FIN是正常关闭,它会根据缓冲区的顺序来发的,就是说缓冲区FIN之前的包都发出去后再发FIN包,这与RST不同。

5、RST标志位

RST表示复位,用来异常的关闭连接,在TCP的设计中它是不可或缺的。就像上面说的一样,发送RST包关闭连接时,不必等缓冲区的包都发出去(不像上面的FIN包),直接就丢弃缓存区的包发送RST包。而接收端收到RST包后,也不必发送ACK包来确认。

TCP处理程序会在自己认为的异常时刻发送RST包。例如,A向B发起连接,但B之上并未监听相应的端口,这时B操作系统上的TCP处理程序会发RST包。

又比如,AB正常建立连接了,正在通讯时,A向B发送了FIN包要求关连接,B发送ACK后,网断了,A通过若干原因放弃了这个连接(例如进程重启)。网通了后,B又开始发数据包,A收到后表示压力很大 很懵逼 ,不知道这野连接哪来的,就发了个RST包强制把连接关了,B收到后会出现connect reset by peer错误。

6、RST攻击

A和服务器B之间建立了TCP连接,此时C伪造了一个TCP包发给B,使B异常的断开了与A之间的TCP连接,就是RST攻击了。实际上从上面RST标志位的功能已经可以看出这种攻击如何达到效果了。

那么伪造什么样的TCP包可以达成目的呢?我们至顶向下的看。

假定C伪装成A发过去的包,这个包如果是RST包的话,毫无疑问,B将会丢弃与A的缓冲区上所有数据,强制关掉连接。

如果发过去的包是SYN包,那么,B会表示A已经发疯了(与OS的实现有关),正常连接时又来建新连接,B主动向A发个RST包,并在自己这端强制关掉连接。

这两种方式都能够达到复位攻击的效果。似乎挺恐怖,然而关键是,如何能伪造成A发给B的包呢?这里有两个关键因素,源端口和序列号。

一个TCP连接都是四元组,由源IP、源端口、目标IP、目标端口唯一确定一个连接。所以,如果C要伪造A发给B的包,要在上面提到的IP头和TCP头,把源IP、源端口、目标IP、目标端口都填对。这里B作为服务器,IP和端口是公开的,A是我们要下手的目标,IP当然知道,但A的源端口就不清楚了,因为这可能是A随机生成的。当然,如果能够对常见的OS如windows和linux找出生成source port规律的话,还是可以搞定的。

序列号问题是与滑动窗口对应的,伪造的TCP包里需要填序列号,如果序列号的值不在A之前向B发送时B的滑动窗口内,B是会主动丢弃的。所以我们要找到能落到当时的AB间滑动窗口的序列号。这个可以暴力解决,因为一个sequence长度是32位,取值范围0-4294967296,如果窗口大小像上图中我抓到的windows下的65535的话,只需要相除,就知道最多只需要发65537(4294967296/65535=65537)个包就能有一个序列号落到滑动窗口内。RST包是很小的,IP头+TCP头也才40字节,算算我们的带宽就知道这实在只需要几秒钟就能搞定。

那么,序列号不是问题,源端口会麻烦点,如果各个操作系统不能完全随机的生成源端口,或者黑客们能通过其他方式获取到source port,RST攻击易如反掌,后果很严重。

posted on 2022-10-04 01:22  bdy  阅读(2958)  评论(0编辑  收藏  举报

导航