WebRTC系列- turn及stun网络分析法

文章目录

  • 1. TCPDUMP分析法
    • 1.1 简述
    • 1.2 使用
  • 2. WireShark 基本使用
    • 简述
    • 实战

之前的文章有分析各种协议包的组成,那么实际上在使用的时候是不是和分析的一样,这就需要获取到请求的包进行分析;在分析网络协议最好能抓取到数据包,然后看分析数据包是不是和规定的协议一致;
一般的网络数据包分析我们有两个常用的工具:

  • Linux端的一般经常使用tcpdump
  • 其他客户端一般使用WireShark
    当然可以将tcpdump抓取的数据拿到wireShark中分析。

1. TCPDUMP分析法

1.1 简述

TCPdump是Linux端强大的网络抓包分析工具,但是要求使用者对网络协议等要有较高的熟悉度,如果不熟悉,看到的都是满屏的二进制数据,TCPdump在Linux上配合grep的搜索就会有很强大方便的分析能力;需要注意的是,由于需要抓取网卡的数据这里需要sudo root权限;

1.2 使用

使用实例如下:

sudo tcpdump -i en7  src www.xxx.top  -xx -Xs 0

上述命令中的各个参数解析如下:

  • -i : 用来指定要捕获的接口,通常是以太网卡或无线网卡,后面跟网卡名称(比如:这里监听en7网卡的数据包),也可以是 vlan 或其他特殊接口,当然在当前系统上只有一个网络接口,则无需指定。
  • src 指明包的来源,一般可以使用src 或 dst 只抓取源或目的地,后面跟的可以是IP地址也可以使用域名;
  • port 指定要监听的端口,可以是源端口或目的端口,可以是tcp或udp端口;
  • -xx 指被抓取到的包以16进制现实;
  • -Xs 实际上是两个参数 X表示ASCII码的形式显示二进制数据;s 0表示需要抓取整个包,o表示抓取的数量无限制;
  • -w 是指要写入到文件中,后面跟文件名;

上述命令执行后如下:
WebRTC系列- turn及stun网络分析法_第1张图片
mac下抓取网卡后写入文件的方式如下:

sudo tcpdump -i en7  dst  www.test.top  -xx -Xs 0  -w /Users/用户名/desktop/test.cap

抓取一段时间后,结束抓取(control + c)就会在桌面生成一个cap文件,这个文件可以使用wireshake打开,打开效果如下:
WebRTC系列- turn及stun网络分析法_第2张图片

详细的使用介绍超详细的网络抓包神器 tcpdump 使用指南

2. WireShark 基本使用

简述

由于一个网卡的数据可能包含多个协议及很多的源地址和目的地址等, WireShark 提供了基本逻辑运算用于处理数据,常用的如下:

  • 与运算, and 或者使用&&
  • 或。 or或者 ||
  • 非。not 或者 !
    基本判断如下:
    等于 eq 或者 ==
    小于 It 或者<
    大于 gt 或者 >
    。。。
    一般的过滤方式:

实战

按照协议过滤,实例如下:
打开wire shark过滤的方式如下:

注意如果开始没有看到所有的网卡,可以点击图中的的按钮打开:
WebRTC系列- turn及stun网络分析法_第3张图片
打开软件后,在输入行里就可以使用过滤命令了,比如这里要过滤stun 相关的,就可以如图输入:
WebRTC系列- turn及stun网络分析法_第4张图片

这里可以看到目前没有任何请求,我们发起一个请求看下;抓取到的数据如下:
WebRTC系列- turn及stun网络分析法_第5张图片

在任何一条数据上双击就可以打开一个窗口查看详细的数据,比如这里双击第一条request请求;效果如下:
WebRTC系列- turn及stun网络分析法_第6张图片
这里在会话层的数据中可以看到:

  • message Type:是0X0001也就是一个绑定请求消息;
  • message length:消息的长度是0,
  • message cookie: 之前的协议分析文章说过magic cookie是一个4字节(32bit)的固定值0x2112A442,这里可以看到和协议一致。
  • 接着就是transaction ID,这里看到ID是4969464e374f374469655670,
    我们看一下服务的响应消息,如下图:
    WebRTC系列- turn及stun网络分析法_第7张图片
    可以看到transport ID和请求的时候是一值的;详解如下:
  • type: 0x0101 表示请求绑定的响应消息
  • length 是 80长度
  • cookie 是一个固定值
  • ID 与请求时候的ID一致,表示同一次的会话;
  • attributes 包含映射地址等,这里就不做每一条的分析;
    补充: attributes里每一条里的长度消息想加就是上面message length的值;
    之前的文章描述过stun是在turn之上的协议,所以这里抓包包含了turn的协议内容,这里看下allocate:
    WebRTC系列- turn及stun网络分析法_第8张图片
    按照之前的协议分析,第一的request会返回一个错误;这里如下:
    WebRTC系列- turn及stun网络分析法_第9张图片
    可以看到这里响应的消息的transport ID和请求时候的是一样的;接着会再发送一个携带用户信息的绑定请求如下:
    WebRTC系列- turn及stun网络分析法_第10张图片
    接着服务会回一个请求成功的消息如下:
    WebRTC系列- turn及stun网络分析法_第11张图片
    可以看到这次的ID和请求的一致,同时也返回了attributes信息给客户端;

按照同样的方式可以去抓取tcp或udp;

按照地址过滤(例如:ip.src =192.168.0.1 或 ip.dst = 140.4.5.44),实例如下:
WebRTC系列- turn及stun网络分析法_第12张图片
上图中就是过滤后的效果,这里使用了组合,即: 先按是源地址是指定的过滤,然后筛选出stun协议的数据显示
同样可以换成ip.dst == 0.0.0.0 && stun 的组合去获取stun协议的目的地址是这个的数据包;
例如使用下列命令进一步过滤端口数据:

ip.src==192.168.0.1 && stun && udp.dstport == 3478

效果如下:
WebRTC系列- turn及stun网络分析法_第13张图片
可以看到数据少了很多;只剩下从源地址向服务特定端口发送的数据;
掌握上述命令就可以来做网络协议的分析,其他的组合命令,网络上有多的介绍;
本文就介绍到这里;

你可能感兴趣的:(WebRTC进阶,日常开发工具,音视频)