随着互联网技术的不断发展，银行互联网边界网络作为对公众以及互联网合作商户提供服务的重要网络基础设施也在不断演进。在高可用、高性能、高安全管控要求下，银行互联网边界网络架构日益复杂，一旦发生故障，影响大，排查难，由于其结构复杂，个别系统运维人员难以全局了解整体架构，涉及到互联网边界各类问题需要网络运维人员共同研究和讨论分析，这也成为网络运维的难点。本文结合近年来我行互联网服务区域网络运维安全运营的经验，聊聊互联网边界网络故障定位分析的一些思路。
在说分析思路前，有必要先熟悉一下边界网络。大体上边界网络都具备三大功能：
1、互联网线路接入:承载出入向的互联网访问流量。考虑冗余性和运营商互联互通问题和多数据中心部署，多中心多出口多活是各大银行的常规配置，配套需要部署多组DNS设备通过GSLB智能地址解析实现在各互联网出口线路中进行流量调度；
2、DMZ区服务器接入，常见部署WEB或者前置服务器。随着计算、存储和网络技术的发展，通过虚拟化或者容器化部署逐渐成为目前的主流部署方式，形成了多种资源池接入的架构；
3、安全资源接入，承载互联网边界的安全防护能力。安全设备包括防火墙、入侵检测、加解密、WAF应用防火墙等多种安全产品，提供全方位的安全防护能力。多种安全防护设备的接入进一步提高了互联网边界架构的复杂度。
从以上的介绍中可以看到，互联网边界网络犹如一个精密的机器，分层部署环环相扣，在这样一个网络中定位一个问题是难度是极大的。然而，一个实际互联网系统访问异常可能比这个更为复杂：
1、涉及范围广。互联网故障所涉及的网络范围远远不止数据中心运维人员维护的数据中心资源范畴，还包括从用户端到银行互联网边界线路所经过的整个互联网，包括用户侧网络，可能是家庭网络也可能是企业网络，可能是有线网络也可能是无线网络，无线网络还需要区分WIFI网络和移动网络，中间还可能经过多个运营商的广域网网络才能到达网站的边界网络。而真正的问题根因也可能发生在内网服务器。
2、复杂的第三方平台。大型网站常常通过第三方服务来增强边界网络的能力。比如说常见的CDN内容分发网络、运营商DNS解析、云安全防护服务等等。排查第三方的问题通常需要在对专业技术持续学习掌握的同时，持续与第三方保持沟通，建立连接通道。以CDN服务为例，CDN技术使用复杂的域名调度策略，涉及对域名技术的深入理解；CDN运营商在全国甚至世界各地部署缓存节点，实行复杂的缓存和灾备策略，出现问题时双方技术人员需要配合共同分析，由于互相不清楚对方的架构，会增加沟通成本。
3、IPv6/IPv4双栈网络。随着国家IPv6规模部署的推进，大型网站通常使用双栈网络提供互联网服务，由于屏蔽底层网络的变化，用户通常不知道自己使用IPv6还是IPv4访问的网站，排查双栈网络问题，将大大增加排查工作量。
面对复杂的网络环境，很多运维人员面对互联网故障都感觉有点“懵”，感到难以下手，其实只要掌握基本技能，全局了解整体部署架构后查问题犹如破案，不断地获取新证据进行抽丝剥茧，大胆的推测分析，全面的检验求证，就不难找出真相。
证据，指的是事实，尽可能掌握更多的事实，这可以说是查问题最关键的部分，大部分常见问题，都能在现象中发现蛛丝马迹，即使不能一次性定位问题，也能极大地缩小问题分析的范围。但是如果获得一个错误的事实，那么所有的努力都可能走偏，浪费宝贵的生产故障处置时间。
通常面对互联网故障场景，大部分报障外部用户甚至是应用运维人员都无法说清楚全部问题现象。例如网站无法访问的问题中，大部分报障信息可能就是某某网站无法访问或者白屏。其实浏览器的报错内容至关重要，通常浏览器会直接告知访问不通的原因，如域名无法解析、IP地址不可达、证书错误、403禁止访问、面找不到、500服务器内部错误。图2这个浏览器返回页面显示，访问的域名为无效域名，直接可以定位为用户侧误操作问题。如果是403、404、500等这些HTTP错误码，则可以判断网络层无异常，用户可以访问到服务器，此问题发生在应用层，需要在服务器侧做进一步分析，重点落在参与四七层应用层处理设备上，如代理模式的负载均衡、安全设备、服务器等。反之，若系统应用报警日志不友好，使用某个默认错误页面且无对应ERROR代码供分析比对，运维人员将会消耗大量时间用于开发人员沟通。
事件发生时，通常决策者对了解故障应用系统业务影响范围的迫切度会高于了解故障原因本身，是个别、局部还是全局问题，影响到整个事件的范围判断以及资源协调组织。一般从两方面去了解影响范围，一是从用户角度，通过报障信息的数量和分布情况可以比较直接的了解影响范围；二是从网站监控方面，查看是否存在应用、系统、网络、安全等方面的异常告警，确认流量、交易量、可用性等关键指标同比的变化量。
对于分析者来说这一步可以进一步判断排查的范围，如果是个别问题，基本可以确认是用户侧问题，全局问题通常是CDN或在数据中心服务侧问题，局部问题则需要进一步寻找发生问题的用户的共性，如同一个运营商、同一个地理位置、同一种浏览器、同一种品牌的手机等等。
开始分析前，需要准备必要的信息，包括用户侧地址、用户上网环境、故障发生时间、故障频率、关键操作过程、业务流程等。这里面最重要的一项准备工作是准备网络拓扑图。拓扑图可以将抽象的问题具象化，在拓扑图上进行演算，远比空想更有效率。拓扑图通常有两种，一种为物理拓扑图，展示所有网络路径，常用于排查分析网络的关键节点。当第一步通过事实推理出怀疑方向后，就可以把整个路径的可疑点全部圈出，逐一排查；另一种为逻辑拓扑图，常用于分析应用层问题，展示所有四七层节点访问关系，对于后续的分段抓包分析有极大的帮助。即使是对环境很熟悉的老手，也有必要准备一个拓扑图。
对于隐藏较深的棘手问题，就要借助工具。“工欲善其事，必先利其器”，什么情况下要借助工具呢？
1、看指标。指标为生产运行过程中计算出的数据，如速率、丢包率、带宽占用率、延时等等，这些数据无法直接获得，需要通过工具计算；
2、看趋势。故障发生时一定会出现指标异常，看趋势可以明显看出异常发生时间点，以及处置后是否已经恢复；
3、查找关键特征。有些事件有明显的特征，比如某个HTTP错误码，某个交易流水号，某个域名，某个账户等等，通过查找关键特征可以快速定位问题；
4、抓包分析。底层数据包是包含数据链路层到应用层的所有信息，所有问题一定能从数据包中找到答案，但是从海量的底层数据中分析出问题，对分析人员的技术和经验都有较高的要求，另外，对于需要快速处理的事件，抓包分析时间长，效率低，所以抓包分析更适合事后问题根因分析。
有了充分的事实并通过工具观察后，可以形成几个可疑点，疑点可以有多个，但是一定要清晰的列在纸上，然后对每个疑点进行逐一复盘。这里不是说事件处理后对整个事件处置的复盘，而是列出怀疑的点后，要基于这个推论重新对每一个故障现象进行推理，看看这个疑点是否会导致所有现象的出现，如果全部符合，那么就可以基本判定这个推论就是故障的原因。如果有矛盾，那么继续分析下一个最可疑的点，不断重复这个过程。
边界防火墙经常吐出日志报警，并发会话数超过平时十倍，瞬间恢复，查看火墙当前的会话数排名，最高的通信对也只有几百个会话。互联网线路流量无异常，各互联网业务都正常，无业务促销秒杀等活动。DDOS设备、WAF设备等安全设备无告警。负载均衡流量、会话数无异常。
看起来是个很诡异的问题，一切都正常，就是有告警，因为告警时间相当短，登陆上设备的时候已经无法看到现象。但是即使动用探针，对流量数据进行回溯，依然找不到异常的通信对，甚至连客户端数量也没有增长。其实，问题的关键在于防火墙是怎么工作的。防火墙准确的说不能算一个四层设备，没有完整的TCP协议栈，但是它有会话的概念，通常一个通信的五元组完成一次TCP三次握手后我们才认为建成一个会话，但是火墙的会话不同，火墙的会话只有一个目的，让策略允许通过的五元组通信对可以回包。
可能性一：虽然学过网络的人都知道UDP是无连接的协议，但是在防火墙上，UDP也是有会线秒超时），为了保证UDP请求的回包可以通过火墙。常见的UDP协议，主要就是DNS，某些客户端短时间发起大量域名的查询请求，导致火墙会话数短时间升高，常见DNS FLood攻击。
可能性二：大量的SYN包扫描，由于TCP三次握手需要来回三次交互，所以第一个SYN包就可以在网络防火墙上生成会话，如果大量的SYN包扫描，就有可能在火墙上短时间内产生大量的半开连接会话。
基于这个推论重新复盘一下所有的现象，看看是否有矛盾的地方。不管是SYN包还是DNS包都很小，大量的访问也无法引起流量的变化，同时对其他业务也不会造成影响，但是DDOS防护设备为什么没有告警呢？DDOS告警取决于策略阈值，单个客户IP的请求频率和单个服务器IP的请求频率，如果都未到达阈值，或者持续时间极短，则可能无法触发告警。事实证明这两种情况都有可能造成火墙会话数高的告警。
建立DNS请求量和SYN包请求量视图，查看故障发生时曲线是否有异常升高，针对DNS FLood行为，可以增加单个IP发起DNS请求的域名数量统计指标，对于扫描行为，可以增加单个IP访问“目标地址+端口”的数量统计指标，都可以快速定位到异常客户端，提交给安全运营或运维安全人员跟踪处置。
现象：远程银行中心接到少量用户投诉，个别手机打开移动APP客户端有出现白屏的情况，这些用户都集中在个别省市，涉及某个运营商，未接到其他省用户投诉，且服务侧各项监控指标无明显异常。
这是一个典型的“局部问题”，在某市安排当地具有相同运营商号段的科技人员使用手机卡流量上网协助进行测试，发现复现该问题，但访问行内其他网站及同业APP正常，说明用户本地运营商网络基本正常，域名解析正常。总部数据中心本地人员测试访问正常，说明服务端正常。这时一个重要信息从应用的开发人员处获得，移动APP打开后会先加载一个静态的广告页面，如果广告页面异常，有可能导致访问APP失败的情况。这个静态的页面，是从CDN获取的。
CDN的工作原理是用户通过域名访问网站，CDN的域名服务器根据用户IP所属的地理位置，返回给用户一个离他最近的缓存节点地址，然后用户访问最近的这个缓存节点获取资源。问题原因到这已经呼之欲出了，某省市的这个CDN缓存节点中有服务器可能有故障。
重新复盘一下，CDN某个缓存节点有故障，导致使用该缓存节点的用户都获取不到广告页面，导致APP白屏，而其他地区的用户访问其他缓存节点正常。由于CDN流量不会被源站监控统计，所以指标无法观察到异常。
1、要求CDN运营商紧急隔离当地的缓存节点后业务恢复。2、手机APP增加加载资源超时跳出逃生功能，避免加载不到资源而被卡住。
现象：某公司部分员工反馈员工考勤app无法打开，进一步验证发现，相关员工手机访问公司内其他网站也无法打开，但可以访问其他企业网站，分析源地址同为某一运营商IP，切换地址后恢复。在互联网入口抓包，发现大量的建链请求被服务端RST中断。在WAF前端抓包，发现大量synack应答包被客户端RST中断。
梳理一下现象：1、仅有一个运营商地址有异常；2、只针对本公司的网站；3、WAF前端抓包能看到客户端RST。如果仅从这三个现象看，这百分之百应该是运营商的问题，应尽快找运营商协查。但是在复盘时发现，第4个现象和我们的这个推断并不相符：在互联网入口看，RST是从服务端发出的。第3和第4个现象看起来很矛盾，只有一个解释，中间有设备同时向两边发了RST。
拿出拓扑图重新分析，从互联网出口到内网依次经过接入交换机、接入防火墙、入侵检测设备、负载均衡、加解密设备、WAF设备、WEB服务器。从抓包的情况看，设备应该在互联网出口到WAF之间，交换机和防火墙都没有能力发RST可以排除。负载均衡、SSL设备在连接超时时会同时向两端发送RST断链，但是这些设备发出的RST包TTL值和真正的客户端或者服务端不一样，从抓包中看，TTL值完全符合客户端和服务端发送的特征，所以也可以排除。重新观察拓扑图，拓扑图中接入的安全设备进入我们视野。该安全设备会检测客户端源地址，对黑名单中的IP进行阻断，并同时向客户端及服务端发送RST。这个流程和我们看到的现象完全一致。
互联网边界故障可以说是所有网络故障中最难排查的问题之一，需要对整体架构、技术产品、业务部署等全栈领域知识深入理解和长期运维经验，互联网边界故障分析并没有完全固定的套路，需要日常持之以恒的学习积累和实践总结，将每一次故障处置作为练兵提升的机会，持续开展应急处置和演练，提升科技运营网络队伍的能力。本文对一些常见案例和分析思路进行总结，希望能为后续互联网边界故障分析处置提供一些思路和灵感，后续我们将结合实际运维场景，在实际工作中多总结、多思考，开展网络持续优化，提升工具和自动化处置能力，助力业务健康平稳发展。
