tcpdump命令
选项 | 示例 | 描述 |
-i | tcpdump -i eth0 | 指定网络接口,any表示所有接口 |
-nn | tcpdump -nn | 不解析IP地址和端口号的名称 |
-c | tcpdump -c 5 | 限制要抓取的网络包的个数 |
-w | tcpdump -w file.pcap | 将抓取的包保存到文件中 |
tcpdump -nn过滤
选项 | 示例 | 描述 |
host、src host、dst host | tcpdump -nn host 192.168.1.100 | 主机过滤 |
port、src port、dst port | tcpdump -nn port 80 | 端口过滤 |
ip、ip6、arp、tcp、udp、icmp | tcpdump -nn tcp | 协议过滤 |
and、or、not | tcpdump -nn host 192.168.1.100 and port 80 | 逻辑表达式 |
tcp[tcpflags] | tcpdump -nn "tcp[tcpflags] & tcp-syn != 0" | 特定状态的TCP包 |
服务器环境准备
使用docker拉起两台容器,容器分别为:
# 拉取Ubuntu Client
docker run --privileged --name ubuntu_client -itd ubuntu
# 拉取Nginx Server
docker run --privileged --name nginx -d nginx
# 查看容器信息
docker inspect ubuntu_client
docker inspect nginx
容器名称 IP
ubuntu_client 172.17.0.3
nginx 172.17.0.2
在Nginx Server端抓取来自ubuntu client的ICMP包
# 进入容器
docker exec -it ubuntu_client /bin/bash
# Ping Nginx Server
ping 172.17.0.2
# 进入容器
docker exec -it nginx /bin/bash
# 执行抓包命令
tcpdump -i eth0 -nn icmp and host 172.17.0.3
在Nginx Server上执行抓包命令以后可以看到以下输出:
上述表述的信息还是比较少的,我们在linux服务器上抓取的包一般会保存为pcap文件,然后导出到本地利用WireShark工具进行分析。
# 执行抓包并写入文件
tcpdump -i eth0 -nn icmp and host 172.17.0.3 -w icmp.pcap
# 在宿主机上执行,将容器内文件拷贝到本地
docker cp nginx:imcp.pcap ~/Downloads/
使用WireShark可以看出每一层的详细信息,如下图:
TCP三次握手流程我们已经详细讲述过,但现实往往不是圆满的,总会有这样那样的问题,在TCP握手的过程中每一个环节都有可能出现问题:
当然,TCP可以保证丢包重传,但是重传几次,经过多长时间重传、重传次数可不可以设置之前我们也没有太过说明,今天我们通过抓包来看一下上述问题。
TCP的第一次握手SYN包丢失
这里我们在Nginx Server上对防火墙进行一些修改,如下:
# 拒绝所有来自ubuntu_client的数据包
iptables -I INPUT -s 172.17.0.3 -j DROP
在ubuntu_client执行以下命令,如下:
# 执行抓包并写入文件
tcpdump -i eth0 -nn tcp and host 172.17.0.2 and port 80 -w http.pcap
# 另开一个窗口,执行curl请求nginx
date;curl http://172.17.0.2;date
从上图中可以看出,在经过两分多钟以后,curl返回了超时错误。
再通过我们对抓的包进行分析:
Linux第一次握手的重传次数由谁决定?
cat /proc/sys/net/ipv4/tcp_syn_retries
由内核参数tcp_syn_retries决定,从上图可以看出,我们这里的默认值是6。
读者可以将上述参数改为2,然后你会发现很快就会超时。
通过以上可以得出关于第一次握手的结论:
TCP的第二次握手SYN+ACK包丢失
在服务器上还原我们上边添加的拒绝规则,保证服务端可以正常的接收到客户端的数据。
# 删除 INPUT的第一条规则
iptables -D INPUT 1
在客户端上配置防火墙规则,拒绝掉Nginx Server的包,如下:
# 拒绝来自Nginx Server的所有数据包
iptables -I INPUT -s 172.17.0.2 -j DROP
# 执行抓包并写入文件
tcpdump -i eth0 -nn tcp and host 172.17.0.2 and port 80 -w http.pcap
# 另开一个窗口,执行curl请求nginx
date;curl http://172.17.0.2;date
从上图可以看出,SYN+ACK包的丢失会引起以下操作:
为什么我们设置了防火墙依旧可以在客户端抓取包?
这个主要取决于iptables的限制条件:
原因是:
二次握手的包最大重传次数由谁决定?
该最大重传次数由内核参数tcp_synack_retries决定。
# 默认值是5
cat /proc/sys/net/ipv4/tcp_synack_retries
下面我们分别对客户端和服务端做如下修改,:
# 在Nginx Server上执行该命令将重传次数修改为2
echo 2 > /proc/sys/net/ipv4/tcp_synack_retries
# 在Ubuntu Client上执行该命令将SYN重传次数修改为1
echo 1 > /proc/sys/net/ipv4/tcp_syn_retries
通过上图可以看出,客户端的SYN包只重传了1次,服务端的SYN+ACK超时重传了2次。
TCP第三次握手ACK丢包
在开启实验前,大家记得还原一下客户端和服务端的iptables,然后在服务端对iptables做以下修改:
# 屏蔽ubuntu客户端TCP报文中的标志位ACK的数据包
iptables -I INPUT -s 172.17.0.3 -p tcp --tcp-flag ACK ACK -j DROP
在客户端执行以下命令进行抓包:
tcpdump -i eth0 -nn tcp and host 172.17.0.2 and port 80 -w telnet.pcap
# 然后另开启一个窗口,执行telnet指令
telnet 172.17.0.2 80
在客户端和服务端执行以下命令查看TCP连接建立情况:
netstat -lantp
通过上图可以看出,客户端这边的TCP连接建立完成,TCP连接状态处于ESTABLISHED。但服务端由于收不到第三次握手的ACK包,因此一直处于SYN_RECV状态,如下图:
但是Nginx Server端的连接会在一定时间后消失。
我们过一段时间后在telnet窗口再输入123456字符,然后再抓一会包,如下图所示:
从上图中可以看出,由于NginxServer上的tcp_synack_retries参数被设置为2次,上图中我们可以看出SYN+ACK包超时重传了2次,2次以后不再重传,此时服务端的TCP连接就主动中止了,所以处于SYN_RECV状态的连接就消失了。
由于客户端的连接还没中断,我们输入123456发送给服务端,但是服务端已经断开连接,客户端的数据一直在不停的重传(PUSH+ACK报文),那么客户端建立连接后重传的最大次数是由啥控制呢?
由内核参数tcp_retries2控制。
# 执行以下命令,可以看出默认值是15
cat /proc/sys/net/ipv4/tcp_retries2
当你将客户端的tcp_retries2参数修改为2以后,当你再次输入123456字符,你会发现很快telnet客户端就断开,如下图:
假设客户端一直不发送数据,那么连接什么时候断开?
此时需要借助TCP的保活机制,关于保活机制我们已经讲过了,可以私信我获取原文,不清楚的可以再回顾一下。
页面更新:2024-04-28
本站资料均由网友自行发布提供,仅用于学习交流。如有版权问题,请与我联系,QQ:4156828
© CopyRight 2008-2024 All Rights Reserved. Powered By bs178.com 闽ICP备11008920号-3
闽公网安备35020302034844号