STUN client初试 (续)


在完成了最基本STUN客户端功能(发送Binding request,接收Binding response)之后,做了一些测试.
之前一直纠结在 端口号为何 返回的 与其它软件的返回结果 有出入. 当中.
于是疑心四起,在怀疑了NAT修改,字节顺序 之后,不停地调试....
然后发现我用0x1111去& 某个值, 而事实是 ,我应该用 0xffff . ( 囧0z)
但之后所做的种种测试,让我 决定再写一篇 用来备忘 STUN协议应该注意的很多重要细节。
同时也希望能帮助更多 还没接触过该协议的人,我相信我的这些记录能帮助他们少走弯路.
首先说说我为什么怀疑NAT修改, 这就引出了一个替代RFC3489 的STUN协议 : rfc5389.
rfc5389 在第一页就以Session Traversal Utilities for NAT的缩写 重名名了 老的RFC3489 STUN 缩写,
老实说我严重怀疑这篇的起草人在凑名字 -- 他们希望 rfc5389代替RFC3489 所有东西.包括 STUN 缩写.
呵呵,当然是开玩笑.其实rfc5389 之所以从新定义STUN 缩写,主要是STUN 不再是p2p的完全解决方案。
正如描述:
 
而rfc5389 中描述的所谓的magic cookie (rfc3489bis-03中被加入)还有 XOR-MAPPED-ADDRESS Attribute(rfc3489bis-01中被加入)
即为了防止 某些手段较狠的NAT 对MAPPED-ADDRESS 的修改 .它的主要机制:
 
(通过把MAPPED-ADDRESS 用异或运算 的 映射方式 映射为XOR-MAPPED-ADDRESS 从而逃过 网关修改)
(注意异或运算是其自身的逆运算,所以我们再异或一下就可以得出真实的MAPPED-ADDRESS了)


早在rfc3489bis-01中就用这样一句话作为引入XOR-MAPPED-ADDRESS 的解释:
 
幸亏我 调试半天 得到的原因不是 NAT对报文的修改.不过我们 应该知道 存在这样的情况。 那么在 MAPPED-ADDRESS不对时
有助于注意到这个极有可能被忽略的原因.(所以塞翁失马焉只祸福 , 感谢我的0x1111)

其次,我不得不提醒所有刚开始着手客户端协议的童鞋:网上铺天盖地的STUN 名字其实 背后隐藏着 是 它有很多版本的事实 .
以后提到STUN 我们需要说明它所指的版本.
要命的是,现在网上能找到的很多公开STUN服务器地址,他们apply的STUN版本还很多是rfc3489bis-02 版的,
也就是说,rfc5389 早在08年就出来,‘问世’ 有3 年了 ,很多STUN服务器 还使用 2005 年的rfc3489bis-02.(或许这就是对标准的反应速度)
更要命的是,
期间的每一版本(我并没有全看 且 看得不很仔细) 发生了很多重要变化
(从整个名字的更换 和 对其本质定义彻头彻尾的改变就可以见一斑) ,有些重要的定义 刚出现
就被下一版所否定(如我后面将举到的 rfc3489bis-02中对0x8020的定义),而客户端需要理解attribute. 这就造成了很多对该属性的无所适从.
甚至怀疑返回的结果,和STUN服务器的正确性. 所以明白一些重要的细节 及 他们在各个版本中的区别 对于STUN 客户端开发者来说,个人认为十分重要.
现在就举rfc3489bis-01中的例子,我对8个公开STUN服务器做了测试:
 
可以发现只有 stun.iptel.org 和 stun.ideasip.com 没有返回 0x8020的attribute ,可以看出他们仍用着rfc3489bis-02的协议。
怎么证明呢??
因为仅仅独有rfc3489bis-02 对其定义了. 而且定义还出现失误,因为rfc3489bis-03立即对其进行了纠正:
 
所以我们要了解 这些服务器所使用的协议,就算他们没有用最新的协议.也可以推断出他遵循的版本.
从而对其返回结果作出正确的反应.
此外stun.iptel.org 和 stun.ideasip.com 返回的结果 中带有0x5 和 0x4这两个attribute .
所以也可以推断出他们使用的 版本 在rfc3489bis-04 之前 .因为rfc3489bis-04中描述与上一版的区别:
 
好,下一步就准备 对 MAPPED-ADDRESS 进行一些打洞试验了 ,我真的渴望取得成功的那一天 .
也希望这些细节对 他人有用, 这样就真没白写了.
By ga6840

 

阅读更多
想对作者说点什么? 我来说一句

没有更多推荐了,返回首页