Files

2025-09-14 22:27:11 +00:00

25 KiB

Raw Permalink Blame History

【E21现场】YouTube deny失败

ID	Creation Date	Assignee	Status
OMPUB-641	2022-09-23T15:21:11.000+0800	杨威	已关闭

目前现在版本22.07情况下，对YouTube的deny失败。liuxueli commented on 2022-09-26T09:45:50.811+0800:

测试时间段已排查内容： ** 交换版均为pass状态 ** 没有相应的DDOS Bypass ** 没有丢包 ** 策略没有问题 ** 与单向流无关 ** youtube在E境内存在节点，但不是IGW阻断无效果的真正原因 *** !image-2022-09-26-09-45-16-214.png!

liuxueli commented on 2022-09-29T15:58:06.746+0800:

暂时关闭BOL-IGW NPB 1/2/5的overload protection功能，观察丢包情况。

yangwei commented on 2022-10-08T19:07:50.103+0800:

更新10.5-10.7排查记录

10.5 UTC+8 18:00-22:00 ** 现象描述 *** 在IGW下发YouTube deny策略，拨测（固定公网IP）有效率低于10% *** 在PE下发相同策略，拨测有效率100% *** PE相当于省口，IGW相当于国际口，流量理论上先过PE，再上行至IGW至国际互联网 ** 现场拨测 *** {}生效策略{}：IGW deny Client IP（196.188.136.150）+YouTube *** 使用现场终端，分别用浏览器直接访问www.youtube.com和命令行执行curl [https://www.youtube.com|https://www.youtube.com/] ，多次测试后，有效率仍然低于10% *** 通过观察客户端捕获的数据包，观察到 **** 问题1：deny有效的会话，实际生效的动作为drop，未收到rst包 **** 都有用172.217.169.238这个IP（归属地美国，所属公司为Google）使用SSL SNI请求www.youtube.com的行为，相同二元组不同四元组的情况下，同时存在有效和失效的情况 *** 缩小测试范围 **** 测试终端上修改hosts，将www.youtube.com固定解析为172.217.169.23 **** 使用curl复测，仍然存在有效率低的现象，但是并不为0 *** 界面查询会话日志 **** 查询条件为172.217.169.23-196.188.136.150二元组 **** 二元组会话日志同时存在于Old Airpod PE、DIR IGW和MW IGW三个站点 ***** PE的会话日志数量与拨测数量相符 ***** 两个IGW站点的会话数量，与拨测数量不相符 *** 策略改为在PE生效，有效率100% *** 通过在DIR IGW的NPB捕包，配合拨测操作，未捕获到deny无效的会话 *** 推测1：PE流量完整，IGW流量不完整，即使相同二元组，也存在部分会话流量缺失的情况 ** 当天结论 *** 怀疑IGW接入流量不完整，建议用户如果想使用deny功能，优先在PE生效。不足之处在于丢流量的工具链完全由我方提供，加上存在丢日志的情况，对业主的说服力或许不够. *** 补充测试了Facebook、Instagram、Telegram等应用，有效率都是100%，暂时可观察到的有问题应用范围仍然是YouTube
10.6 UTC+8 17:00-19:00 ** 补充前一晚拨测结果 *** OLAP已经尝试修复日志丢失的问题 *** 策略仅在IGW生效的话，拨测有效率在10%-50%之间变化 *** 仍然存在PE的会话日志量，与拨测次数能够对应，但是IGW的会话日志量，少于拨测次数，怀疑仍然存在日志丢失的问题 ** 补充测试策略 *** 安全策略日志缺失的量，似乎少于会话日志，因此补充两条安全策略，方便进行对比验证 **** PE新增一条client IP + YouTube Monitor策略 **** IGW新增一条 Client IP + Server IP Monitor策略 **** !image-2022-10-08-19-07-46-060.png|width=575,height=168!
10.7 UTC+8 17:00-22:00 ** 测试问题 *** 由于同一天业主同时也在办公网内，使用同一个公网出口进行拨测，因此，界面上出现二元组的策略日志和会话日志，远大于拨测终端访问的次数 *** 要求现场人员，补充了客户端捕包，和NPB捕包的数据，方便进行对比验证

**** 业主办公网的出口，经过NAT后共享196.188.136.150这个公网IP进行访问，除源端口发生转换外，似乎NAT中包含一个L4 Proxy，导致TSG日志中使用TCP_ISN无法关联拨测终端捕到的包 **** 使用SSL JA3 Hash，成功关联拨测终端产生的会话，和TSG日志中的会话 ** 结果分析 *** 以最后一次拨测为例，尝试31次访问，15次有效deny，16次deny失败 **** PE ***** NPB上捕获的数据包，能够查询到31条会话，且{}全部为双向流{} ***** 可以查询到31条会话日志，和31条monitor策略日志 **** DIR_IGW ***** NPB捕获的数据包，能够查询到15条会话，与deny成功的对应，{}全部为C2S单向流{} ***** 查询到Deny策略日志13条，均包含在上述15条会话中 ***** 查询到Monitor策略日志13条，均包含在上述15条会话中 ***** 查询到会话记录日志12条，均包含在上述15条会话中 **** MW_IGW ***** NPB捕获的数据包，能够查询到16条会话，与deny失败的对应，{}全部为S2C单向流{} ***** 查询到Monitor策略日志12条，均包含在上述16条会话中 ***** 查询到会话记录日志6条，均包含在上述16条会话中 ** 更新结论 *** 测试固定的二元组（196.188.136.150，172.217.169.23）过IGW时存在单侧流量缺失的情况 **** 经过PE时为完整的双向流 **** 上行至IGW，随机从DIR_IGW或者MW_IGW出口访问国际互联网 **** 经过DIR_IGW的流量，缺失S2C侧流量，不影响deny效果 **** 经过MW_IGW的流量，缺失C2S侧流量，影响YouTube识别，导致无法有效deny *** {}IGW仍然存在丢失日志的情况{}，包括安全日志和会话记录日志

yangwei commented on 2022-11-07T10:04:24.067+0800:

更新记录11.01 UTC+8 17:00-22:00

Old Airport的70次访问，到IGW全部变成单向流
应该在IGW查到70*2=140条日志，但是Microwave-IGW只有36条，Dire Dawa-IGW只有34条，并集为20条
从Old Airport出来的70条拨测访问，20条经过IGW接入是完整的（以单向流的形式Dire Dawa-IGW+Microwave-IGW分开）
14个会话只有C2S，16个只有S2C
拨测的70个会话，在IGW出现次数是20+14+16=50，有20个会话在IGW缺失，缺失率到28%
!image-2022-11-07-10-02-51-001.png|width=524,height=125!

结论

按概率，怀疑IGW侧C2S和S2C接入各缺失约50%，需要更大的测试样本

yangwei commented on 2022-12-06T15:55:43.880+0800:

背景 ** 前述测试server IP 172.217.169.238，属于AS15169，登记的掩码为23位
目标 ** 为验证流量在IGW的缺失，是否与AS域相关，拟扩大拨测范围，请[~liuju] 测试后更新下测试结果表
方法 ** 针对待测试IP，执行以下命令，重复10次，记录命令是否执行成功 {code:java} openssl s_client -connect [测试IP]:443 -state {code}

** 查询会话日志（查询条件 client IP == 196.188.136.150 && server IP == 测试IP），记录对应的IGW和PE日志数量，和流量方向（单向流or双向流）

||测试IP||拨测时间||拨测次数(成功次数)||PE会话日志情况||IGW会话日志情况||备注|| |172.217.169.238| | |站点： SledIP：会话数量：双向流： C2S单向流： S2C单向流：|站点： SledIP：会话数量：双向流： C2S单向流： S2C单向流：|YouTube服务端拨测IP，Google AS15169| |172.217.169.254| | | | |Google IP 与172.217.169.238相同C段IP| |172.217.14.238| | | | |Google IP 相同ASN,临近C段的Google IP| |142.251.215.243| | | | |Google IP 相同ASN的Google IP| | | | | | | | |104.244.42.6| | | | |Twitter IP AS13414| |157.240.3.35| | | | |Facebook IP AS32934| | | | | | | | |175.27.8.138| | | | |Tencent IP AS45090|

liuju commented on 2022-12-06T20:53:24.205+0800:

2022-12-06 拨测结果见下表，具体会话日志见附件

||测试IP||拨测时间||拨测次数(成功次数)||PE会话日志情况||IGW会话日志情况||IGW会话日志情况||备注|| |172.217.169.254|15:42:56--15:45:08|5|站点：old airport -pe SledIP：10.231.11.3 会话数量：5 双向流：5 C2S单向流：0 S2C单向流：0|站点：BOLE-IGW SledIP：10.225.11.3 会话数量：1 双向流：0 C2S单向流：1 S2C单向流：0| |与172.217.169.238相同C段IP| |172.217.14.238|15:54:21--15:57:13|5|站点：old airport -pe SledIP：10.231.11.5 会话数量：4 双向流：4 C2S单向流：0 S2C单向流：0|站点：0 SledIP：0 会话数量：0 双向流：0 C2S单向流：0 S2C单向流：0| |相同ASN,临近C段的Google IP| |142.251.215.243|16:03:22--16:04:29|5|站点：old airport-PE SledIP：10.231.11.2 会话数量：5 双向流：5 C2S单向流：0 S2C单向流：0|站点：BOLE-IGW SledIP：10.225.11.2 会话数量：2 双向流：0 C2S单向流：2 S2C单向流：0|站点：MWV-IGW SledIP：10.227.11.6 会话数量：2 双向流：0 C2S单向流：0 S2C单向流：2|相同ASN的Google IP| |172.217.169.238|16:14:32--16:16:23|5|站点：old airport-pe SledIP：10.231.11.3 会话数量：5 双向流：5 C2S单向流：0 S2C单向流：0|站点：MWV-IGW SledIP：10.227.11.9 会话数量：1 双向流：0 C2S单向流：0 S2C单向流：1| | |

yangwei commented on 2022-12-07T09:52:05.457+0800:

[~liuju] 看结果，像是PE日志都完整，而且流量100%经过，

怀疑IGW在丢流量或者日志，下次测试，把拨测次数增加到10次，并且附一下当时IGW有没有功能端bypass或者丢日志的描述。

yangwei commented on 2022-12-07T10:15:07.563+0800:

新增Facebook、Twitter 、 Tencent IP各一个

liuju commented on 2022-12-08T21:03:16.385+0800:

2022-12-08 拨测结果如下：

具体会话日志及拨测期间板卡监测详情见附件

查询拨测2022-12-08 09:28:00~~2022-12-08 10:25:15时间段内涉及到的NPB 的ddos bypass情况如下：

10.231.11.1 （有bypass 但是bypass期间没有拨测） 10.231.11.2(有bypss 但是bypass期间没有拨测) 10.231.11.3 (无bypass) 10.231.11.4 (无bypass) 10.231.11.5 (无bypass)

10.225.11.1（有bypass 拨测期间一直都有ddos bypass） 10.225.11.2 (有bypass 拨测期间一直都有ddos bypass） 10.225.11.3 （有bypass 拨测期间一直都有ddos bypass） 10.225.11.4 （有bypass 拨测期间一直都有ddos bypass） 10.225.11.5 （有bypass 拨测期间一直都有ddos bypass）

10.227.11.4 (无bypass) 10.227.11.5 (无bypass) 10.227.11.6 (无bypass) 10.227.11.9 (有bypss 但是bypass期间没有拨测) 10.227.11.10 (无bypass) ||测试IP||拨测时间||拨测次数(成功次数)||PE会话日志情况||IGW会话日志情况||IGW会话日志情况||备注|| |172.217.169.238|9:28:01--9:33:52|10|站点：OAP-PE SledIP：10.225.11.3 会话数量：14 双向流：14 C2S单向流：0 S2C单向流：0|站点：BOLE-IGW SledIP：10.225.11.3 会话数量：5 双向流：0 C2S单向流：5 S2C单向流：0|站点：MWV-IGW SledIP：10.227.11.9 会话数量：4 双向流：0 C2S单向流：0 S2C单向流：4|YouTube服务端拨测IP，Google AS15169| |172.217.169.254|9:37:10--9:39:05|10|站点：OAP-PE SledIP：10.231.11.3 会话数量：10 双向流：10 C2S单向流：0 S2C单向流：0|站点：BOLE-IGW SledIP：10.225.11.3 会话数量：2 双向流：0 C2S单向流：2 S2C单向流：0|站点： SledIP：会话数量：双向流： C2S单向流： S2C单向流：|Google IP 与172.217.169.238相同C段IP| |172.217.14.238|9:41:57--9:47:11|10|站点：OAP-PE SledIP：10.231.11.3 会话数量：10 双向流：10 C2S单向流：0 S2C单向流：0|站点：BOLE-IGW SledIP：10.225.11.5 会话数量：6 双向流：0 C2S单向流：6 S2C单向流：0|站点：MWV-IGW SledIP：10.227.11.5 会话数量：5 双向流：0 C2S单向流：0 S2C单向流：5|Google IP 相同ASN,临近C段的Google IP| |142.251.215.243|9:49:54--9:53:28|10|站点：OAP-PE SledIP：10.231.11.2 会话数量：10 双向流：10 C2S单向流：0 S2C单向流：0|站点：BOLE-IGW SledIP：10.225.11.2 会话数量：3 双向流：0 C2S单向流：3 S2C单向流：0|站点：MWV-IGW SledIP：10.227.11.6 会话数量：1 双向流：0 C2S单向流：0 S2C单向流：1|Google IP 相同ASN的Google IP| | | | | | | | | |104.244.42.6|10:25:50--11:21:03|10|站点：OAP-PE SledIP：10.231.11.1 会话数量：10 双向流：10 C2S单向流：0 S2C单向流：0|站点：BOLE-IGW SledIP：10.225.11.1 会话数量：8 双向流：0 C2S单向流：8 S2C单向流：0|站点：MWV-IGW SledIP：10.227.11.10 会话数量：5 双向流：0 C2S单向流：0 S2C单向流：5|Twitter IP AS13414| |157.240.3.35|15:33:30--16:40:24|10|站点：OAP-PE SledIP：10.231.11.4 会话数量：10 双向流：10 C2S单向流：0 S2C单向流：0|站点：BOLE-IGW SledIP：10.225.11.4 会话数量：4 双向流：0 C2S单向流：4 S2C单向流：0|站点：MWV-IGW SledIP：10.227.11.4 会话数量：5 双向流：0 C2S单向流：0 S2C单向流：5|Facebook IP AS32934| |175.27.8.138|10:08:09--10:25:14|10|站点：OAP-PE SledIP：10.231.11.5 会话数量：10 双向流：10 C2S单向流：0 S2C单向流：0|站点：BOLE-IGW SledIP：10.225.11.5 会话数量：1 双向流：0 C2S单向流：1 S2C单向流：0|站点：MWV-IGW SledIP：10.227.11.5 会话数量：9 双向流：0 C2S单向流：0 S2C单向流：9|Tencent IP AS45090|

chengsiyuan commented on 2022-12-16T22:33:34.590+0800:

2022-12-16 拨测结果如下：

具体会话日志及拨测期间板卡监测详情见附件

查询拨测2022-12-16 15:11:00~~2022-12-16 16:16:42时间段内涉及到的NPB 的ddos bypass情况如下：

10.231.11.1 （有bypass） 10.231.11.2（有bypss) 10.231.11.3 （有bypass) 10.231.11.4 （有bypass) 10.231.11.5 （无bypass)

10.225.11.1（有bypass 拨测期间一直都有ddos bypass） 10.225.11.2 （有bypass 拨测期间一直都有ddos bypass） 10.225.11.3 （有bypass 拨测期间一直都有ddos bypass） 10.225.11.4 （有bypass 拨测期间一直都有ddos bypass） 10.225.11.5 （有bypass 拨测期间一直都有ddos bypass）

10.227.11.4 (无bypass) 10.227.11.5 (无bypass) 10.227.11.6 (有bypass) 10.227.11.9 (有bypss) 10.227.11.10 (有bypass)

||测试IP||拨测时间||拨测次数(成功次数)||PE会话日志情况||IGW会话日志情况||IGW会话日志情况||备注|| |172.217.169.238|15:11:48--15:13:13|5|站点：OAP-PE SledIP：10.231.11.3 会话数量：5 双向流：5 C2S单向流：0 S2C单向流：0|站点：BOLE-IGW SledIP：10.225.11.3 会话数量：2 双向流：0 C2S单向流：2 S2C单向流：0|站点：MWV-IGW SledIP：10.227.11.9 会话数量：1 双向流：0 C2S单向流：0 S2C单向流：1|YouTube服务端拨测IP| |104.244.42.65|15:16:54--15:45:01|5|站点：OAP-PE SledIP：10.231.11.3 会话数量：5 双向流：5 C2S单向流：0 S2C单向流：0|站点：BOLE-IGW SledIP：10.225.11.3 会话数量：1 双向流：0 C2S单向流：1 S2C单向流：0|站点：MWV-IGW SledIP：10.227.11.10 会话数量： 3 双向流：0 C2S单向流：0 S2C单向流：3|Twitter服务端拨测IP| |157.240.195.35|15:45:39--16:16:42|5|站点：OAP-PE SledIP：10.231.11.5 会话数量：40 双向流：40 C2S单向流：0 S2C单向流：0|站点：BOLE-IGW SledIP：10.225.11.5 会话数量：10 双向流：0 C2S单向流：10 S2C单向流：0|站点：MWV-IGW SledIP：10.227.11.10 会话数量：34 双向流：0 C2S单向流：0 S2C单向流：34|Facebook服务端拨测IP|

zhengchao commented on 2022-12-19T10:34:29.006+0800:

[~doufenghu] 本周三前定位IGW Data Transporter丢日志的原因

qidaijie commented on 2022-12-20T23:14:50.586+0800:

关于日志在IGW 存在丢失情况，排查如下：

通过OLAP数据流监控，日志从Data Transporter汇聚到国家中心未有明显的日志丢失现象。但在MWV-IGW/ BOL-IGW Data Transporter，功能端向Kafka写入有较明显丢失情况，推断因Kafka磁盘IO利用率过高，影响功能端向Kafka写入日志的性能或延迟。

!OLAP数据流监控.png|thumbnail!

MWV-IGW/ BOL-IGW站点Kafka服务端日志没有ERROR信息，仅有个别WARN信息。

MWV-IGW IO使用率在65%左右，平均每秒写入140MB；BOL-IGW IO抖动较大峰值在75%左右，平均每秒写入170MB。经过比对监控时间线，IO的抖动情况与功能端记录的丢日志监控基本吻合，下图为截取的12月17号BOL-IGW IO利用率和功能端写入BOL-IGW Kafka监控。

!功能端写入Kafka监控.png|thumbnail! !BOL-IGW IO使用率.png|thumbnail!

在先前的优化处理中，MWV-IGW站点功能端关闭了部分日志字段的发送（OMPUB-684），修改后平均日志大小1.6K；日志写入相对更平稳，多写入了2.5-4K的日志。

!功能端日志情况记录-更新前.png|thumbnail! !功能端日志情况记录-更新后.png|thumbnail!

后续排查及处理建议： 1.从功能端出的写入异常监控图，凌晨0-7点未出现丢失日志，可在此阶段通过自动化脚本进行拨测。 2.在Kafka服务端未看到任何错误信息，需要功能端协助查看客户端具体的错误信息。 3.在IGW会话日志适当提高发送会话日志条件(已统计目前会话日志都大于5个包），或关闭DNS会话日志(当前占比40%)，为安全事件日志预留IO。

yangwei commented on 2022-12-25T17:45:42.400+0800:

现状（2022年12月25日） ** 流量缺失问题 *** 通过在低谷时段进行拨测（此时TSG健康状态较为良好，不存在Bypass，日志失败比例较低），发现YouTube和Facebook仍然存在流量缺失的情况 **** 按100次拨测，流量缺失率在5%-10%之间 ** TSG自身问题 *** 日志失败比例高 **** 经在京版模拟测试，相同硬件配置情况下的kafka broker，极限处理日志量为11w-12w tps（前提为对kafka broker参数进行优化，减少写磁盘和增加Batch Queue Size） **** 目前Bole和MWV功能端预计发送的总量均超过14w tps（非峰值时段），超过现场极限处理能力 **** 现场情况 ***** Bole和MWV日志发送失败现象严重，峰值日志（安全+会话）失败比例超过60% ***** Bole和和MWV功能端由于Self Protection触发的会话bypass比例逐步上升 *** 流量Bypass比例高 **** Bole和MWV流量再一次呈上涨趋势，抽样一台NPB观察，每秒新建会话数较两个月前，上涨 20%-30% ***** Bole峰值流量下（晚上21:30），TCP新建每秒已经超过6w CPS，此时功能端bypass比例接近50% ***** MWV峰值Bypass会话比例接近18%
问题 ** {}E21 IGW侧确实存在流量缺失现象，估测比例在5%-10%{}，仅有缺失C2S侧流量时，将造成Deny失败 ** 由于TSG自身问题，业主工作时段拨测，会因为功能端处理能力过载造成Bypass的原因，{}放大Deny失败的结果，比例高于实际的5%-10%{} ** 加上日志发送失败的现象，如果仅以TSG作为排查工具链，将{}给用户以流量缺失较实际更为严重的结论{}
解决方案 ** 日志失败 *** 功能端关闭Bole和MWV的DNS会话日志（此前仅调整MWV单条日志的长度，降低了发送带宽，但是没有调整日志量），缓解kafka broker压力（调整后，预计日志发送量在11w tps） **** 具体操作方法已提交刘菊，视现场情况酌情进行调整 *** OLAP 调整两个站点kafka broker参数，提升接收性能（如果不调整参数，降低后的11w tps仍然过载） ** 功能端Bypass造成Deny效果不佳 *** 根据前述分析，目前性能瓶颈之一在于策略命中结果较多，造成扫描消耗CPU较大，但是指导用户对冗余策略条件进行合并，可操作性不大 *** 升级sapp，Bypass时，跳过常用端口（如443、80），从而一定程度上，优先保证Deny效果 **** 目前HTTP和SSL流量占比约50%，理论上仅对非HTTP和SSL会话进行bypass，仍然能够起到Self Protection的效果，具体效果需要更新后观察 **** 对应的sapp程序已发送给刘菊（MD5sum 5b43d015df8a8d77fee10e6a994ddc5a），视现场情况酌情进行调整

yangwei commented on 2022-12-26T15:35:18.398+0800:

2022-12-26 10:33

Bole-IGW NPB04，单核使用已经超过85%，存在Bypass现象

!image-2022-12-26-15-34-15-331.png|width=590,height=337!

perf top -C 4

!image-2022-12-26-15-35-07-022.png|width=809,height=486!

yangwei commented on 2022-12-26T15:40:05.504+0800:

Bole-IGW 2022-12-25 11:05至2022-12-26 11:05 24小时的Live Traffic Chart

SSL占比（HTTPS+SSL）约49%

HTTP占比约5.6%

!image-2022-12-26-15-38-44-332.png|width=580,height=489!

yangwei commented on 2022-12-26T15:58:51.441+0800:

Bole-IGW NPB04 扫描统计情况

!image-2022-12-26-15-55-35-726.png|width=659,height=457!

流量统计情况，原始流量7.8Gbps，每秒新建TCP 5.7w，UDP 2.9w，总计新建8.6w，平均每1Gbps流量每秒新建1.1w

!image-2022-12-26-15-57-12-419.png|width=668,height=294!

liuju commented on 2022-12-26T21:08:55.512+0800:

2022-12-26 已根据研发提供的sapp（MD5sum 5b43d015df8a8d77fee10e6a994ddc5a）对BOLE-IGW 10.225.11.4做以下更新： 1、sapp进行升级；

2、关闭DNS transaction log；编辑plug/business/tsg_conn_sketch/tsg_conn_sketch.inf，把下面这三行前面加上#注释了 [DNS] FUNC_FLAG=ALL FUNC_NAME=tsg_record_dns_entry

3、sapp添加了5个核。目前/opt/tsg/sapp/etc/sapp.toml配置如下： worker_threads=48 bind_mask=[5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52] /opt/tsg/tfe/conf/tfe/tfe.conf配置如下： nr_worker_threads=1