为何远程办公室无法EAP-TLS认证上网?

位于某海滨城市的远程办公室用户都无法连接上网,遇到这样的网络故障你首先会想到什么?

第一步看看认证是否成功。

远程办公室采用的是EAP-TLS认证,只有认证成功了才允许DHCP获得IP地址,所以先去看看Radius Server认证日志。

认证服务器位于上海的数据中心,与远程办公室采用SD-WAN连接。Radius认证日志显示,来自该远程办公室的认证请求被服务器收到,服务器也进行了双向消息交互。但认证最后都以Timeout失败告终。始终没有收到客户端的数字证书。

作为对比,其它城市的远程办公室上网没有问题。而且从日志里也清晰地看到收到来自客户端的数字证书。

为何会有这样的差别?
经过检查发现,用户的数字证书通常在1680字节左右。有扎实计算机网络基础的同学,一下子会想到可能是MTU造成的,导致尺寸小的报文可以双向交互,但是超出了MTU的报文就被卡住了。由于数字证恰好属于比较大的报文,所以不幸被网络丢弃了。

在远程办公室抓包发现,携带用户数字证书的报文确实被IP层分片了,一共两个分片。最后从SD-WAN路由器的出口流出的两个分片,一个1500字节,一个300多字节,且DFFlag =0。

由于互联网的标准MTU = 1500字节,所以这两个分片应该都会抵达Radius Server。退一步讲,即使在互联网上遭遇更小MTU链路的情况下,比如MTU =1400,由于DF=0,那么也应该将1500字节的那个分片分成两个分片。那么将会有三个IP分片抵达终点,然后由IP层将三个分片重组成一个完整的IP报文,IP层剥离IP头、UDP剥离UDP头,将剩余的报文提交给RadiusServer。

照这样分析,为何Radius Server没有收到客户端的证书?

是不是因为链路有一定程度的丢包,导致三个分片任意一个被丢弃,即使其它两个分片到达了终点,也无法重组为一个完整的IP报文,从而被IP层丢弃?

在排错的初期确实有这样的怀疑,但是为何几十个客户端都无法成功,不符合概率论啊,毕竟网络的平均丢包率在1%左右。

以上都是惯性思维,没有分清什么是事实,什么是猜测。Radius Server没有收到数字证书是事实,SD-WAN路由器出口看到的报文分片也是事实,其它的统统是猜测。事实是排错过程中唯一可以信赖的依据,而猜测有时会延缓我们发现问题的Root Cause。

接下来自然需要验证SD-WAN链路可以提供的有效MTU,这个很好验证,只要使用Ping 工具就可以获得。得到以下事实:

SD-WAN出口流出的IP报文最大只能为1450字节,一旦超出这个大小,无论DF=0还是1,都会被SD-WAN途径的互联网给丢弃。

发现这个事实之后,将SD-WAN路由器的出接口(Internet Facing)的MTU从1500字节修改为1450字节,问题立马得到了修复。

疑问来了,为何同样的网络,使用另外一家无线供应商A司的产品却没有认证失败的问题,A司的产品同样要将客户端的证书运到上海数据中心的认证服务器上认证,这又是为什么呢?以下内容仅供会员阅读。

如何加入会员?
原价300元/人/年,优惠价200元/人/年,仅限今日(2021.4.12)有效。公众号后台回复“200”获取报名链接。

来源:车小胖谈网络,本文观点不代表自营销立场,网址:https://www.zyxiao.com/p/126581

发表评论

登录后才能评论
侵权联系 投诉举报
返回顶部