第9章 网络排查与工单处理

对应简历：技能第 6 条「熟悉 TCP/IP 与 VLAN 基础网络，能独立完成网络连通性排查（ping / telnet / traceroute）与基础配置」、技能第 1 条「一线问题响应、记录跟踪与客户沟通的完整经验」、职责实-2「按'记录—处理—转派—跟踪—闭环'流程」、项目三 P3-3「配套云服务配置管理」。 支持版定位：本章是支持岗的主梁章，全量保留运维版网络内容并扩写——排查命令树逐条讲解化（每条命令独立成节：输出怎么读、下一步查什么），新增"网络类工单处理流程"与 VLAN/DNS/DHCP 三类故障场景。 华为 CE 交换机配置细节详见华为篇 07-iBMC 与 CE 交换机，本章只保留操作与诊断层。 使用提醒：面试支持岗，"网络不通怎么排查"几乎是必考题——本章 9.5–9.11 的命令树和 9.12 的工单五步就是标准答案的骨架。

第一部分：网络基础（对应技能第 6 条）

9.1 OSI 七层与 TCP/IP 四层模型 【必背】

标准回答：先说结论：OSI 是理论上的七层参考模型，工程上大家实际用的是 TCP/IP 四层模型，我平时排障就是按四层一层层收敛的。 OSI 从下往上七层分别是：物理层管比特流在线缆上的传输，数据链路层把比特封装成帧、用 MAC 地址做寻址，网络层负责 IP 包的路由选路，传输层做 TCP/UDP 的端到端通信，再往上会话层、表示层、应用层分别管会话维护、加密压缩和具体应用。 TCP/IP 四层是把七层做了工程化合并：网络接口层对应物理加链路层，网络层跑 IP、ICMP、ARP，传输层跑 TCP 和 UDP，应用层把 OSI 上面三层合成一层，HTTP、DNS、SSH 都在这层。 这个模型对支持岗最大的价值是排障顺序：先看线缆网卡亮不亮，再看 IP 和路由通不通，然后测端口连不连得上，最后再看应用本身返回什么——从一层往七层逐层验证，问题一定能收敛到某一层。 我在银行项目和移动云项目里定位网络问题都是这个套路，比如 kubectl 连不上 apiserver，先 ping 通不通、再 telnet 6443 端口、最后看证书和 apiserver 日志，就是四层模型的实际应用。

追问链：

• 追问1：交换机和路由器分别工作在哪一层？ → 答：交换机工作在二层，收到帧之后查 MAC 地址表决定从哪个口转发；路由器工作在三层，收到包之后查路由表按目的 IP 转发。现在数据中心常用的三层交换机是带路由功能的交换机，既有二层的大容量交换能力又能做三层网关，银行项目的 CE 交换机就是这类，配了 VLANIF 接口给每个 VLAN 做网关。支持岗记住"交换机认 MAC、路由器认 IP"这句话，VLAN 和路由的故障就能分开归因。
• 追问2：一次 ping 通到底经历了哪些层？ → 答：ping 用的是 ICMP 协议，它工作在网络层，但整个动作是跨层的：本机应用发出 ping 命令，内核封装成 ICMP 包再套上 IP 头，然后封装成以太网帧从网卡发出去，对端收到后原路解封装再回显应答。这里有个重要的排障结论：ping 通只能验证一到三层是通的，不能证明应用正常——要验证应用得用 telnet 测端口或者 curl 看响应。反过来 ping 不通也未必是链路断，可能只是对端禁了 ICMP——这是我常踩常讲的坑，"ping 通不代表应用好，ping 不通也不代表网络断"，两边都要有替代验证手段。
• 追问3：ARP 协议是干什么的？ → 答：ARP 是地址解析协议，解决"已知同一网段的目标 IP，求它的 MAC 地址"的问题，靠广播请求、单播应答完成，结果缓存在本机 ARP 表里。排障时 arp -n 能看到网关的 MAC，如果 ARP 表里网关 MAC 不对或者学不到，说明二层就有问题，比如交换机端口没放行对应 VLAN，这时候连 ping 网关都不通。ARP 是"二层有没有问题"的第一证人，排查"连网关都不通"时我第一个看它。

9.2 三次握手与四次挥手（及原因）【必背】

标准回答：三次握手是 TCP 建立连接的过程。 第一步客户端发一个 SYN 报文，带着随机生成的初始序列号 seq=x，表示请求建立连接；第二步服务端收到后回一个 SYN 加 ACK 的报文，自己也生成一个随机序列号 seq=y，确认号是 x+1，意思是"你的请求我收到了，我也要和你建连接"；第三步客户端再回一个 ACK，确认号是 y+1，双方连接就建立了。 为什么必须是三次不能是两次？ 核心原因是双方都要确认"自己的发送能力和接收能力都正常"：两次握手的话，服务端发了 SYN+ACK 之后无法确认客户端到底收没收到，连接状态是不完整的；另外三次握手还能防止网络里滞留的历史 SYN 报文迟到之后误建连接。 四次挥手是断开的过程：主动关闭方发 FIN，对端回 ACK，对端把剩下的数据发完之后再发 FIN，主动关闭方回最后一个 ACK。 为什么断开要四次而建立只要三次？ 因为 TCP 是全双工，两个方向要分别关闭；而且被动方收到 FIN 时可能还有数据没发完，所以先把 ACK 回了、数据发完再发自己的 FIN，ACK 和 FIN 拆开就成了四次。 这套机制我在排查连接问题的时候经常用连接状态来反推：ss 看到大量 SYN_SENT 说明请求发不出去（网络或对端不可达），大量 ESTABLISHED 但应用无响应要看应用层，大量 CLOSE_WAIT 是应用没关连接的代码问题——握手挥手不是背给面试官的，是读懂 ss 输出的钥匙。

追问链：

• 追问1：TIME_WAIT 是什么状态、为什么要等 2MSL？ → 答：TIME_WAIT 出现在主动关闭方，它发完最后一个 ACK 之后不直接关闭，而是等待两倍报文最大生存期才真正释放连接。等这两个时间的原因：一是保证最后的 ACK 如果丢了，对端还能重传 FIN 过来，本端有时间重发 ACK 完成关闭；二是让这条旧连接的所有报文在网络上自然消亡，不会串到复用相同端口的新连接里污染数据。运维场景里大量 TIME_WAIT 一般是短连接高频创建导致的，比如应用没有用连接池、每个请求都新建连接，缓解办法是改长连接、用连接池——但它本身是协议的自我保护，不一定是故障。
• 追问2：大量 CLOSE_WAIT 说明什么问题？ → 答：CLOSE_WAIT 的意思是对方已经发了 FIN 过来，但本端一直没调用 close() 关闭连接。这几乎百分之百是本端应用代码的 bug——收到了关闭请求却没释放连接资源，堆积多了会耗尽文件描述符导致新连接建立不了。所以排查思路是先查应用代码而不是怀疑网络，网络只是把对方的关闭意愿带到了，没关是应用自己的事。支持岗的价值是"识别出这个形态并精确转派"：ss 统计 + 哪个进程 + 增长趋势三样证据递给开发，比一句"连接好多"专业十倍。
• 追问3：怎么快速统计服务器上的连接状态分布？ → 答：ss -ant | awk '{print $1}' | sort | uniq -c，一眼看出 ESTABLISHED、TIME_WAIT、CLOSE_WAIT、SYN_SENT 各有多少。这个命令是我巡检和排障的固定动作：CLOSE_WAIT 几百上千就拉开发查代码，TIME_WAIT 爆炸往短连接方向查，SYN_SENT 堆积说明往外连不通（目标不可达或防火墙拦截），LISTEN 数量异常要查服务是不是起了多个实例。一条命令读出四种故障形态，这就是"背握手"的实战回报。

9.3 TCP 与 UDP 的区别 【理解】

标准回答：一句话总结：要"对"用 TCP，要"快"用 UDP。 展开讲，TCP 是面向连接的协议，通信前要三次握手建立连接，传输中靠确认应答、超时重传、序列号排序保证数据可靠有序到达，还带滑动窗口做流量控制和拥塞控制，所以 HTTP、SSH、MySQL 这些要求准确的协议都跑在 TCP 上。 UDP 是无连接的，发之前不用握手，发了也不保证到、不保证顺序，头部固定只有 8 字节开销小延迟低，适合 DNS 查询、DHCP、视频流、游戏这类"丢一点没关系、快最重要"的场景。 两者的联系是都在传输层、都用端口区分应用、都依赖网络层的 IP 做实际路由。 我在运维里最直观的感受是排障方式不同：TCP 的服务可以用 telnet 直接探端口验证握手能不能完成，UDP 无连接就没法这样探，得用 nc -u 或者直接看应用日志——DNS 故障难查一半的原因就是它是 UDP。 另外 HTTP/3 和 QUIC 是在 UDP 上自己实现了类似 TCP 的可靠传输，把拥塞控制搬到应用层优化，这个趋势我有跟踪，面试聊到可以作为延伸。

追问链：

• 追问1：UDP 想要可靠怎么办？ → 答：传输层本身不管，要在应用层自己补——参照 TCP 的思路做确认应答、超时重传、序列号排序和拥塞控制，典型例子就是 QUIC 协议，它在 UDP 之上实现了接近 TCP 的可靠性，同时避免了 TCP 三次握手的延迟和队头阻塞问题。所以说可靠不可靠最终是工程取舍，不是绝对的能力边界——这个答法把"背区别"升级成"懂取舍"。
• 追问2：TCP 粘包了解吗？ → 答：知道原因。TCP 是字节流协议，不保留报文边界，发送方多次 write 的数据可能被合并成一个段发出去，接收方一次 read 可能拿到两条"消息"粘在一起。它不是 TCP 的 bug，是字节流的特性。解决办法在应用层定边界：固定长度、用分隔符，或者消息头里带长度字段。排查业务"消息错乱"类问题时要想到这一层——这类问题表象在网络，根因在应用协议设计，支持岗定位到"不是网络问题"就是有价值的结论。

9.4 常见端口 【理解】

标准回答：端口我按"天天见的"和"项目里特别记住的"两层背。 天天见的：22 SSH、80 HTTP、443 HTTPS、53 DNS、67/68 DHCP、3306 MySQL、6379 Redis、5432 PostgreSQL、3389 Windows 远程桌面、8080 常见备用 HTTP；桌面支持还要加：445 SMB 文件共享、137-139 NetBIOS。 监控容器体系：9100 node_exporter、9090 Prometheus、3000 Grafana。 K8s 体系：6443 apiserver、2379/2380 etcd、10250 kubelet、30000-32767 NodePort。 我特别记住的 16443——银行项目负载均衡和 master 复用一台机器，6443 已被 apiserver 占用，前置 Nginx 监听 16443 做代理。 记端口的价值是排障条件反射：用户报"连不上数据库"，脑子里立刻过 3306——telnet 它；用户报"远程桌面连不上"——3389 加 445；做规划时想端口冲突——监控节点上 9090 和业务端口会不会撞。 端口表就是支持岗的"座机号码本"，背熟它，报障到嘴边就能报出第一嫌疑端口。

追问链：

• 追问1：怎么查本机哪个端口被谁占用？ → 答：ss -lntp | grep :端口 一步拿到监听地址、进程名和 PID，比 netstat 快；Windows 上是 netstat -ano | findstr 端口 再 tasklist 对 PID。容器环境还要注意端口可能是被 docker-proxy 或 kube-proxy 占的，宿主机看到的进程是代理不是业务本身，这个区别排障时容易误判。桌面支持场景同理：用户报"端口被占用起不来服务"，Windows 的 netstat -ano 加任务管理器详情页就是同构操作——跨平台的同构意识是支持岗的加分习惯。
• 追问2：端口被占了，杀进程就能解决吗？ → 答：分情况。残留旧进程占着，确认无业务流量后按"先 kill -15 优雅停、等几秒不行再 -9"处理；有业务在跑的端口被规划给了新服务，要做的是改新服务的端口规划而不是硬杀。生产上动端口前先确认归属——ps 看启动命令和启动时间、lsof 看打开的文件，归属确认是变更纪律。桌面场景更常见的是"应用 A 起不来因为端口被 B 占"——先弄清 B 是谁、能不能挪，而不是条件反射杀进程，这一步判断力就是支持岗和专业用户的差别。

实操模板（端口速查清单）：

21 FTP(20数据)  22 SSH     23 Telnet  25 SMTP    53 DNS      67/68 DHCP
80 HTTP         110 POP3   143 IMAP   443 HTTPS  445 SMB     137-139 NetBIOS
1433 SQLServer  1521 Oracle  3306 MySQL  5432 PG  6379 Redis  3389 RDP
8080 HTTP备用   9100 node_exporter  9090 Prometheus  3000 Grafana
6443 K8s apiserver  2379/2380 etcd  10250 kubelet  30000-32767 NodePort
16443 银行项目 apiserver LB 端口（避开 6443 冲突）

第二部分：排查命令树（逐条讲解化，支持岗核心）

9.5 命令树总览与 ping 【必背】

标准回答：网络排查我有一套固定的命令树，从本机往对端逐层推进：ip a 看本机地址和网卡 → ip r 看路由和网关 → ping 网关 验证内网 → ping 对端IP 验证三层可达 → telnet/nc 验证四层端口 → traceroute/mtr 看路径断在哪跳 → ss 看连接状态 → curl -v 验证七层服务 → tcpdump 抓包看最终证据。 每条命令回答一个"是不是"：是不是配置了、是不是路由对、是不是三层通、是不是端口开、是不是路径断、是不是连接堆积、是不是服务响应、是不是报文交互——把模糊的"网络不通"变成精确的"断在第几层"。

ping 单独讲透：它用 ICMP 回显请求/应答验证三层可达性，读输出看四样——通不通（有 reply 就是通的）、丢包率（time= 后面的延迟值和丢包百分比，内网正常 1ms 以内，丢包大于 0 就要警惕）、延迟稳定性（ping -i 0.2 -c 50 快速发 50 个包看延迟是否抖动剧烈）、解析对不对（ping 域名时首行显示解析到的 IP，确认是不是预期地址——很多"网站打不开"其实是解析到了错误 IP）。 支持岗用 ping 的进阶姿势是"对照组法"：同时 ping 网关、ping 一个已知正常的外网地址、ping 报障目标——三个结果一对比，问题区间立刻收敛（网关都不通是本机/内网问题；网关通外网通只有目标不通是目标或路由问题）。

追问链：

• 追问1：ping 通但 telnet 端口不通，怎么继续查？ → 答：这说明三层通、四层不通，问题收敛在端口层面。按三个方向查：第一，对端服务起没起、有没有监听这个端口——登对端 ss -lntp 看；第二，监听地址是不是 0.0.0.0——很多服务默认只听 127.0.0.1，本机自测正常、外面连不上，这是超高频坑；第三，路径上的防火墙、安全组放没放行——云上环境安全组是第一嫌疑人。三步查完基本必有答案。这个组合现象（ping 通 + 端口不通）是我处理过的最高频网络形态，答的时候按"服务监听 → 监听地址 → 防火墙"顺序说，层次立刻出来。
• 追问2：ping 不通有哪些可能，怎么快速分型？ → 答：按范围分型：ping 网关都不通——本机问题（网卡 down、IP 配错、网线/VLAN 不对）或二层问题（交换机端口、ARP 学不到），先 ip a 和 arp -n；ping 网关通、ping 外网不通——路由或出口问题（默认网关错、NAT/出口故障、被 ACL 拦），查 ip r 默认路由；都通只有目标不通——目标宕机、目标禁 ICMP、中间路由拦截，用 telnet 加 traceroute 交叉验证。还有一种形态是"ping 域名不通 ping IP 通"——那是 DNS 问题直接跳 9.15。分型口诀："网关是分水岭，域名是 DNS 试金石"。
• 追问3：ping 延迟时高时低，怎么定位？ → 答：先排除本机和末端：ping 网关 稳定而 ping 对端抖，抖动在中间链路；用 mtr 跑 1-2 分钟看每一跳的丢包和延迟分布（下一节详讲），区分"某一跳抖"和"全程抖"。全程抖查本机负载和出口带宽（备份任务占带宽是常见元凶，iftop 看）；某跳开始抖，那一段链路的问题要找网络组。另外注意 ping 高延迟也可能是对端 CPU 忙不过来回包慢——结合对端负载一起判断。支持岗报"网络慢"必须有数字：平均延迟、抖动幅度、丢包率三个数，才是网络组认的工单语言。

9.6 telnet / nc：四层端口探测 【必背】

标准回答：telnet 和 nc 解决的是"ping 通了但服务到底在不在"的问题——ping 验证机器活着，telnet 验证服务端口活着，这一步是网络排查从"链路层"进入"服务层"的分界。 用法：telnet IP 端口，能连上会显示 connected 或进入黑屏光标闪烁（HTTP 服务敲两个回车可能看到响应），连不上立即报 Connection refused 或长时间挂起超时；nc 更好用：nc -zv IP 端口，-z 只探测不发数据、-v 显示过程，nc -zv IP 3306 返回 succeeded 就是通的。 读结果的三种形态要背下来：秒拒（Connection refused）——网络可达但端口没人听，查服务进程和监听；超时挂起——包被防火墙 DROP 或对端不可达，查防火墙规则和中间链路；连上但马上断——服务在听但应用层拒绝（白名单、认证），要看应用日志。

这个命令是我支持工作的日活工具：数据库连不上先 telnet 3306、web 打不开先 telnet 443、SSH 上不去先 telnet 22——一条命令把"网络问题"和"服务问题"切开，两秒钟给用户一句"网络是通的，是服务没起"或"根本到不了对方机器"。 Windows 环境同样可用（telnet 客户端要启用，或用 Test-NetConnection IP -Port 端口），跨平台一致性让它在桌面支持场景同样好使。

追问链：

• 追问1：telnet 被淘汰了吗？为什么还在用？ → 答：作为远程登录协议确实被 SSH 取代了（明文传输不安全，23 端口应该封掉），但作为端口探测工具它是轻量标准——几乎所有系统自带，不用安装。更现代的选择是 nc -zv 和 curl -v telnet://IP:端口，还有 PowerShell 的 Test-NetConnection。我用 telnet 主要因为它"到处都有"：客户机器、堡垒机、临时环境，随取随用——支持岗选工具的第一原则是"在任何现场都能立刻用起来"，其次才是优雅。
• 追问2：telnet 通了就代表服务正常吗？ → 答：不代表，telnet 只证明 TCP 三次握手能完成（端口有人听），不证明应用逻辑正常——应用可能假死、可能内部连不上数据库、可能返回 500。所以完整验证是三层递进：telnet 通（四层）→ curl -v 看 HTTP 响应码和响应体（七层）→ 业务功能实测（用户真实操作）。我在银行现场的标准动作是 telnet 后必跟 curl，"端口通 + 响应对"才敢跟用户说"服务正常"。这个递进意识能避免"我以为好了其实没好"的二次报障——二次报障对支持岗信誉的伤害远大于第一次。

9.7 traceroute 与 mtr：路径定位 【必背】

标准回答：traceroute 和 mtr 解决"通不通"之外的第三个问题：断在哪、慢在哪一跳。 traceroute 原理是利用 TTL：发出 TTL=1、2、3…的探测包，每个路由器把 TTL 减到 0 时回 ICMP Time Exceeded，于是逐跳暴露路径；读到某一跳开始全是 * * * 星号就是从那一跳之后断了或被拦截。 mtr 是 traceroute 的增强版，结合 ping 持续发包，实时显示每一跳的丢包率和延迟——mtr -n 目标IP 跑一两分钟，看 Loss%、Avg、Best/Worst 列。 mtr 比 traceroute 强在能看出"丢包丢在哪一跳、延迟在哪一跳跳起来"，而且能识别假丢包：某一跳显示 100% 丢包但后续跳全部正常，说明那台路由器只是不响应 ICMP 探测（限速或策略），转发是正常的——判断真丢包的标准是"从某一跳开始，它和它后面的所有跳都丢"。

支持场景的用法：用户报"访问某系统时快时慢"，traceroute 看路径有没有绕远（走了不该走的路由）、mtr 看丢包和抖动集中在哪一段——出内网边界就抖是运营商链路，最后一跳抖是对端服务问题，全程轻微抖可能是本机或 WiFi。 这两个工具给"网络慢"提供量化证据，是网络工单里"我这边没问题/问题在链路"这类归属判断的依据。

追问链：

• 追问1：mtr 某一跳丢包 100% 但后面正常，能下结论吗？ → 答：不能，这是假丢包——该跳路由器不响应 ICMP 但正常转发流量，真实业务流量不受影响。判断标准：从某一跳开始，它及之后所有跳都丢，才是那一跳或之后的链路真有问题；只有单跳丢、后面恢复，看后续跳的丢包率是否也可接受。这个细节能讲出来，说明真用过 mtr 而不是背名词——把假丢包当成结论去和网络组扯皮，是要被专家当场纠正的，所以这条我背得很牢。
• 追问2：traceroute 每一跳都显示 *，怎么理解？ → 答：两种可能：整条路径禁 ICMP/UDP 探测（很多运营商骨干对 traceroute 默认协议做策略），可以换 traceroute -T -p 443 用 TCP 探测目标端口——TCP traceroute 的探测包长得像正常业务流量，穿透率高得多；或者真的链路不通，结合 ping 和 telnet 交叉确认。经验是"默认 traceroute 看不到路径不代表网络坏，先换 TCP 模式再下结论"——工具的默认行为有盲区，知道盲区在哪才不会被误导。

9.8 ss：连接与监听状态 【必背】

标准回答：ss 是支持岗在服务器上排网络问题的"显微镜"，我按三组用法讲。 第一组看监听：ss -lntup——l 监听、n 不解析名字（快且避免 DNS 干扰）、t TCP、u UDP、p 显示进程，一屏回答"哪些端口在听、听在哪个地址、被哪个进程占着"；重点读监听地址列：0.0.0.0:8080 是对所有地址服务，127.0.0.1:8080 是只对本机服务——"外面连不上本机自测正常"的九成答案就在这一列。 第二组看连接：ss -ant 配 awk '{print $1}' | sort | uniq -c 统计状态分布——ESTABLISHED 多是正常业务，TIME_WAIT 大量是短连接、CLOSE_WAIT 大量是应用不关连接、SYN_SENT 堆积是往外连不通，四种形态四种方向（9.2 的实战应用）。 第三组看水位和定位：ss -s 汇总连接总数和各状态量；ss -ant state established '( dport = :3306 )' 按目标端口过滤，数某服务的活跃连接数——数据库连接数、Redis 连接数、到负载均衡的连接水位都是这么数的。

ss 替代 netstat 的理由要说一句：netstat 遍历 /proc/net 全表，连接数大时慢；ss 直接读内核 socket 缓存，几万连接也是秒出。 我巡检脚本里的网络项全是 ss——快，还不用装包。

追问链：

• 追问1：怎么用 ss 排查"服务对外不可达但进程在"？ → 答：三连动作：ss -lntp | grep 端口 看有没有监听——没有就是服务内部绑定失败，查服务日志；有监听但地址是 127.0.0.1——改成监听 0.0.0.0 或具体内网 IP 后重启服务；有监听地址也对——问题在防火墙或上游链路，转 iptables/安全组方向。这个三连是"进程在但连不上"的标准分解，每一步都把可能性砍掉一半。我给同事培训时说：ss -lntp 是网络排障的第一条命令，它把"服务有没有认真在等请求"这个最基本的事实摆在眼前。
• 追问2：怎么统计某个服务当前的连接数并找到连接来源 TOP？ → 答：ss -ant state established '( dport = :3306 )' | awk '{print $4}' | cut -d: -f1 | sort | uniq -c | sort -rn | head——按目标端口过滤 established 连接，取源地址统计 TOP，几秒内知道"哪些机器占着最多连接"。这个组合在连接数满的场景（第 3 章 3.6）是定位元凶的利器：哪个应用服务器开了几百条连接一目了然，比登数据库里 processlist 更快——两个视角（OS 层 ss 和数据库层 processlist）互相印证，归因就有双证据。

9.9 tcpdump：抓包取证 【必背】

标准回答：tcpdump 是网络排查的终点站——前面所有命令都定位不了时，抓包看两台机器之间到底有没有报文、交互到哪一步卡住，这是终极证据。 我的标准用法：tcpdump -i eth0 -nnn host 对端IP and port 端口——-i 指定网卡、-nnn 不做地址端口反解析（输出干净且不因反解拖慢）、host+port 过滤把流量缩到最小；保存分析用 -w file.pcap 抓下来用 Wireshark 打开。 读抓包输出我按"Flags 讲故事"：正常连接是三次握手三行——Flags [S] 客户端 SYN、[S.] 服务端 SYN+ACK、[.] 纯 ACK；数据传输是 [P.]（带数据推送）和对应 ACK；断开是 [F.] FIN 序列。 异常形态认三种：只见 SYN 没有回包——请求根本没到对端或被丢弃，查中间链路和防火墙；回 [R]（RST）——连接被强制重置，握手阶段 RST 通常是端口没人听或被防护设备切断，established 之后 RST 多是防护干预或进程崩溃；大量重传（相同 seq 反复出现）——链路质量差或对端处理不过来。

支持场景里 tcpdump 的典型三问：到底有没有数据交互（"对方说发了，我这边没收到"——抓包一锤定音）；TLS 握手卡在哪一步（ClientHello 发出后对端无响应还是直接 RST——区分网络断和服务拒）；丢包重传发生在哪——配合时间戳和应用日志对齐。 抓包纪律：先窄过滤后宽，一上来全量抓会把自己淹死；抓完记得停（Ctrl+C），-w 文件按规范命名留档进工单。

追问链：

• 追问1：抓包怎么过滤只看某个端口的流量？ → 答：BPF 过滤表达式：tcpdump -i eth0 tcp port 6443 -nnn 只看该端口 TCP 包，加 host IP 限定对端、and 组合多条件、not port 22 排除干扰（否则自己的 SSH 流量刷屏）。先窄后宽的原则：精确过滤定位问题，什么都没抓到再逐步放宽条件——抓包最大的失败不是抓不到，是抓了一堆无关流量看不出重点。
• 追问2：抓包看到 RST 一般是什么原因？ → 答：三种常见来源：目标端口没有进程监听，内核直接回 RST 拒绝——配合 ss -lntp 在对端确认；安全设备或防火墙主动切断连接——RST 的 TTL 和来源 IP 可能异常，内网防护设备行为；应用异常退出时内核替它发 RST。区分方法：RST 出现在握手阶段多半是端口没人听或被拦，出现在 established 之后多半是防护设备干预或进程崩溃——结合 ss 看监听状态和应用日志时间点就能定位。我处理过 apiserver 连接问题的抓包分析：ClientHello 后对端 RST，最终定位是中间安全设备拦截，这类"服务都配置对了但连不上"的悬案，只有抓包能给最终答案。

9.10 curl 与 DNS 排查（dig / nslookup）【必背】

标准回答：curl -v 是七层验证的标准工具，curl -v https://域名/路径 的输出我按四段读：DNS 解析段（解析到哪个 IP——错误 IP 直接暴露 DNS 或 hosts 问题）、TCP 连接段（Connected to 哪个 IP:端口——连不上是网络层）、TLS 段（证书 subject、有效期、是否验证通过——证书问题在这里现形）、HTTP 段（状态码、响应头、响应体——应用层答案）。 -k 跳过证书校验可以做对照：加 -k 通、不加 -k 报证书错，问题锁定在证书链；--resolve 域名:443:指定IP 可以绕过 DNS 强制访问指定节点，验证"是解析问题还是节点问题"。 DNS 工具一对：nslookup 简单直接问"这个域名解析到哪"，dig 更专业——dig 域名 +short 精简结果、dig @223.5.5.5 域名 指定 DNS 服务器对比（本地 DNS 有问题换公共的立刻能验证）、dig -x IP 反向解析。 本机 DNS 配置看 /etc/resolv.conf（Windows 看 ipconfig /all 的 DNS 服务器项）。

DNS 故障的经典判据必须背：ping IP 通、ping 域名不通 = DNS 问题——经典应用题"QQ 能登录但网页打不开"就是这个形态：QQ 走 IP 直连不依赖 DNS，网页必须先解析，答案秒出。 DNS 应急三板斧：换公共 DNS（223.5.5.5、114.114.114.114）、改 hosts 临时指路、清本机 DNS 缓存（ipconfig /flushdns、systemd-resolve --flush-caches）。

追问链：

• 追问1：怎么判断一个"访问不了"是 DNS 的问题？ → 答：两步验证：第一步 dig 或 nslookup 这个域名，看能不能解析出 IP、解析出的 IP 对不对；第二步直接 ping 解析出来的或已知的 IP。dig 失败但 ping IP 通——问题在解析环节，查本机 DNS 配置和 DNS 服务器；dig 成功但 ping IP 不通——问题在链路或对端。再加一个进阶判断：dig 指定公共 DNS 能解析、默认 DNS 不行——本地 DNS 故障或污染，应急换 DNS。这套"解析与连通分离验证"的方法，是把"打不开"这个模糊报障三分钟能出方向的核心手段。
• 追问2：curl 能通但浏览器打不开，查什么？ → 答：说明服务端和网络是通的，问题在客户端侧，按序排查：浏览器代理设置——内网环境常要配代理，配置错误就全挂（对照"能通的 curl"是不是走了不同出口）；本机 hosts 有没有过期劫持记录——ping 域名看解析出的 IP 对不对；浏览器缓存和插件——无痕模式一试便知；证书信任——企业内部 CA 证书没导入浏览器信任库。方法是"用已知干净的客户端对照"，把变量隔离掉——分层排障思想在应用层的延伸。桌面支持场景这个题是日活：用户"打不开"十有八九是代理、hosts、缓存三件套，工具化对照十分钟收工。

9.11 网络类工单处理流程（五步闭环）【必背】

标准回答：网络类报障我按五步闭环处理，这套流程是我驻场银行两年和"记录—处理—转派—跟踪—闭环"工单机制结合的落地版。 第一步接到报障：信息收集要一次问全——五要素：谁（哪个部门哪些用户）、什么现象（完全不通/时断时续/慢）、从什么时候开始、错误提示或截图、有没有做过什么操作（改配置、搬工位、新装软件）。 问全这五项能省掉一半来回，我的习惯是给用户一个标准模板让他们填，报障质量立刻提升。 第二步定位层级：按命令树收敛——本机配置（ip a/ipconfig、路由、DNS）→ 内网连通（ping 网关、ping 其他内网资源）→ 出口连通（ping 公网、traceroute）→ 目标端口（telnet）→ 目标服务（curl）；每一步结论记进工单，收敛到"断在第几层"。 第三步处理或转派：本机层问题（IP 冲突、DNS 配错、代理设置、 hosts 劫持）我自己处理；主机和服务层问题按 01/03/04 章路径处理；链路层和交换机层问题转网络组——转派必须带"已排查证据包"（做了什么、结果是什么），不让二线从零开始。 第四步跟踪：转派不是结束，我在工单里盯状态、定时间点跟催、有新信息及时补充给二线——用户只认"问题找我的人"，支持岗要对闭环负责而不是对转派负责。 第五步闭环复盘：解决后和用户确认验证、工单记录根因和解法、高频问题沉淀进 FAQ/知识库、必要时更新巡检项——闭环的标志不是"我修好了"，是"下次这类问题不用再找我"。

追问链：

• 追问1：用户报"上不了网"，你的完整处理顺序？ → 答：先收集五要素，然后按分型走：先看范围——一个人还是一片人，一个人的问题查本机（网卡、IP 获取、DNS、代理、hosts），一片人的问题查公共层（交换机端口、DHCP、出口设备）；本机排查固定动作：ipconfig /all（Windows）或 ip a 看 IP 拿没拿到、是不是 169.254.x.x 自动私有地址（DHCP 失败的标志，见 9.14）、ping 网关、ping 223.5.5.5（出口通不通）、nslookup（解析通不通）、查浏览器代理。三分钟内基本能定位到"本机配置/DHCP/DNS/出口"四类之一。这个题是网络支持岗最高频的实操题，答的关键是"先问范围再动手 + 固定动作链"，显出流程感。
• 追问2：问题定位在链路层需要转网络组，转派单怎么写才算合格？ → 答：我的转派包四件套：现象描述（报障原文、时间点、影响范围）、排查证据（我做过什么、每步结果——ping/telnet/traceroute 的输出摘要）、已排除项（明确写"本机配置正常、DNS 正常、出口可达，问题在 X 到 Y 之间的链路"）、影响与紧急度（多少人、什么业务、有没有替代方案）。核心思想是"把收敛后的区间递出去"：二线拿到不用重复我的工作，直接从 X-Y 区间开工——转派质量决定闭环速度，这是我两年协同华为原厂磨出来的经验，写进了 SOP。
• 追问3：网络问题反复出现，怎么减少重复工单？ → 答：三层动作：短期把本次解法写进 FAQ（知识库），同类报障引导用户自助；中期看共性——同一类问题月超三次就要查根源（网口老化、配置漂移、软件冲突），从根上修；长期把检查自动化——把高频检查做成自检脚本或自助页面，用户跑一下就知道问题在哪一层。我在公司内部 IT 的实践是"重复问题知识库化"：办公网断连的自检指南、打印机自助排查页上线后，这类工单量明显下降（对应简历职责运-3 建设维护 IT 知识库 SOP）——支持岗的进阶是从"修得快"到"让问题不再发生"。

9.12 典型网络工单场景速答 【必背】

• 场景一：云上服务突然访问不了，怎么排查？ → 答：云上排障顺序和机房不同，第一嫌疑人是配置而不是线缆。我的三步：先查安全组和网络 ACL 有没有最近变更——云上大量"突然不通"是变更引起的，控制台看变更记录；再查实例和监听——登机器 ss -lntp 看服务在不在、监听是不是 0.0.0.0；最后查负载均衡健康检查状态——后端被摘除流量自然断。传统 ping/traceroute 放最后，因为云上"逻辑网络配置"远比"物理链路"容易出问题。这套"配置 → 实例 → 入口"的顺序是我项目二日活的总结。
• 场景二：部分用户访问某系统慢，其他系统正常？ → 答：差异定位法：慢的是同一批人还是随机——同一批人查他们的共同路径（同一办公区交换机、同一 VPN 出口、同一代理）；随机分布查系统侧。对照实验：慢的用户 ping/telnet 目标系统，拿正常用户做对照，比较延迟和路径（mtr）——差异段就是问题段。还要查时间相关性：是不是高峰时段才慢（带宽饱和、并发瓶颈）。产出必须是数字：延迟多少、丢包多少、正常对照多少——带数字的归因才能推动网络组或应用组接单。
• 场景三：服务器之间内网互 ping 丢包，业务偶发超时？ → 答：按层收敛：先 mtr 跑两分钟看丢包集中在哪一跳——本机网关内丢是主机/交换机问题，跨设备段丢是链路问题；同网段和跨网段分开测（VLAN 间路由问题 vs 纯二层问题）；交换机侧 display interface brief 看端口 CRC 错包和流量（错包持续增长是线缆/光模块/网卡硬件劣化的标志）；还要排除人为负载——备份、大文件传输把链路打满。我银行项目处理过类似问题，最终定位是光模块劣化 CRC 增长——"错包计数"是硬件层问题的金标准指标。

第三部分：VLAN / DNS / DHCP 故障场景

9.13 VLAN 原理与故障场景 【必背】

标准回答：VLAN 是在交换机上把一个物理局域网逻辑划分成多个广播域的技术。 为什么需要它：第一隔离广播风暴——没有 VLAN 时一个二层网络所有设备共享广播域，设备一多广播互相干扰；第二安全隔离——不同部门流量二层就隔开；第三灵活——按业务分组改 VLAN 配置就行，不用重新布线。 关键技术点：不同 VLAN 之间二层不通，要互通必须经过三层设备——三层交换机的 VLANIF 接口做各 VLAN 网关，或路由器单臂路由。 端口类型两种必须分清：Access 口接终端设备，只属于一个 VLAN，收发不打标签；Trunk 口用在交换机之间或接服务器，一条链路承载多个 VLAN，靠 802.1Q 在帧上打 4 字节标签区分。 虚拟化场景是两者组合：物理交换机口起 trunk 放行多个 VLAN，虚拟化平台分布式交换机端口组绑定 VLAN ID——银行项目我在 FC 上配端口组，和网络团队的交换机 trunk 配置按同一张规划表施工验收。

VLAN 故障场景三类必须会讲：新接终端不通——端口 access VLAN 配错或没配（接进了错误网段），display vlan 和端口配置核对；跨交换机不通——级联口 trunk 没放行对应 VLAN（一端 trunk 一端 access 最危险，轻则不通重则串 VLAN），两端 display port vlan 核对放行列表一致；ping 网关不通但同 VLAN 内通——VLANIF 网关配置或 VLAN 划分不一致，arp -n 看网关 MAC 学没学到。 预防动作是"规划表施工 + 两端互检 + save"（华为设备不保存重启全丢）。

追问链：

• 追问1：银行项目的管理面和业务面怎么隔离的？ → 答：每台服务器双平面：管理 IP 和业务 IP 分开，分别接不同交换机或不同 VLAN，管理流量和业务流量隔离；再加第三张网——BMC 带外管理网接 iBMC 管理口。三张网互不抢带宽，业务网打满也不影响管理操作和带外救机器。这是我最扎实的一次平面隔离实践，后来移动云安全组分层设计也是同一隔离思想——隔离的思想是通用的，载体从 VLAN 换成了安全组。
• 追问2：怎么定位环路和广播风暴？ → 答：先看现象：所有端口流量同时异常打满、交换机 CPU 升高、ping 大面积超时抖动。用 display interface brief 看哪个口流量异常、有没有大量广播包和 CRC 错包，检查是不是有口被误接成环路。防的办法是交换机配 STP 生成树协议，阻塞冗余路径自动破环，故障时自动切换。银行组网里管理和业务双平面分开、各自独立组网，天然减少了环路面。环路的特点是"突发且全局"，和单点故障的"局部且持续"形态不同——现象形态本身就是分型依据。

实操模板（CE 基础配置，详见华为篇 07，此处背骨架）：

system-view
sysname SW-MGMT-01
vlan batch 10 20                          # 批量建 VLAN
interface 10GE1/0/1
 port link-type access
 port default vlan 10                     # 接终端
interface 10GE1/0/24
 port link-type trunk
 port trunk allow-pass vlan 10 20         # 级联口放行
interface Vlanif 10
 ip address <管理IP> <掩码>               # 三层网关
quit
save                                      # 必须！不保存重启全丢
# 诊断: display interface brief / display vlan / display mac-address / display lldp neighbor brief

9.14 DNS 故障场景 【必背】

标准回答：DNS 故障是"打不开"类报障里最常见又最容易被误判的一类，我把三个典型场景讲透。 场景一：全部域名解析失败——本机 DNS 配置错误、DNS 服务器宕机、网络根本不通，排查顺序：nslookup 看报错形态（超时是服务器不可达，refused 是被拒绝）、cat /etc/resolv.conf 或 ipconfig /all 看配置、dig @223.5.5.5 对比公共 DNS 能不能解析——公共的行、内网的不行就是内网 DNS 服务器问题，转 DNS 服务负责人。 场景二：部分域名解析错误（污染或劫持）——解析出的 IP 不是预期值，dig 对比不同 DNS 服务器的答案、dig +trace 看解析链路，常见于内网 DNS 缓存了旧记录或域名刚变更没同步，处理是清 DNS 服务器缓存（或等 TTL 过期）、必要时改 hosts 应急。 场景三：解析慢——能开但等很久，第一个 DNS 服务器超时后才用第二个，resolv.conf 里配了不可达的 DNS 就会这样；nc 探测 DNS 服务器的 53 端口延迟，把不可用的 DNS 从配置里摘掉。 应急三板斧统一：换公共 DNS、改 hosts、清缓存（ipconfig /flushdns / systemd-resolve --flush-caches）。

支持岗要建立的意识是：DNS 故障的现象永远是"间接的"——用户说"打不开"，实际是解析环节断了；而 DNS 又是 UDP 53，没有 telnet 式的直观探测，所以要靠 dig/nslookup 的对比测试。 "解析问题还是链路问题"是这类工单的第一个分叉，dig 和 ping IP 的组合一测便知。

追问链：

• 追问1：内网自建 DNS 和公网 DNS 的选择怎么讲？ → 答：内网环境用内部 DNS 有三个理由：解析内部域名（外网 DNS 根本不知道）、按安全策略控制可解析范围、解析内网服务的私有地址。公网 DNS（223.5.5.5 等）用于应急验证和纯公网需求。我在银行内网的环境全部走内部 DNS，遇到解析异常先用 dig @公共DNS 做对照——能区分"内网 DNS 坏了"还是"域名本身有问题"。这个"对照法"是 DNS 排障的核心手法，比背协议流程更实用。
• 追问2：DNS 的递归查询和迭代查询区别？ → 答：递归是"你帮我问到底"——客户端把问题交给本地 DNS，它必须返回最终答案，中间过程客户端不参与；迭代是"我告诉你去问谁"——本地 DNS 问根服务器，根不替它查而是指路给顶级域，本地 DNS 自己一步步问过去，最后从权威 DNS 拿到答案。客户端对本地 DNS 是递归，本地 DNS 对上游是迭代。面试说出"两个关系的组合"比单背定义清楚；支持场景里这个知识的用处是理解"本地 DNS 是解析质量的枢纽"——它坏了、慢了、缓存脏了，全网都遭殃，所以内网 DNS 服务器的监控和冗余值得投入。

9.15 DHCP 故障场景 【理解】

标准回答：DHCP 是自动分配 IP 的协议，交互四步要会讲：客户端广播 DHCPDISCOVER 发现消息 → 服务器回 DHCPOFFER 提供候选 IP → 客户端选一个发 DHCPREQUEST 请求确认 → 服务器回 DHCPACK 确认，带 IP 和租约期限（默认 8 天，租约一半时间点客户端会尝试续租）。 私有地址是 RFC1918 三段：10.0.0.0/8、172.16.0.0/12、192.168.0.0/16，出公网要 NAT。 支持场景的 DHCP 故障三形态：拿不到地址——Windows 上表现为 IP 是 169.254.x.x（自动私有地址，APIPA），原因按序查：网线/端口通不通（物理层）、所在 VLAN 里有没有 DHCP 服务可达（跨网段要 DHCP 中继）、DHCP 服务器地址池是否耗尽（办公网典型：设备数超过池容量，表现是"新来的设备上不了网，老设备正常"）；拿到错误网关或错误 DNS——网络里私接了路由器当 DHCP 服务器，终端拿到它分的错误配置，防法是交换机配 DHCP Snooping：接终端的口设非信任口、只信任上联 DHCP 服务器的口，非信任口的 OFFER 直接丢弃；租约相关间歇断网——租约到期续租失败的窗口，查 DHCP 服务器可用性。

我的边界口径要诚实：DHCP 的四步交互和故障形态是课程实验加办公网支持的真实理解，云上环境 ECS 的内网 IP 是 VPC 静态规划分配不走 DHCP（项目二我按节点角色规划固定 IP），两边场景我都接触过，讲得出各自适用面。

追问链：

• 追问1：用户电脑 IP 是 169.254.x.x，说明什么、怎么处理？ → 答：169.254.0.0/16 是 APIPA 自动私有地址——客户端等不到 DHCP 响应时自己给自己配的地址，此时只能和同网段其他 APIPA 设备勉强互通，上不了正常网络。处理顺序：先物理层（网线、端口灯、VLAN 口配置）、再确认同网段其他设备是否正常（都异常就是 DHCP 服务或中继问题，只有他异常就是他机器或端口问题）、本机 release/renew 重试（ipconfig /release + /renew）、查本机是否配了静态 IP 冲突。这个 IP 形态是桌面支持岗的"常识指纹"，看到 169.254 立刻知道方向是 DHCP 链路而不是别的。
• 追问2：办公网有人私接路由器导致部分同事上不了网，怎么处理？ → 答：现象是部分设备拿到错误网关（私接路由器的 LAN 地址），只能访问私接路由器后面的假网络。处理三步：定位——ipconfig /all 看异常设备的网关和 DHCP 服务器地址，通常是 192.168.x.1 这类家用路由默认值，按网关 ARP 定位接入位置（交换机 MAC 地址表找到端口）；隔离——拔掉私接设备或关其 DHCP 功能；加固——交换机开 DHCP Snooping，非信任口丢弃 OFFER 报文，从架构上杜绝。这是二层安全的经典案例，答出来体现"知道现象背后的协议机制"，比"重启就好了"高一个层次。

第四部分：云网络与安全（保留压缩）

9.16 VPC、子网与安全组 【理解】

标准回答：这三个是云上网络的骨架，从大到小说。 VPC 虚拟私有云是云上逻辑隔离的私有网络空间，VPC 之间天然隔离，网段自己定义——项目二我用一个 C 类网段跨三个可用区部署了整个集群。 子网是 VPC 内部按可用区再切分的网段，云资源都创建在某个子网里。 安全组是实例级的有状态虚拟防火墙，挂在 ECS 网卡上，默认拒绝一切入站，要访问必须显式加规则；"有状态"指入方向放行的连接，响应出站自动允许，不用写回程规则——和网络 ACL（子网级、无状态、进出各写各的）的区别是必考点。 一句话分工：VPC 和子网管"网络怎么组"，安全组管"谁能访问我"。 项目二的安全组按角色分组：管控面只放行跳板机网段访问 6443 和 22，业务面按"入口到应用到数据库"链路式放行，默认全拒，变更走审批。 这套最小权限规划方法换哪家云都适用。

追问链：

• 追问1：安全组规则变更怎么管理才不出事故？ → 答：三个纪律：变更走申请审批有工单记录；改前把原规则导出备份；一次只改最小范围并验证后再收尾。安全组配错的影响是即时的全局的——误放行 0.0.0.0/0 到数据库端口就是暴露公网。我把安全组当高危变更管理，绝不随手点；这也呼应支持岗"配置类变更留痕可回滚"的通用纪律。
• 追问2：云上 K8s 节点 NotReady 会和网络配置有关吗？ → 答：会，安全组配错是云上 K8s 节点 NotReady 的常见根因之一：节点互通要放行 6443（apiserver）、2379/2380（etcd）、10250（kubelet）、NodePort 段 30000-32767，还有 Flannel VXLAN 的 8472/UDP——端口没放行节点注册不上、健康检查过不去。我排查 NotReady 的固定动作里就有"核对安全组放行列表"，和镜像拉取失败（CNI Pod 起不来）并列为两大先查项——云环境的网络故障一半是"配漏了"而不是"坏了"。

9.17 ECS、CLB、NAT 网关与 EIP 【理解】

标准回答：这四个是项目二的云资源主力。 ECS 弹性云服务器就是云上虚拟机，项目二开了 7 台（3 master、3 worker、1 监控），跨三个可用区做机房级故障隔离。 CLB 负载均衡是流量入口：四层直接转发 TCP/UDP 报文，性能好延迟低透传源 IP，适合数据库和 TCP 服务——apiserver 统一入口就是 CLB 四层监听 6443，健康检查自动摘除故障 master；七层能按域名 URL 路由、终止 TLS，适合 Web 入口。 一句话：四层管"转发"，七层管"内容"。 NAT 网关解决"VPC 里没有公网 IP 的资源怎么出公网"：SNAT 把内网主动出站的流量源地址换成 NAT 网关绑定的 EIP；EIP 是独立弹性公网 IP 可绑可解。 项目二的设计是出入口收敛：出方向统一 NAT 网关、入方向统一 CLB、管理入口统一跳板机——所有流量有明确的道，审计和排障都简单。 SNAT 管出去、DNAT 管进来，这一句话的区分要能随口讲。

追问链：

• 追问1：apiserver 入口为什么用四层 CLB 不用七层？ → 答：kubectl 和集群组件连 apiserver 走 TCP 上的 TLS 长连接，不需要按 URL 路由和改写头这些七层能力；四层转发性能更好延迟更低，健康检查直接 TCP 探 6443 简单可靠。只有需要按 HTTP 路径分流或卸载证书的 Web 流量才值得七层——"按需要选层"比"七层更高级所以选七层"专业。
• 追问2：云上为什么用 CLB 不自建 Nginx+Keepalived？ → 答：我两种都真实做过，对比有说服力：银行内网没有云 LB 可用，我自建 Nginx+Keepalived VIP 漂移，自己维护健康检查脚本、防脑裂、管 VIP；云上 CLB 是托管多可用区高可用、无单点、健康检查自动摘除是平台能力。结论：云上首选托管服务，把精力留给业务；自建能力我在内网验证过，两边原理相通——这个对比是支持岗"双环境经验"的最好展示。

9.18 华为 CE 交换机操作与 HTTPS 证书 【理解】

标准回答：CE 系列是数据中心级交换机，银行项目我真实配置过（管理/BMC 网 CE6856HI、业务网 CE6863）。 操作五件套流：console 或带外登入 → system-view 进系统视图 → sysname 改名 → vlan batch 建网 VLAN → 端口划 VLAN（access 接终端、trunk 级联放行）→ VLANIF 配管理地址 → save 保存（华为设备不保存重启全丢，这是我每次配置完必做、巡检也查的动作）。 诊断四命令：display interface brief 看端口状态和收发流量、display vlan 看划分、display mac-address 看 MAC 学习、display lldp neighbor brief 看上下联设备——定位物理连接特别有用。 配置细节和堆叠等深层内容详见华为篇 07 章，我按"操作与诊断层"掌握。

HTTPS 与证书：HTTPS 是 HTTP 跑在 TLS 上，握手阶段非对称加密完成身份验证（证书是否可信 CA 签发、域名对不对）和密钥协商，之后对称加密跑数据——"非对称解决信任和密钥交换，对称解决传输性能"。 运维视角记四件事：TLS 终止点通常在 Nginx 或 LB；SAN 字段决定证书对哪些域名 IP 有效（我踩过 certSANs 的真实坑）；有效期要有告警和续期规范（30 天/7 天两级）；自签证书要分发 CA 链到信任端。 排查命令：openssl x509 -in 证书 -noout -dates 看有效期、-text 看 SAN、openssl s_client -connect 域名:443 远程探测线上生效证书。

追问链：

• 追问1：等保合规对支持岗的日常有什么影响？ → 答：直接影响四块日常：日志留存不少于六个月（logrotate 归档策略按此设计）；账号权限最小化加定期审计（离职回收、休眠清理）；通信加密（生产系统 HTTPS、证书管理）；安全配套（WAF 防应用层攻击、DDoS 防流量、主机安全做基线和入侵检测、数据库审计留痕）。我的角色口径是"配置管理者"：这些服务的策略配置、放行配合、证据提供我真实做过，攻防专家不是我的定位——诚实边界反而稳。等保三级以上每年测评，配合测评提供材料也是支持岗的实际工作之一。
• 追问2：WAF、防火墙、DDoS 防护三者怎么区分？ → 答：看层次：传统防火墙在三四层，管 IP 和端口通不通；WAF 在七层，管请求内容恶不恶意——SQL 注入、XSS、CC 高频请求这些它才看得到；DDoS 防护管流量规模，防带宽和连接被冲垮。三者互补：一个对外业务通常防火墙做访问控制、DDoS 保带宽、WAF 保应用。WAF 误杀正常请求的处理顺序我也实践过：先看拦截日志定位命中规则 → 精确加白（到 URL/参数/规则 ID，不整类关闭）→ 业务验证，上线先观察模式再切拦截——这套顺序在项目二业务发布放行时真实走过。

9.19 路由基础、默认网关与子网划分（速答）【理解】

标准回答：路由的本质是"查路由表、按最长前缀匹配、决定下一跳"。 路由来源三类：直连路由——接口配了 IP 自动生成；静态路由——管理员手工配置，简单可控但不自适应；动态路由——OSPF 这类协议在设备间自动同步拓扑。 特殊的默认路由 0.0.0.0/0 掩码最短、优先级最低，专门兜底匹配所有未知目的地——服务器和出口设备必配，否则访问任何没有明细路由的地址直接丢包。 服务器上排查动作：ip r 看路由表和默认网关、ping 网关 验证默认路由通不通、临时加路由 ip route add 目标网段 via 网关。 "同网段通、跨网段不通"第一件事就是看默认网关和路由表——这个分型在 9.5 的 ping 分型里反复用到。 子网划分用一道必背题讲方法：把 192.168.0.0/24 划成每个子网至少容纳 50 台主机——50 台需要主机位至少 6 位（2 的 6 次方减 2 等于 62），从主机位借 2 位做子网位，掩码 /26 即 255.255.255.192，得到 4 个子网，每个 62 个可用地址；注意每个子网的头尾不可用：网络号是主机位全 0、广播地址是主机位全 1（第一个子网的广播是 .63）。

追问链：

• 追问1：/26 子网的广播地址怎么快速算？ → 答：记"块大小"口诀：/26 的块是 64，子网网络号加块大小减 1 就是广播地址——192.168.0.0/26 的广播是 0+64-1=.63，可用范围 .1 到 .62。这套口诀对 /25（块 128）、/27（块 32）、/28（块 16）通用，现场算网段几秒钟。支持岗被现场考子网划分的概率不低，口诀加一道例题就够应对，再深就是网络工程师的范畴了。

9.20 双云产品对照与"换云"话术（移动云↔阿里云）【理解】

标准回答：我的双云经验一句话：概念同构、命名不同、方法论可迁移。 对照着说：云服务器两家都叫 ECS；负载均衡移动云叫 CLB，阿里云叫 SLB/ALB；私有网络都叫 VPC；云数据库对应 RDS；对象存储移动云 EOS 对阿里云 OSS；容器服务移动云 ACK 对阿里云 ACK。 因为阿里云是国内云计算的事实标准，各家云的概念模型基本照着这套来的，所以换云的成本不在概念而在三件事：控制台操作习惯要重新熟悉、API/SDK 命名有差异、软件源和镜像源地址要换。 支持岗被问"来了我们用的是 XX 云怎么办"，我的回答分两层：操作层一两天上手——我两朵云都在真实操作，控制台这类界面学习不是门槛；方法论层直接复用——安全组矩阵怎么做最小权限、出入口怎么收敛、资源怎么按角色规划，这套东西和厂商无关，是我做项目二时沉淀的。 另外我简历上的 AI 工具链（阿里云百炼、Cherry Studio）本身就在阿里云生态里日常使用，阿里云对我来说不是零接触的陌生云。

追问链：

• 追问1：两朵云有没有遇到行为不一致的地方？ → 答：有，最典型的是镜像源和配套服务目录：不同云的公共镜像源地址不同、可用的托管服务清单不同——某些中间件托管一家有另一家没有。我的处理办法是建设方案里把"依赖的云服务清单"列出来，换云时逐项对照，缺的自己部署补齐；配套细节（健康检查参数口径、安全组规则语法差异）按官方文档逐条核对。这也是我把项目二方案沉淀成文档的价值之一：清单先行，换什么云都不慌——"概念同构加清单核对"就是我的迁移方法论。

9.21 本章案例

• 【真实项目·支持场景】一次"无法访问平台"的全链路定位（STAR，约 230 字）：背景是银行某部门多人反馈上午九点半起无法访问智能合约平台。任务：我作为驻场一线定位并协调解决。行动：先收集信息——同一部门约 20 人、现象是完全打不开、9 点半开始、无报错弹窗、无变更；按命令树让用户侧配合测：ping 平台 VIP 不通、ping 网关通、ping 其他内网系统通——问题收敛到"该部门到平台网段的路由/策略"；traceroute 显示在核心交换后丢包，telnet 平台 443 不通；我把排查证据打包转网络组，指定了"部门网段到平台网段"的收敛区间。网络组排查发现是夜间防火墙策略变更误删了一条放行规则，恢复后验证恢复。结果：从报障到恢复 45 分钟，全程工单记录，事后我推动"防火墙变更通知同步驻场组"进流程。这个案例的要点：命令树收敛 + 带证据转派 + 闭环改流程，三段都是支持岗的价值。
• 【真实项目】CLB 健康检查误摘与恢复演练（STAR）：背景是移动云集群一次节点内存压力导致 kubelet 短暂无响应，CLB 健康检查把该 master 摘除，kubectl 出现偶发超时。任务：定位并验证入口高可用。行动：控制台确认 CLB 后端健康状态变化时间线，与监控内存曲线对齐；验证摘除机制正常（故障节点摘除、恢复后自动加回）；补做一次主动演练——停一台 master 的 kubelet，验证 CLB 秒级摘除、kubectl 经 VIP 无感。结果：确认设计目标达成（99.99% 是设计目标口径），并把"入口健康检查状态"加进日常巡检项。支持视角的收获：偶发故障要还原时间线，高可用机制要演练验证而不是口头相信。
• 【课程项目】网络基础成套实验：VLAN 与 Trunk 划分、子网计算（/24 按 50 主机划分：借 2 位成 /26，4 个子网各 62 可用）、DHCP 四步交互抓包、ping/telnet/traceroute 全链路排查——课程基础和银行现场 CE 交换机实操互相印证，面试按"实验打底、现场实操"口径讲。
• 【经典故障】网页打不开但 QQ 能登录（完整版约 200 字）：背景是用户反馈网页打不开但 QQ 正常。排查按"网络连接 → DNS → 代理 → 服务器"四层收敛：ping 网关和公网 IP 确认链路通；链路通而域名不通锁定 DNS——nslookup 解析失败，换 223.5.5.5、114.114.114.114 对比能解析，确认本地 DNS 故障或缓存污染，清缓存改 DNS 后恢复；顺手确认浏览器代理设置未被改动；最后 curl 验证服务器响应正常。价值：展示分层排查思路，和云上"ping → 安全组 → 监听 → 日志"的顺序同构——面试我常拿它把传统网络和云网络串成一套方法论。

章末自测清单

1. TCP/IP 四层是哪四层？ → 网络接口、网络、传输、应用；排障按层从下往上收敛。
2. 三次握手为什么不能两次？ → 双方都要确认收发能力，且防历史 SYN 误建连接。
3. TIME_WAIT 在哪端、等多久？ → 主动关闭方，2MSL；大量 TIME_WAIT 查短连接。
4. 大量 CLOSE_WAIT 说明什么？ → 本端应用收到 FIN 没调 close，代码 bug，转开发。
5. ping 通 telnet 不通查什么？ → 对端服务监听（ss -lntp）→ 监听地址是否 0.0.0.0 → 防火墙/安全组。
6. ping 不通怎么分型？ → 网关都不通查本机/二层；网关通外网不通查路由出口；只有目标不通查目标或禁 ICMP。
7. mtr 怎么判真丢包？ → 某跳丢且后续全丢是真丢；单跳丢后面正常是路由不响应 ICMP 的假丢包。
8. ss 看监听读什么？ → -lntp：端口、监听地址（0.0.0.0 vs 127.0.0.1）、进程 PID。
9. tcpdump 三种异常形态？ → 只有 SYN 无回包（被丢/不可达）、[R]（被拒/被切）、大量重传（链路差/对端忙）。
10. "打不开"先问 DNS 还是先 ping？ → ping IP 和 ping 域名对照：IP 通域名不通即 DNS，dig/nslookup 深入。
11. 网络工单五步闭环？ → 接报障收五要素 → 命令树定位层级 → 处理或带证据转派 → 跟踪跟催 → 确认闭环复盘沉淀。
12. 转派单四件套？ → 现象描述、排查证据、已排除项（收敛区间）、影响与紧急度。
13. 169.254.x.x 说明什么？ → DHCP 拿不到地址的 APIPA 自动配置；查物理层、DHCP 服务/中继、地址池。
14. 私接路由器怎么防？ → 交换机 DHCP Snooping：终端口非信任、仅信任上联 DHCP 口，丢弃非法 OFFER。
15. Access 和 Trunk 区别？ → Access 单 VLAN 不打标签接终端；Trunk 多 VLAN 带 802.1Q 标签做级联。
16. 不同 VLAN 互通靠什么？ → 三层设备：三层交换机 VLANIF 做网关或路由器单臂路由。
17. 安全组和网络 ACL 区别？ → 安全组实例级有状态（免回程规则）；ACL 子网级无状态（进出各写）。
18. SNAT/DNAT 一句话？ → SNAT 内网出公网改源地址；DNAT 外部进来改目标地址。
19. HTTPS 握手加密分工？ → 非对称验证证书+协商密钥，对称加密传输数据。
20. 查证书有效期与 SAN？ → openssl x509 -noout -dates / -text；线上用 openssl s_client 远程探测。
21. 移动云 CLB 对应阿里云什么？ → SLB；ECS/VPC/OSS 概念同构，方法论可迁移。
22. 等保对支持的日常要求举两条？ → 日志留存≥6 个月、账号最小权限定期审计。
23. traceroute 全是星号先做什么？ → 换 TCP 探测（-T -p 目标端口）再下结论，默认协议可能被策略拦。
24. CE 交换机配置完必做什么？ → save；诊断四命令 display interface brief / vlan / mac-address / lldp neighbor。
25. 云上服务不可访问第一嫌疑人？ → 安全组/ACL 变更记录，其次监听状态与 CLB 健康检查。