域名解析错误页面无法显示_网络原来如此之互联网边界问题分析漫谈

介绍

随着互联网技术的不断发展，银行互联网边界网络也正在发展成为为公众和互联网合作商户提供服务的重要网络基础设施。 在高可用性、高性能、高安全控制的要求下，银行互联网边界网络架构变得越来越复杂。 一旦发生故障，影响很大，且难以排除故障。 由于其结构复杂，单个系统运维人员很难完全理解其整体架构，其中涉及到互联网。 各种边界问题需要网络运维人员共同研究、讨论和分析，这也成为网络运维的难点。 本文结合我行近年来互联网服务区域网运营安全运行的经验，谈谈互联网边界网络故障定位分析的一些思路。

1. 互联网边界故障分析与处理的挑战

在讲分析思路之前，有必要先熟悉一下边界网络。 一般来说，边界网络具有三大功能：

1、互联网线路接入：承载入站和出站的互联网访问流量。 考虑到冗余、运营商互联问题以及多数据中心部署，多中心、多出口、多主是各大银行的常见配置。 为此，需要在每条出口线路上部署多套DNS设备，实现GSLB智能地址解析。 交通调度；

2. DMZ区服务器访问，一般部署WEB或前端服务器。 随着计算、存储和网络技术的发展，虚拟化或容器化部署逐渐成为当前主流的部署方式，形成了访问多个资源池的架构；

3、安全资源接入，承载互联网边界的安全防护能力。 安全设备包括防火墙、入侵检测、加解密、WAF应用防火墙等安全产品，提供全面的安全防护能力。 多种安全防护设备的接入进一步增加了互联网边界架构的复杂性。

图1

从上面的介绍可以看出，互联网边界网络就像一台精密的机器，层层部署环环相扣。 在这样的网络中定位问题是极其困难的。 然而，实际的互联网系统访问异常可能比这更复杂：

1、覆盖面广。 互联网故障涉及的网络范围远远超出了数据中心运维人员维护的数据中心资源范围。 还包括从用户端到银行互联网边界线的整个互联网，包括用户侧网络，可能是家庭网络，也可能是家庭网络。 企业网络可以是有线网络或无线网络。 无线网络还需要区分WIFI网络和移动网络，还可能经过多个运营商的WAN网络到达网站的边界网络。 问题的真正根源还可能出现在内网服务器上。

2.第三方平台复杂。 大型网站经常使用第三方服务来增强其外围网络的功能。 例如常见的CDN内容分发网络、运营商DNS解析、云安全防护服务等。排查第三方问题通常需要不断学习和掌握专业技术，同时不断与第三方沟通，建立连接渠道。 以CDN服务为例，CDN技术采用复杂的域名调度策略，涉及对域名技术的深入理解； CDN运营商在全国乃至全球部署缓存节点，实施复杂的缓存和容灾策略，出现问题时需要双方技术人员联合分析。 由于彼此不知道对方的结构，沟通成本就会增加。

3. IPv6/IPv4双栈网络。 随着国家大规模IPv6部署的推进，大型网站通常采用双栈网络来提供互联网服务。 由于屏蔽了底层网络的变化，用户常常不知道自己是使用IPv6还是IPv4访问网站。 排查双栈网络问题将大大增加排查工作量。 工作量。

2.互联网边界故障分析及解决思路

2.互联网边界故障分析及解决思路

面对复杂的网络环境，很多运维人员在面对上网故障时都感到有些“茫然”，无从下手。 其实，只要掌握了基本技能，了解了整体部署架构，再去排查问题，就像破案一样，不断获取新的证据来剥茧。 ，大胆猜测和分析，全面考察和求证，不难找出真相。

第一步是获得真实、完整的故障现象。

证据是指事实。 尝试掌握尽可能多的事实。 这可以说是排查问题最关键的一环。 对于大多数常见问题，都可以从现象中找到线索。 即使不能一下子定位到问题，也可以极大的改善问题。 缩小问题分析的范围。 但如果获得了错误的事实，所有的努力都可能会误入歧途，浪费宝贵的时间来排除生产故障。

通常在面对互联网故障场景时，大多数报告故障的外部用户甚至应用运维人员都无法解释所有问题症状。 例如，当某个网站无法访问时，上报的故障信息大部分可能是某个网站无法访问或者白屏。 事实上，浏览器的错误内容非常重要。 通常浏览器会直接告知访问被阻止的原因，例如域名无法解析、IP地址不可达、证书错误、403访问禁止、404页面未找到、500内部服务器错误等。 图2浏览器返回页面显示访问的域名为无效域名，可以直接识别为用户端误操作问题。 如果是403、404、500等HTTP错误码，则可以判断网络层没有异常，用户可以访问服务器。 该问题出现在应用层，需要在服务器端进一步分析。 重点是参与第四层和第七层应用。 层处理设备，如代理模式负载均衡、安全设备、服务器等。另一方面，如果系统应用报警日志不友好，使用默认的错误页面，没有对应的ERROR代码进行分析比较、运维人员会花费大量时间与开发人员沟通。

图2

第二步是确定影响范围。

当事件发生时，决策者通常更渴望了解故障应用系统对业务影响的范围，而不是了解故障本身的原因。 无论是个体、局部还是全局问题，都会影响整个事件的范围判断和资源协调组织。 一般来说，我们可以从两个方面来了解影响范围。 首先，从用户角度，通过故障上报信息的数量和分布，可以更直接地了解影响范围； 其次，从网站监控的角度，可以检查应用、系统、网络、安全等是否存在异常报警，确认流量、交易量、可用性等关键指标同比变化情况。

对于分析师来说，这一步可以进一步确定调查范围。 如果是个别问题，基本可以确认是用户端问题。 全局问题通常是CDN或者数据中心服务端的问题。 本地问题需要进一步查找出现问题的用户。 共性，如同一运营商、同一地理位置、同一浏览器、同一品牌手机等。

第三步是准备必要的信息。

在开始分析之前，需要准备必要的信息，包括用户侧地址、用户上网环境、故障发生时间、故障频率、关键操作流程、业务流程等。这里最重要的准备工作是准备网络拓扑图表。 拓扑图可以把抽象问题具体化，在拓扑图上进行计算远比幻想高效。 通常有两种类型的拓扑图。 一是物理拓扑图，显示所有网络路径，常用于排查和分析网络关键节点。 当第一步从事实推导出可疑方向时，可以圈出整条路径上的所有可疑点，一一排查； 另一种是逻辑拓扑图，常用于分析应用层问题，显示所有第四层、第七层节点的访问关系。 ，对于后续的分段抓包分析有很大的帮助。 即使对于熟悉环境的老手来说，准备一张拓扑图也是很有必要的。

第四步是工具分析。

对于隐藏很深、很困难的问题，就需要使用工具。 “工欲善其事，必先利其器”。 什么情况下需要使用工具？

1、看指标。 指标是生产运营过程中计算出来的数据，比如速度、丢包率、带宽占用、时延等，这些数据无法直接获取，需要通过工具进行计算；

2.看趋势。 当出现故障时，肯定会出现指标异常。 查看趋势，可以清楚地看到异常发生的时间以及处理后是否已恢复；

3. 找到关键特征。 有些事件具有明显的特征，例如某个HTTP错误码、某个交易序列号、某个域名、某个账户等，通过寻找关键特征，可以快速定位问题；

4.抓包分析。 底层数据包包含从数据链路层到应用层的所有信息。 所有的问题都可以从数据包中找到答案。 然而，从大量基础数据中分析问题需要分析师高水平的技能和经验。 要求。 另外，对于需要快速处理的事件，抓包分析耗时较长，效率低下，因此抓包分析更适合事件后根本原因分析。

第五步，列出疑点并进行回顾。

有了足够的事实并通过工具观察后，可以形成几个疑点。 疑点可以有多个，但一定要在卷子上清楚地列出来，然后对每个疑点都一一进行审查。 这并不是在事件处理完毕后对整个事件进行回顾，而是在列出疑点后，我们应该根据这个推论对每一个故障现象进行重新推理，看看这个疑点是否会导致所有现象的发生。 如果都一致的话，那么基本可以确定这个推论就是失败的原因。 如果有矛盾，则继续分析下一个最可疑的点，不断重复这个过程。

3、经典案例分析

案例一：边界防火墙会话数突然超过阈值报警

现象：

边界防火墙经常吐出日志告警，并发会话数超过平时的十倍。 它立即恢复。 查看防火墙当前的会话数排行，最高的通信对也只有几百个会话。 互联网线路流量无异常，所有互联网服务正常，无商家促销、闪购等活动。 没有DDOS设备、WAF设备等安全设备的告警。 负载均衡流量和会话数没有异常。

分析：

这似乎是一个非常奇怪的问题。 一切正常，但有警报。 由于报警时间很短，登录设备时看不到该现象。 然而，即使使用探针回溯流量数据，也找不到异常的通信对，甚至客户端数量也没有增加。 事实上，问题的关键在于防火墙的工作原理。 准确地说，防火墙不能被视为四层设备。 它没有完整的TCP协议栈，但是有会话的概念。 通常，我们只考虑通信五元组完成TCP三次握手后才建立会话。 然而，防火墙的会话是不同的。 ，防火墙会话只有一个目的，使得策略允许的5元组通信对能够返回数据包。

可能性一：虽然学过网络的人都知道UDP是无连接协议，但是在防火墙上，UDP也是有会话（30秒超时）来保证UDP请求的返回包能够通过防火墙的。 常见的UDP协议主要是DNS。 部分客户端短时间内发起大量域名查询请求，导致防火墙会话数短时间内增加。 DNS 洪水攻击很常见。

可能性二：扫描大量SYN包。 由于TCP三向握手需要3次交互，因此第一个SYN数据包可以在网络防火墙上生成会话。 如果扫描到大量SYN报文，则有可能会话会在短时间内被防火墙阻塞。 产生大量半开连接会话。

根据这个推论，再次审视一切现象，看看是否有矛盾之处。 SYN报文和DNS报文都非常小，大量访问不会造成流量变化，也不会影响其他服务。 但为什么DDOS防护设备不报警呢？ DDOS告警取决于策略阈值、单个客户IP的请求频率、单个服务器IP的请求频率。 如果未达到阈值，或者持续时间极短，则可能不会触发警报。 事实证明，这两种情况都可能引起防火墙会话数过高的告警。

解决：

建立DNS请求量和SYN报文请求量视图，检查故障发生时曲线是否异常增大。 针对DNS Flood行为，您可以增加单个IP发起DNS请求的域名数量统计指标。 对于扫描行为，您可以增加单个IP的访问次数。 “目标地址+端口”的量化统计指标可以快速定位异常客户端，并提交给安全运营或运维安全人员进行跟踪处置。

DNS网络域名解析请求跟踪图：

图3

SYN和区分网络跟踪图：

图4

案例二：部分手机用户客户端APP某个页面白屏

现象：远程银行中心收到少量用户投诉。 部分手机打开手机APP客户端时出现白屏。 这些用户集中在某些省市，涉及某个运营商。 未收到外省用户投诉，服务端各项监测指标未见明显异常。

分析：

这是一个典型的“局部问题”。 某城市安排当地同运营商号码的技术人员使用手机卡流量上网协助测试。 发现问题重现，但访问业内其他网站和同行APP均正常，说明用户当地运营商网络基本正常，域名解析也正常。 本地人员在总部数据中心测试访问正常，说明服务器正常。 这时，从应用程序的开发者那里获得了一条重要的信息。 手机APP打开后，首先会加载一个静态广告页面。 如果广告页面异常，可能会导致APP访问失败。 该静态页面是从CDN获取的。

CDN的工作原理是用户通过域名访问网站。 CDN的域名服务器根据用户IP的地理位置返回距离用户最近的缓存节点地址，然后用户访问最近的缓存节点来获取资源。 问题的原因已经揭晓。 可能是某个省市的CDN缓存节点的服务器出现故障。

再次查看后，发现CDN的某个缓存节点出现故障。 导致使用该缓存节点的用户无法获取广告页面，导致APP白屏。 但其他地区的用户可以正常访问其他缓存节点。 由于CDN流量不受源站监控统计，因此无法观察到指标异常。

优化方案：

1.要求CDN运营商在业务恢复前紧急隔离本地缓存节点。 2、手机APP在加载资源时增加跳出逃生功能，避免因加载资源失败而卡住。

情况3：部分地址无法访问

现象：某公司部分员工反映，员工考勤APP打不开。 进一步核实发现，相关员工通过手机访问公司内部其他网站时无法打开，但可以访问其他公司网站。 经分析，源地址为某运营商IP。 切换地址后，恢复。 在互联网入口抓包，发现大量建链请求被服务器RST中断。 在WAF前端抓包，发现大量响应包被客户端RST中断。

图5

分析：

我们来梳理一下现象： 1、只有一个操作员地址异常； 2、仅适用于我公司网站； 3.WAF前端抓包可以看到客户端RST。 如果只看这三个现象，这应该100%是运营商的问题，应该尽快联系运营商寻求帮助。 然而，在审查过程中，我们发现第四个现象与我们的推断不符：查看互联网门户，RST是从服务器发送的。 第三个和第四个现象看起来很矛盾。 只有一种解释。 中间有一个设备同时向两边发送RST。

拿出拓扑图重新分析一下。 从出口到内网，经过接入交换机、接入防火墙、入侵检测设备、负载均衡、加解密设备、WAF设备、WEB服务器。 从抓包来看，该设备应该位于互联网出口和WAF之间。 交换机和防火墙都没有发送RST的能力，所以可以排除这种情况。 当连接超时时，负载均衡和SSL设备会同时向两端发送RST。 然而，这些设备发送的RST数据包的TTL值与真实客户端或服务器的TTL值不同。 从抓包来看，TTL值与客户端完全一致。 由客户端和服务器发送的特征，因此也可以将其排除。 再看一下拓扑图，拓扑图中连接的安全设备就清晰可见了。 安全设备会检测客户端源地址，屏蔽黑名单中的IP，同时向客户端和服务器发送RST。 这个过程和我们看到的完全一致。

解决：

从黑IP地址列表中删除相关被屏蔽的IP。

4. 总结

互联网边界故障可以说是所有网络故障中最难排查的问题之一。 需要对整体架构、技术产品、业务部署等全栈领域知识有深入的了解和长期的运维经验。 互联网边界故障分析尚未完全修复。 套路需要每天坚持不懈的学习、积累和实践总结。 每次故障处理都应作为培训和改进的机会。 持续开展应急处置和演练，提升技术运营网络队伍能力。 本文总结了一些常见案例和分析思路，希望能为后续互联网边界故障的分析和处理提供一些思路和启发。 未来我们将结合实际运维场景，在实际工作中更多总结和思考，进行持续的网络优化。 完善工具和自动化处理能力，助力业务健康稳定发展。

结尾