第9章 云网络与割接联调

对应简历：技能第10条「熟悉移动云（ECS / CLB / VPC / 云数据库）与阿里云核心产品，具备云上环境交付经验」/ 项目一职责「负责上线割接与环境验收」/ 项目二职责「配套云数据库、消息队列及 WAF / DDoS / 主机安全等云服务的开通配置与业务发布支持」/ 技能第3条中「集群与分布式交换机配置」的网络联调部分

实施版定位：网络是实施岗的"事故高发区"——客户现场装不通、联调连不上、割接出意外，九成是网络层的事。本章四条主线：排查命令链、联调排障、安全组配置、云资源开通交付清单，再加网络割接的准备与验证。CE 交换机与双平面组网的深度内容在第 8 章与华为篇第 7 章；割接的项目级编排（方案/窗口/回退）详见第 15 章 15.12，本章讲网络侧的技术动作。

9.1 网络排查命令链：五层从本机到抓包 【必背】

标准回答（实施版第一生存技能）: 网络排查我有一套固定的五层命令链，从本机往数据方向逐层推进，把模糊的"网络不通"变成精确的"断在第几层"。第一层看本机：ip a 确认地址配了没、网卡 up 没 up，ip r 看路由和默认网关，ss -antup 看监听端口和连接状态，然后 ping 网关 验证本机到网关这段——网关都不通基本是本机配置或二层的问题。第二层测链路：ping 对端IP 通不通，不通就 traceroute 对端IP 看路径断在哪一跳——是出网关就断还是中间某一跳断。

第三层测端口：telnet IP 端口 或 nc -zv IP 端口，验证四层能不能连上——ping 通 telnet 不通，问题就收敛到端口层面。第四层测服务：curl -v 带详细输出访问，看七层返回的状态码、证书和响应。第五层抓包：tcpdump -i eth0 host 对端 and port 端口，看两个机器之间到底有没有报文交互、交互到哪一步卡住——比如 TCP 握手只发不回，还是回了 RST。

辅助还有 arp -n 看 ARP 学习、ss -ant | awk '{print $1}' | sort | uniq -c 统计连接状态分布。这套链条我在银行现场和云上排障都是这么走的，差别只在第一嫌疑人：机房环境先怀疑线缆和 VLAN，云上环境先怀疑安全组和网络 ACL——云上"突然不通"大量是变更引起的，先看变更记录再动命令。 实操模板（排查命令树，背熟）：

1 本机:  ip a | ip r | ss -antup | ping <网关>
2 链路:  ping <对端IP> → traceroute <对端IP>（看断在哪跳）
3 端口:  telnet <IP> <端口> 或 nc -zv <IP> <端口>
4 服务:  curl -v http(s)://<域名或IP>:<端口>/路径   # 看状态码
5 抓包:  tcpdump -vvv -nnn -i eth0 host <对端IP> and port <端口>
6 组合:  ss -ant | awk '{print $1}' | sort | uniq -c   # 连接状态统计

追问链：

• 迭问1：ping 通但 telnet 端口不通，怎么继续？ → 答：这说明三层通、四层不通，问题收敛在端口层面，按三个方向查：第一对端服务到底起没起、有没有监听这个端口——登对端 ss -lntp 看；第二监听地址是不是 0.0.0.0——很多服务默认只听 127.0.0.1，本机自测没问题、外面就连不上，这是联调期的超高频坑；第三路径上的防火墙或云上安全组有没有放行。三步查完基本必有答案，我在客户现场处理"应用装好了但客户访问不了"，八成落在第二条。
• 迭问2：tcpdump 你实际用来解决过什么问题？ → 答：典型场景是验证两台机器之间有没有真实的数据交互。比如怀疑证书协商失败，抓包能看到 TCP 三次握手完成、客户端发 ClientHello 之后对端直接回 RST 或者没有响应——一下就能区分"网络断"还是"服务拒"。命令形如 tcpdump -vvv -nnn -i eth0 host A and port 6443，-nnn 不做域名和端口反解输出干净；要留证就 -w 存 pcap 文件。抓包是网络排障的终点站——前面命令都定位不了就上它，银行项目里我排查 apiserver 连接问题就是这么定论的。

9.2 联调排障实战：前后端联调的网络三板斧 【必背】

标准回答（项目一/二联调期的真实打法）: 实施岗的联调排障，我总结成"三个高频问题加固定打法"。问题一服务装好了外部访问不了：按 9.1 的方向三查——监听（ss -lntp）、监听地址（0.0.0.0 还是 127.0.0.1）、防火墙/安全组。数币平台联调时前端页面正常但接口报错，我按"从入口往里"走：curl 入口通 → telnet 后端 8080 通 → jps 确认 Java 进程在 → 翻后端日志——最后定位到数据库连接串问题，网络层全通、应用层配置错，这种"层层排除后收敛到应用"的路径比瞎猜快得多。

问题二域名/服务名解析不了：二分法先做——ping IP 通但域名不通，锁死 DNS 层；然后 nslookup 或 dig 验证，dig @223.5.5.5 域名 指定公共 DNS 对比还能判断是不是本地 DNS 污染；集群内看 resolv.conf 指向 CoreDNS、nslookup 服务名验证。经典现象"QQ 能登网页打不开"就是 DNS 故障的教科书案例——IP 直连的应用都正常，凡是要解析域名的全挂。问题三跨网段/跨可用区访问慢或断：traceroute 和 mtr 看路径——mtr 能区分假丢包（某跳不响应 ICMP 但后续正常）和真丢包（某跳起后续全丢）；带宽疑问用 iperf3 打流拿硬数据（服务端 -s、客户端 -c，十秒出吞吐）。联调期我把这些命令做成一张排障卡贴在工位，同事遇到网络问题也照着走——后来这张卡直接进了交付文档的"联调排障"一节。 追问链：

• 迭问1：Nginx 反代场景 502 和 504 怎么分？ → 答：先分清两个码的方向：502 是后端连不上或返回无效响应——后端挂了、重启中、监听地址不对；504 是连上了但超时没返回——后端慢，慢在数据库或下游依赖。第一步 tail Nginx 的 error.log：connect() failed 对应 502、upstream timed out 对应 504，日志措辞直接分诊。然后 ss -lntp 看后端监听、curl 本机直连后端绕开 Nginx 验证。这套分诊我在平台联调和上线保障期用过很多次，是中间件交付的必备技能（Nginx 配置细节见第 4 章）。
• 迭问2：连接状态统计能看出什么？ → 答：ss -ant | awk '{print $1}' | sort | uniq -c 一条命令看分布：大量 SYN_SENT 是请求发不出去（对端不可达或队列满）；大量 CLOSE_WAIT 是应用收到对方 FIN 却没调用 close——几乎百分之百是应用代码 bug，要拉开发查；大量 TIME_WAIT 是短连接高频创建，改长连接或连接池。我把这个命令放进巡检脚本，联调期每天跑一遍，很多问题在客户感知之前就被这个分布图暴露了。

9.3 安全组配置与最小权限矩阵 【必背】

标准回答（云交付的核心配置项）: 安全组是云上实例级的有状态虚拟防火墙，挂在 ECS 网卡上，默认拒绝一切入站流量。它"有状态"的意思是：入方向规则放行的连接，响应的出站流量自动允许，不用写回程规则——这和传统无状态 ACL（进出各写各的）的区别是必考点。我的配置方法论是按角色分组、链路式放行、默认全拒：管控面安全组只放行跳板机网段访问 6443 和 22；节点组放行集群内部端口（10250 kubelet、30000-32767 NodePort 段、8472 UDP Flannel VXLAN）；数据库安全组只收应用子网的 3306；每条规则写清用途备注。项目二移动云的安全组矩阵就是这么设计的——任何变更走申请审批，改动前导出备份，一次只改最小范围并验证后再收尾。

安全组配错是云上 K8s 节点 NotReady 的常见根因之一——节点注册不上、健康检查过不去，我排查 NotReady 的固定动作里就有"核对安全组放行列表"这一步。实施岗还要注意一个纪律：安全组是高危变更——误放行 0.0.0.0/0 到数据库端口等于把库暴露公网，所以我把安全组变更当成和数据库变更同级的管理对象：申请、审批、备份、验证四步缺一不可。这套最小权限的规划方法比记住某个控制台按钮重要得多——换哪家云都适用。 实操模板（安全组规划矩阵示例表）：

安全组          方向  协议  端口         授权对象             用途
sg-master       入    TCP   6443         跳板机网段/CLB       apiserver
sg-master       入    TCP   22           跳板机网段           SSH 运维
sg-node-all     入    TCP   10250        master 网段          kubelet
sg-node-all     入    TCP   8472(UDP)    节点网段             Flannel VXLAN
sg-node-all     入    TCP   30000-32767  业务入口网段         NodePort
sg-db           入    TCP   3306         应用子网             云数据库
默认策略        入    ALL   ALL          拒绝                 最小权限

追问链：

• 迭问1：云上 K8s 节点间要放行哪些端口？ → 答：核心清单：6443（apiserver，节点和 CLB 都要能到）、2379/2380（etcd，master 之间）、10250（kubelet，master 到所有节点）、30000-32767（NodePort 段）、8472 UDP（Flannel VXLAN 封装）。这份清单我在方案里做成表格，开安全组时逐行勾——漏一条的表现各不相同：漏 8472 是跨节点 Pod 不通，漏 10250 是节点 NotReady，漏 6443 是节点根本加不进来。按现象反推漏了哪个端口，这也是排查的捷径。
• 迭问2：安全组"有状态"帮运维省了什么？ → 答：省掉回程规则。放行了入方向 SSH 22，这台机器回给客户端的响应包自动允许出站，不需要再写一条出方向规则——无状态方案（如网络 ACL）就得进出两边都配，规则翻倍还容易漏。理解这个机制还有个实际价值：排查"规则不生效"时不会去乱加出站规则——有状态下多数"单向不通"问题出在入方向或对端，不在回程。

9.4 云资源开通交付清单（项目二真实打法） 【必背】

标准回答（"云上环境怎么交付"标准答案）: 云资源开通我按"一张规划表加一份验收清单"交付，这是项目二落地的真实打法。规划表先定四件事：网络拓扑——一个 VPC 跨三个可用区，子网按角色划分，7 台 ECS 固定 IP 分配（3 台 2C4G master 跨可用区做机房级隔离、3 台 8C16G worker、1 台 4C8G 监控节点）；出入口设计——入口收敛：所有 kubectl 和组件连 CLB 的 VIP:6443，业务入口按需开放；出口收敛：全集群纯内网机器统一走 NAT 网关加 EIP 出公网（拉镜像、下软件包），管理入口统一走跳板机——所有流量都有明确的道，审计和排障都简单；配套服务——云数据库 MySQL 8.0 主备（8C16G/300G SSD）、Redis 双机热备、RocketMQ 两节点、Nacos；安全配套——WAF、DDoS 原生防护 5G、主机安全企业版、数据库审计，这四件套是等保和客户合规的硬性要求。

验收清单逐项过：ECS 可登录、时间同步、初始化基线执行完；CLB 监听器和健康检查生效（后端全健康）；NAT 网关 SNAT 通（节点能出公网）；云数据库可连接、主备状态正常（控制台执行主备切换验证角色互换、应用连接串指向可切换地址）；安全组按矩阵核对无误。开通顺序也有讲究：先网络（VPC/子网/安全组）再计算（ECS）再入口出口（CLB/NAT）最后配套（数据库/安全服务）——网络没就绪就开机器，机器之间不通会白白消耗联调时间。这套清单沉淀在建设方案里，成为公司外包项目云资源开通的标准动作。 追问链：

• 迭问1：为什么数据库用云托管不自建？ → 答：决策逻辑是业务优先：外包项目上线时间紧，自建数据库要搭主备、配备份、做监控、管切换，一套下来一两周还要持续兜底；云托管这些能力现成——主备自动切换、自动备份、监控告警全由云方负责，我们交付的是规格规划和连接信息。另一个坚持是有状态服务不进 K8s——数据库跟容器"随发随销"的模型冲突（第 6 章 6.6 讲过取舍）。当然自建能力我有——银行项目 Vastbase 一主一备是我搭的——正因为会自建，才知道什么时候不值得自建。
• 迭问2：CLB 四层和七层怎么选？ → 答：一句话：四层管转发，七层管内容。apiserver 用四层——kubectl 和组件走的是 TCP 上的 TLS 长连接，不需要七层的域名路由和改写头，四层性能好延迟低，健康检查配 TCP 探测 6443 简单可靠；Web 业务入口才考虑七层——要按域名 URL 路由、在负载均衡上卸载证书的时候。这个选型我在移动云方案里写过对比，是"按流量性质选层"的标准案例。

9.5 网络割接：准备与验证（实施版核心场景） 【必背】

标准回答（项目级编排见第 15 章 15.12，这里讲网络侧动作）: 网络割接是实施岗含金量最高的动作之一，我的方法论三段：准备段做三件事——网络基线快照（割接前的 IP 规划表、VLAN/端口组对应表、路由表、安全组规则全部导出留档，割接后逐一比对）；连通性基线（关键链路的 ping/telnet 结果记录在案，作为割接后的对照标准，比如"跳板机到三个 master 的 6443 全通"这条基线）；回退方案（明确回退触发条件——验证清单有任一关键项不过且短时间定位不了就回退；回退动作写到命令级——改回哪条路由、恢复哪个安全组、DNS 切回旧记录，回退窗口和责任人定好）。

执行段的纪律：变更窗口选业务低峰并向客户报备；动作按清单逐步执行、每步完成即验证（一步一验，不攒着）；双人操作——一人执行一人核对（金融客户尤其认这个）。验证段按"由底层到业务"的顺序：先网络层（traceroute 路径符合预期、安全组放行核对）、再服务层（各组件端口 telnet 通、集群 get nodes 全 Ready、数据库主备正常）、最后业务层（关键功能冒烟——登录、核心交易路径各走一遍）、外加观察期（盯监控大盘一个周期，确认无异常再宣布割接成功）。我在银行项目做平台上线割接、在移动云做集群入口切换，都是这套节奏——割接的本质是"把不可逆变成可逆、把意外变成清单"。 追问链：

• 迭问1：割接中验证失败，回退的决策怎么做？ → 答：决策规则在割接前就定好，现场不临时讨论：验证清单分"关键项"和"非关键项"——关键项（核心业务功能、数据链路）任一失败即触发回退评估；评估只回答一个问题"能不能在窗口内定位并修复"——能且影响可控就修复继续，不能就立即回退。回退不是失败，是预案的组成部分——我在方案里写回退方案时的态度和写割接步骤一样认真，因为"敢不敢割接"取决于"能不能退回来"。真正的事故大多发生在"没有回退预案还硬着头皮继续"的场景。
• 迭问2：双平面网络对割接有什么帮助？ → 答：帮助极大：管理面和业务面物理或逻辑隔离（每台服务器管理 IP 加业务 IP 分接不同交换机/VLAN，另有 BMC 带外网），意味着业务面割接出问题时，管理通道还在——我能通过管理面登录设备排查、通过 iBMC 带外救机器，不至于"业务断了人也瞎了"。银行项目的三张网（管理、业务、BMC）就是为这种场景设计的，割接演练时我们专门验证过"业务面中断时管理操作不受影响"——网络设计的冗余，在割接和故障时刻兑现价值（双平面细节见第 8 章）。

9.6 够用版：TCP/端口/DNS/子网速答 【理解】

标准回答（联调期被问到的基础题，一句话口径）: 几组基础概念按"能接住追问"的深度讲。TCP 三次握手为什么不能两次：双方都要确认"自己的发送和接收能力都正常"，两次的话服务端无法确认客户端收到了应答，另外还能防止历史滞留的 SYN 误建连接。四次挥手为什么四次：TCP 全双工，两个方向分别关闭；被动方收到 FIN 时可能还有数据没发完，所以 ACK 和自己的 FIN 拆开传。TIME_WAIT 在主动关闭方、等 2MSL——保证最后的 ACK 丢了能重发，并让旧连接报文自然消亡。常记端口一组：22 SSH、80/443 HTTP/HTTPS、3306 MySQL、6379 Redis、5432 PG 系、6443 apiserver、10250 kubelet、30000-32767 NodePort、9100 node-exporter、9090 Prometheus、3000 Grafana——记端口的价值是排障条件反射：看到连不上先想"这个端口该由谁监听、放没放行"。

DNS 解析流程：本地缓存 → 本地 DNS（递归）→ 根 → 顶级域 → 权威（迭代），排障口诀"IP 通域名不通查解析，dig 指定 DNS 对比辨污染"。子网划分拿一道题讲透：192.168.0.0/24 划出每段至少 50 台——主机位留 6 位（62 可用），借 2 位做子网位，掩码 /26，得 4 段：.0/26（可用 .1–.62）、.64/26（.65–.126）、.128/26、.192/26，块大小 64 的口诀现场算很快。VLAN 一句话：二层隔离广播域，Access 口接终端不打标签、Trunk 口级联承载多 VLAN 带 802.1Q 标签——虚拟化端口组绑 VLAN ID 与交换机 trunk 放行是"一张规划表对出来的"（第 8 章）。 追问链：

• 迭问1：HTTPS 的加密怎么分工？ → 答：握手阶段用非对称加密完成两件事——验证服务端证书身份、协商出对称密钥；之后的通信用对称加密跑数据。分工原因：非对称慢好几个数量级，只适合交换密钥，大量数据传输靠快的对称算法。运维要记四件事：TLS 终止点通常在 Nginx 或 LB；SAN 字段决定证书对哪些域名 IP 有效（我在 K8s 证书上真实踩过坑，第 6 章 6.3）；有效期管理配告警；自签证书的 CA 链要分发到信任端。
• 迭问2：mtr 里某一跳 100% 丢包但后面正常？ → 答：说明那一跳路由器只是不响应 ICMP 探测（限速或策略），转发是正常的——这是假丢包；判断真丢包的标准是"从某一跳开始它和后面全部丢"。能讲出这个细节，说明真用过 mtr——我在跨网段联调验证线路质量时靠它区分过"中间设备不回包"和"真线路劣化"，两种结论的处理方向完全不同。

9.7 VLAN、Trunk 与双平面组网（交付视角） 【必背】

标准回答: VLAN 是在交换机上把一个物理局域网逻辑划分成多个广播域的技术，三个价值：隔离广播风暴、安全隔离（不同部门流量二层隔开）、灵活（按业务分组改配置不用重新布线）。关键技术点：不同 VLAN 二层不通，互通必须经三层——三层交换机的 VLANIF 接口做各 VLAN 网关；端口类型两种分清——Access 口接终端只属一个 VLAN 收发不打标签，Trunk 口用在交换机之间或接服务器，一条链路承载多 VLAN 流量靠 802.1Q 打 4 字节标签区分。

服务器虚拟化场景是两者的组合：物理交换机口起 trunk 放行多个 VLAN，虚拟化平台的分布式交换机端口组绑定 VLAN ID，虚拟机挂到哪个端口组就在哪个 VLAN——银行项目我在 FusionCompute 上配端口组就是这个模型，和网络团队的交换机 trunk 配置是"一张规划表对出来的"，双方按表施工、按表验收。实施岗最该讲的是双平面组网：银行每台服务器管理 IP 和业务 IP 分开，分别接不同交换机或不同 VLAN，另有 iBMC 口接 BMC 带外管理网——三张网互不抢带宽：业务网再怎么打满，管理操作和带外救机器不受影响。这个平面隔离思想我后来平移到云上就是安全组分层和出入口收敛——网络设计的冗余与隔离，在割接和故障时刻兑现价值。 追问链：

• 迭问1：交换机级联口怎么配、配错什么现象？ → 答：两端都配 trunk 并放行所需 VLAN 列表，两边必须一致——一端 trunk 一端 access，流量标签对不上，轻则不通，重则不同 VLAN 流量串到一起出安全问题。所以交换机配置变更有互检环节，改完 display vlan 和 display port vlan 核对两端放行列表（CE 交换机操作细节详见第 8 章与华为篇第 7 章）。
• 迭问2：怎么定位环路和广播风暴？ → 答：先看现象：所有端口流量同时异常打满、CPU 升高、ping 大面积超时抖动。display interface brief 看哪个口流量异常、有没有大量广播包和 CRC 错包，再排查是否有口被误接成环路。防的办法是交换机配 STP 生成树，阻塞冗余路径自动破环——银行组网管理业务双平面分开、各自独立组网，天然减少了环路面。

9.8 云安全配套四件套：WAF / DDoS / 主机安全 / 数据库审计 【理解】

标准回答（实施岗"配置管理者"口径）: 这四个是项目二按等保要求和客户合规采购的安全配套，我按攻击层次讲它们各防什么。WAF 是 Web 应用防火墙，部署在 HTTP 入口防应用层攻击——SQL 注入、XSS、WebShell 上传这类 OWASP Top 10，外加 CC 高频恶意请求；CC 和 DDoS 的区别要分清：CC 在应用层，每个请求看起来都"合法"，靠高频把 CPU 和连接资源耗尽；DDoS 是流量型，海量包打带宽，靠云端清洗中心抗——我们配套的 DDoS 原生防护是 5G 基础带宽。主机安全装 Agent 干两件事：基线核查（弱口令、高危端口、配置合规对照等保基线给整改建议）和入侵检测（异常登录、WebShell、挖矿进程告警）。数据库审计做全量 SQL 访问留痕——谁、什么时间、从哪个地址、执行了什么语句都可追溯，它比数据库本地日志强在独立旁路采集、防篡改、自带合规报表，这正是等保要独立审计的原因。

我的角色定位要说准：配置管理者——规划选型建议、策略配置（基线检查项开哪些、告警级别怎么定、审计规则覆盖哪些库、WAF 白名单精确到 URL 和参数）、业务发布时做放行配合、账号权限最小化规范，不是安全攻防专家。两条实战经验：WAF 上线先开观察模式（只告警不拦截）跑一段时间把误报摸清再切拦截，避免上线即误杀；主机安全告警疑似挖矿的处置五步——先隔离止损（安全组收紧）、kill 进程清理持久化项、排查入侵入口（弱口令/未授权/漏洞）、加固恢复、回溯横向移动。这个边界诚实讲反而稳。 追问链：

• 迭问1：WAF 误杀了正常请求怎么办？ → 答：处理顺序：先看 WAF 拦截日志，定位命中了哪条规则哪个参数；然后加白名单——白名单必须精确到具体 URL、参数或规则 ID，不能一刀切关掉整类规则（等于开天窗）；放行后做业务验证确认恢复。预防动作就是"观察模式先行"——上线先只告警不拦截，跑稳了再切拦截模式。
• 迭问2：等保对实施交付的实际影响有哪些？ → 答：落地视角五件事：通信加密（HTTPS、内网传输按需加密——Nginx 挂证书的合规背景）；访问控制（安全组最小权限、VPC 分区分域）；安全审计（日志留存不少于六个月——logrotate 归档加异机存储落地，数据库审计平台配保留周期）；入侵防范（主机安全 Agent）；数据备份恢复（备份策略加异地）。测评机构来现场时配合提供证据材料我有经验——配置截图、策略导出、备份记录这些"证据链"的整理本身就是实施交付的一部分。

9.9 用 tcpdump 看懂一次完整的 TCP 连接 【理解】

标准回答（"你说熟 TCP，抓包讲讲"的升级题）: 如果面试官要求抓包讲一次连接，我按 tcpdump 的真实输出讲。命令 tcpdump -i eth0 -nnn host 对端IP and port 8080——-i 指定网卡，-nnn 不做域名和端口反解输出干净。正常连接的输出序列：先是三次握手三行——客户端发 Flags [S]（SYN）带随机初始序列号；服务端回 [S.]（SYN+ACK，点号表示 ACK 位），ack 等于第一行 seq 加一；客户端回 [.]（纯 ACK），握手完成。中间数据传输看到 [P.]（PSH 携带数据推送）和对应 ACK，从 seq 和 length 能看出每次发了多少字节。断开看四次挥手：主动方 [F.]（FIN），对端 ACK，对端再发自己的 FIN，主动方回最后 ACK——主动方随后进 TIME_WAIT。

异常形态我认三种：只看到 SYN 没有回包——对端没收到或被丢，配合防火墙/安全组排查；回的是 [R]——连接被强制重置，握手阶段出现多半是端口没监听或被防护设备切断，established 之后出现多半是设备干预或进程崩溃；大量重传（同样 seq 反复出现）——链路质量差或对端处理不过来。抓包过滤的纪律是先窄后宽：先精确过滤（host 加 port）定位问题，什么都没抓到再放宽，一上来全量抓包自己淹死自己——要留证就 -w 存 pcap 用 Wireshark 看时序图。这套"从 Flags 讲故事"的能力，是 TCP 知识从背诵变成实感的分水岭。 追问链：

• 迭问1：tcpdump 和 Wireshark 什么关系？ → 答：分工不同：tcpdump 是命令行抓包工具，适合在服务器上现场快速抓和过滤，输出文本直接读；Wireshark 是图形化分析器，适合把 tcpdump -w 存下来的 pcap 文件做深度分析——时序图、协议解码、跟随流。我的现场习惯：服务器上 tcpdump 精确过滤快速判断；问题复杂需要回放分析时存 pcap 拉到本机用 Wireshark——两件工具一条链。

9.10 本章案例

• 【真实项目】项目二云网络交付（STAR，约 250 字）：背景是外包业务系统上线，网络与安全体系必须同步到位。任务是我负责移动云上网络规划与安全配套落地。行动：规划一个 VPC 跨三个可用区、子网按角色划分、7 台 ECS 固定 IP；入口层 CLB 四层监听 6443 挂三个 master 配健康检查自动摘除；出口层 NAT 网关加 EIP 统一公网出口；安全层按角色设计安全组矩阵（管控面只放跳板机网段 6443/22、节点组放行 10250 与 NodePort 段和 8472 UDP、数据库只收应用子网），配套 WAF、DDoS 防护、主机安全、数据库审计的策略配置与发布放行验证。结果：业务系统一次性通过安全检查合规上线，安全组矩阵和配置基线沉淀进方案文档成为标准。
• 【真实项目】银行内网双平面组网联调（STAR）：背景是银行生产环境要求管理流量与业务流量隔离。任务是我配合完成三张网实施与联调验证。行动：每台服务器规划管理 IP 加业务 IP 双平面分接 CE6856HI 与 CE6863 交换机，iBMC 口单独接 BMC 管理网；交换机按规划表做 VLAN 划分和 trunk 放行，FC 端口组与交换机配置一一对应；联调期按"规划表逐链路 ping/telnet 验证"建连通性基线。结果：管理、业务、带外三网完全隔离，业务网流量再大不影响管理操作——这套基线在后来的割接验证里直接复用。
• 【经典故障】"QQ 能登网页打不开"（DNS 分诊案例，约 200 字）：用户反馈网页打不开但 QQ 正常。排查按四层收敛：ping 网关和公网 IP 通——链路没问题；域名不通锁定 DNS；nslookup 失败、换 223.5.5.5 公共 DNS 对比能解析——本地 DNS 故障或缓存污染；清缓存改 DNS 后恢复。教学点：IP 直连的应用正常、凡解析域名的全挂，基本锁定 DNS——这个二分法（L3 通 vs 解析通）是我排网络问题的第一刀，云上版本就是"IP 通服务名不通查 CoreDNS"。

9.11 章末自测清单（快问快答）

1. 五层排查命令链？ → 本机（ip a/ip r/ss/ping 网关）→链路（ping/traceroute）→端口（telnet/nc）→服务（curl -v）→抓包（tcpdump）。
2. ping 通 telnet 不通三查？ → 服务监听（ss -lntp）、监听地址是否 0.0.0.0、防火墙/安全组放行。
3. 云上"突然不通"的第一嫌疑人？ → 安全组/ACL 变更——先看变更记录再动命令。
4. K8s 节点间安全组核心端口？ → 6443、2379/2380、10250、30000-32767、8472 UDP（Flannel）。
5. 安全组"有状态"什么意思？ → 入方向放行的连接回程自动允许，不用写出方向规则。
6. 安全组变更四步纪律？ → 申请审批、导出备份、最小范围修改、验证后收尾。
7. 云资源开通顺序？ → 网络（VPC/子网/安全组）→计算（ECS）→出入口（CLB/NAT）→配套（数据库/安全服务）。
8. 出入口收敛的设计？ → 出统一 NAT 网关+EIP，入统一 CLB，管理走跳板机。
9. 割接准备段三件事？ → 网络基线快照、连通性基线、回退方案（命令级）。
10. 割接验证的顺序？ → 网络层→服务层→业务层冒烟→观察期盯盘。
11. 回退决策规则？ → 关键项失败且窗口内无法定位修复即回退；回退是预案组成部分，现场不临时讨论。
12. 双平面对割接的价值？ → 业务面故障时管理面和 BMC 带外仍可用，人不瞎。
13. 502 和 504 一句话？ → 502 后端连不上/挂了；504 连上了但超时——error.log 措辞直接分诊。
14. CLOSE_WAIT 大量堆积说明？ → 应用收到 FIN 没关闭连接，代码 bug，拉开发查。
15. CLB 四层和七层怎么选？ → TCP 长连接/要性能用四层（apiserver）；要域名路由/证书卸载用七层（Web 入口）。
16. 三次握手为什么不能两次？ → 双方都要确认收发能力正常，且防历史 SYN 误建连接。
17. /26 的块大小和可用地址数？ → 块 64，可用 62（网络号加广播去掉两头）。
18. mtr 假丢包判断？ → 某跳丢包但后续跳正常=假丢包（不响应 ICMP）；某跳起后续全丢=真丢包。
19. 非对称和对称加密分工？ → 非对称握手时验证身份换密钥，对称跑数据——性能决定分工。
20. 数据库为什么用云托管？ → 上线时间紧，主备/备份/监控托管现成；有状态服务不进 K8s；自建能力有、掂量过才决定不自建。
21. tcpdump 里 [S]/[S.]/[F.]/[R] 各代表什么？ → SYN 请求 / SYN+ACK 应答 / FIN 关闭 / RST 强制重置（端口没听或被防护切断）。
22. WAF 上线的正确姿势？ → 先观察模式（只告警不拦截）摸清误报，再切拦截；白名单精确到 URL/参数/规则 ID。
23. 等保日志留存要求？ → 不少于六个月，logrotate 归档加异机存储落地。
24. Access 和 Trunk 口区别？ → Access 单 VLAN 不打标签接终端；Trunk 多 VLAN 带 802.1Q 标签接级联/服务器。
25. 双平面组网的价值？ → 管理/业务/BMC 三网隔离——业务打满不影响管理，带外随时救机器。