有一类项目，接单时客户就扔过来一句话："我们网络太乱了，合规审查提了一堆整改项，今年必须把网络分段做掉。"听起来好像就是把几个网段隔开、加几条策略的事，实际从规划走到上线再走到稳定运维，少则两个月，多则半年。网络分段标准化构建，本质上不是设备的活，是管理思路的活——你要先搞清楚"谁允许访问谁"，才能谈VLAN、防火墙和访问控制策略。

这篇文章把我做企业ICT网络分段项目的完整过程整理出来，从最开始的需求分析、区域规划、VLAN与IP设计，到设备配置、迁移上线的节奏，再到后期运维巡检的落地细节，全程踩过的坑也都写进去了。阅读之前先说明一点：本文的重点不在某个厂商的具体命令，而在分段这件事本身的完整方法论。你只要把思路捋顺了，换成哪家的设备都是同一套打法。

1. 先弄明白：网络分段解决的到底是什么问题

1.1 扁平网络到底有多危险：一次真实的横向扩散复盘

我之前经手过一家中等规模的制造企业，整个办公网和生产网混在一个大网段里，两千多台设备全部在10.1.0.0/16下面。听起来没什么不对劲，毕竟很多老企业都是这么过来的。问题出在一次病毒爆发：某台办公电脑中了勒索程序，程序在内网里疯狂扫描445端口，同一网段的文件服务器直接中招，财务共享目录被加密，生产车间的MES客户端连接全部报错。

复盘的时候发现一个很残酷的事实：所有设备在同一个广播域里，意味着任意一台终端都可以直接用ARP广播探活整个网段，找到目标后直接横向攻击。防火墙虽然在出口上，但对内网的东西向流量完全看不见。传统边界安全模型假设"内网可信"，可现实是内网一台设备沦陷，几小时内就能漫游到所有可达网段。

网络分段要解决的就是这个"东西向裸奔"问题。把网络切割成多个逻辑区域，让流量在跨区时必须经过访问控制点，同时缩小广播域的范围。用大白话说，就是把"一个所有人都能串门的大院子"改造成"一栋有门禁的楼"，每层之间要刷卡才能进出。

1.2 分段的本质：把信任边界从"整个内网"收缩到"业务端口"

分段的核心思想是"零信任"里天天讲的那句话：不再信任网络位置，只信任明确的访问关系。落到工程上，就是默认拒绝跨区域的流量，只放行业务明确需要的路径。

比如Web服务器需要访问数据库的3306端口，那就只放行这一条路径：源地址是Web服务器IP，目的地址是数据库IP，协议端口是TCP 3306。至于数据库服务器能不能访问Web服务器？默认禁止。办公终端能不能直接登录数据库？默认禁止。

这里要理解一个关键点：分段的粒度决定了安全效果的上限，也决定了运维成本的下限。粒度太粗，比如只把"办公网"和"生产网"切开，内部的横向移动依然畅通无阻；粒度太细，比如每台服务器一个VLAN、每个应用之间都单独建策略，策略数量会爆炸，运维人员根本维护不过来，最后变成一锅粥。我见过某企业一开始就上微隔离，结果四千多条策略没人敢动，新业务上线等策略审批等了两周。

比较务实的做法是分梯队：先做物理或者逻辑上的区域隔离，再在关键业务路径上做精细化管控，最后在高风险区域考虑微隔离。一步到位的微隔离方案，对大多数传统企业来说，组织能力和工具链都还没准备好。

1.3 三种分段方案的取舍：物理隔离、VLAN隔离、微隔离

不同企业预算和现状不一样，分段的手段也分好几个档次，我列个对比表方便你按需选型：

物理隔离最稳妥但最不灵活，两个区域之间只要有数据交换就得拉网线、加设备，扩个IP都要重新考虑布线。VLAN隔离是企业性价比最高的选择，也是本文的主要落地路径。微隔离是趋势，但请务必在业务上云的场景里再去考虑，传统物理网络硬上微隔离是给自己挖坑。

2. 规划阶段：画拓扑之前，请先把这三件事做完

2.1 资产梳理：没有清单就做分段，等于闭眼开车

做规划的第一步不是打开Visio画拓扑，而是拿着资产清单确认三件事：网络里有什么设备、这些设备在哪个位置、它们之间需要什么通信。我见过最快的翻车方式，就是跳过资产梳理直接规划网段，结果上线那天发现运维同事漏了一台老旧的考勤服务器，导致所有门禁系统离线。

资产梳理至少要覆盖四类对象：服务器、终端、网络设备、应用系统。梳理方法不一定要上多贵的工具，用Excel就能起步。每台服务器记录IP、MAC、操作系统、所属业务系统、负责人；终端按部门和使用场景归类；网络设备记录型号、位置、上联关系；应用系统要细化到"它依赖哪些数据库、中间件、外部接口"。

这里有个实操经验：资产梳理一定要让业务部门签字确认，尤其是服务器和应用依赖的部分。光靠IT自己猜，大概率会漏掉某些"只有业务知道"的老系统。这些老系统往往还是关键路径，上线时突然跳出来要求通端口，轻则推迟工期，重则中断业务。

2.2 通信矩阵怎么做：一张表管住所有访问关系

资产梳理完成后，最核心的规划成果是一张"通信矩阵"，它决定了后续所有VLAN规划和策略设计的输入。通信矩阵本质上就是一张访问关系清单，列出"谁（源）要访问谁（目的）、用什么协议端口、用途是什么、归属哪个业务负责人"。

我习惯的表格字段至少包含这几列：业务系统、源设备、源网段、目的设备、目的网段、协议端口、访问用途、业务负责人、是否必须放行。举例来说：

建矩阵的过程就是反复访谈业务部门的过程。你问一个应用开发负责人"你的系统需要访问哪些端口"，他大概率说不全，你得先抓包或者看服务器连接状态，把现网的活跃连接导出来，再让负责人确认。这个阶段多花一周，后面实施阶段就能少加二十条紧急策略。

2.3 区域划分与VLAN规划：先定边界，再定编号

通信矩阵做好了，区域边界就水到渠成。企业网络一般划分为这么几个大区：办公区、核心业务区、开发测试区、DMZ区（对外服务）、运维管理区。每个大区内部再按业务系统切VLAN，避免同一个区内所有系统塞在一个网段里。

VLAN编号要有全局规则，不要想起一个编一个。我常用的规则是：1-99保留给网络设备互联和管理VLAN，100-199给办公区，200-299给核心业务区，300-399给开发测试区，400-499给DMZ区，500-599给运维管理区。这个规则最大好处是，看到VLAN ID就知道流量属于哪个区域，排查问题时能少走很多弯路。

规划VLAN时还要注意广播域大小。一个VLAN里设备太多，广播报文会拖慢整网效率；太少则VLAN数量膨胀，交换机Trunk链路要放行的列表变长。我一般控制每个业务VLAN的设备数量在200台以内，办公区VLAN按楼层或部门划分，服务器区按应用层划分，尽量让同一广播域内的设备有业务上的相关性。

2.4 IP地址规划：预留、收敛、可扩展，一个都不能少

IP规划这件事被很多人当成"分配一串数字"，其实它是分段项目里后期最难改的部分。一旦上了生产再改IP，牵扯DNS、DHCP、防火墙策略、监控告警，工作量翻倍。所以规划期宁可多花时间，也要把IP地基打稳。

我常用的规划思路是：拿到一段可用内网地址后，按区域先划分大段，再在大段里按业务切小段。比如企业拿到10.0.0.0/16，那么核心业务区用10.0.10.0/24起步，办公区用10.0.20.0/24起步，DMZ用10.0.40.0/24，运维管理区用10.0.100.0/24。每个大区预留一段空白地址，比如10.0.200.0/24到10.0.254.0/24作为扩展池，防止新业务上线时无地址可用。

子网掩码的选择要结合设备数量预估。一个业务区初期只有30台设备，直接用/24（254个可用地址），不要用/27（30个地址）。原因很简单：只要这个业务区将来扩容，/27马上就不够用，重新规划网段的成本远远大于初期多分配几个IP的浪费。另外，网关建议统一放在核心交换机的SVI接口上，不要在每台接入交换机上起三层，否则路由条目和排障难度都会直线上升。

分区IP规划示例表：

3. 实施阶段：策略配置的关键细节与迁移节奏

3.1 核心设备配置：VLAN、SVI与防火墙串接的注意事项

规划图纸完成后进入实施阶段，第一件事是搭建网络基础：在核心交换机上创建VLAN、配置SVI接口作为各网段网关、打通Trunk链路。以常见的华为交换机为例，创建批量VLAN的命令大致是这个思路：

vlan batch 100 200 300 400 500

再把对应的SVI接口配上IP地址作为网关：

interface Vlanif100 ip address 10.0.20.1 255.255.255.0

接入交换机的Trunk口要放行相关VLAN：

interface GigabitEthernet0/0/1 port link-type trunk port trunk allow-pass vlan 100 200

设备配置本身不是难点，真正的难点在于防火墙在网络里的串接位置。通常的做法是：核心交换机作为各VLAN的网关，防火墙旁挂或串接在核心和外部网络之间，所有跨区域的流量经过防火墙做访问控制。如果企业规模不大、预算充足，也可以采用防火墙做全网网关的模式，VLAN间的流量直接由防火墙转发和过滤，安全性更高，但性能压力也更大。

这里有一个我反复强调的点：分段的核心不只是交换机的VLAN，而是"跨VLAN流量必须经过访问控制设备"。如果你只是在核心交换机上创建了不同VLAN、配置了路由，没有串接防火墙，或者ACL没有实际收紧，那么分段只是"形式上分了"，攻击者从办公区到核心业务区依然一路畅通。

3.2 访问控制策略设计：默认拒绝和最小权限怎么落地

策略是分段项目的灵魂。设计策略时，我遵循三条铁律：默认拒绝、显式放行、命名可读。

默认拒绝好理解：防火墙或ACL的最后一条规则是拒绝所有流量，前面只放行通信矩阵里明确列出的路径。显式放行指每条放行策略都要写清楚源地址、目的地址、协议端口，不允许出现"any到any"的规则。命名可读是国内企业最容易忽视的点，很多防火墙策略叫"test1""rule2"，半年后自己人都看不懂这条策略是干什么的，更不敢删。

防火墙策略示意（以常见的命令风格为例，具体以厂商为准）：

security-policy rule name OA_TO_DB source-address 10.0.30.0/24 destination-address 10.0.10.0/24 service tcp_3306 action permit rule name DENY_ALL action deny

策略设计顺序也很重要：放行策略在前，拒绝策略在后。如果有特殊需求，比如某个IP需要临时放行，应该插在拒绝策略之前，并且明确标注过期时间。我见过有人把临时策略加在最后，结果前面的拒绝策略永远命中，临时放行完全不生效，排查半天才发现顺序问题。

3.3 迁移三步走：先同网段，再断高风险路径，最后全量收紧

网络分段最怕的是"一刀切"。你规划文档写得再完美，上线时如果一次性把几千台设备的通信全切断，业务部门一定会炸锅。我总结出一个三段式迁移节奏，实测下来既能控制风险，又能推进落地。

第一步，先把各区域的VLAN和网段建好，终端逐步迁移到新网段，但跨区域的通信暂时全部放行。这一步的目标准确说是"逻辑分域完成，业务不动"。大家可以理解为换了个新房子住进去，但门都还没锁。

第二步，选择最高风险的几条路径先收紧。比如办公区到核心业务区的数据库访问，办公终端到运维管理区的网络设备管理，这两条路径一旦被非法访问，危害最大，优先用策略收紧。这一步会暴露很多之前通信矩阵没梳理到的"隐藏依赖"，正好用真实流量来修正规划文档。

第三步，在所有路径验证完毕后，把默认策略从"放行"切换为"拒绝"。这是全网最紧张的时刻，建议安排在业务低峰期执行，并准备回退方案。回退不一定要断网，最简单的做法是保留一份"放行所有"的策略配置，出问题可以快速加载回去，等排查再精确定位。

3.4 上线现场最容易踩的三个坑

第一个坑是动态端口。很多通信矩阵里只写了"TCP 80"、"UDP 53"这类固定端口，但实际业务里大量协议使用动态端口。比如FTP被动模式的数据端口是协商出来的，某些Windows RPC服务的端口随机，老的视频监控平台也可能用动态RTP端口。如果你的防火墙只放行了固定控制端口，数据通道会被拦死，业务表现为"时好时坏"。解决思路有两个：优先推动业务改固定端口，或者在防火墙上启用应用层识别/ASPF功能，让控制通道自动放开数据通道。

第二个坑是DHCP跨VLAN。终端迁移到新网段后，如果DHCP服务器在老网段，又没有配置跨网段的DHCP Relay，终端就获取不到IP，表现为"网线插上但上不了网"。做迁移之前，务必确认每个VLAN都能正确获取IP，核心交换机上要配置好中继地址指向DHCP服务器。

第三个坑是双机热备和路由协议的组播报文。如果核心交换机或防火墙做了双机热备，很多设备会跑VRRP、HSRP这样的组播协议。你在ACL里一旦把"其他所有协议"拒绝掉，这些组播报文也可能被拦，导致主备切换失效。配置默认拒绝策略时，一定要把管理网段、组播协议、设备间互联的报文先放行掉，否则表面上看策略没问题，一发生设备故障就出大事。

4. 运维阶段：分段不是上完线就结束

4.1 变更管理：策略是资产，不是临时工

分段上线之后，真正的考验才刚开始：日常变更。新员工入职要开通某台服务器权限，新系统上线要加一条数据库访问规则，业务方说"这个端口不通了"要临时放行一下。如果没有一套变更管理流程，半年后防火墙策略列表就会变成糊成一团的面条。

我在运维端的建议是：所有策略变更走申请-审批-实施-复核四步。申请环节必须写明原因、影响范围、预计有效期；审批环节要由业务负责人和安全负责人共同确认；实施窗口放在低峰期，并记录变更前配置和回退步骤；复核环节在变更后第二天检查策略命中日志，确认没有误拦或异常放行。

策略命名规范要强制执行。我见过做得很好的团队，每条策略名都能看出来龙去脉，比如"20240115_OA_APP_TO_DB_TCP3306"。这种命名习惯在清理策略时价值巨大——你会知道这条策略是谁申请的、为了什么事，判断它是否还可以删除就简单多了。

4.2 监控与审计：怎么看东西向流量和策略命中

分段做完，安全团队反而要更勤快，因为原来"看不见"的东西向流量现在要纳入监控。基础要求是把防火墙日志、交换机Syslog统一采集到日志中心，至少保留半年。更进一步是部署流量分析工具（NetFlow/sFlow），实时查看各区域间的流量大小、连接数、异常流量模式。

我先给一条实操经验：不要只看防火墙的"拒绝日志"，更要关注"放行日志"。拒绝日志量大且繁杂，大部分是扫描探测，容易让人麻木；放行日志里反而能发现可疑行为，比如某个办公终端从早到晚高频访问数据库、某个服务器凌晨突然跟陌生IP建立长连接，这些都是失陷迹象。

我习惯每周导出一份策略命中Top100清单，看哪些策略被大量触发，哪些策略长期零命中。零命中的策略大概率是僵尸规则，可以进入待清理流程；高频命中的规则要定期确认业务是否还有效，防止业务下线后规则残留变成安全敞口。

4.3 定期巡检与策略瘦身：把"僵尸规则"赶出去

运维阶段的重点工作之一是策略瘦身。企业网络运行一两年后，策略数量膨胀是必然的。有些是上线时临时加的，业务下线了策略没人删；有些是排障时为了"快速恢复"放的宽策略，后面忘了收窄。这些僵尸规则最大的风险不是性能，而是"可用作绕过访问控制的路径"——攻击者一旦找到一条放得特别宽的规则，就能绕过其他所有精细策略。

我建议至少每季度做一次策略评审，流程是：导出全量策略清单，按最后命中时间排序，找出超过半年无命中的策略；逐条联系业务负责人确认是否还需要，确认不需要的直接删除并归档。如果策略数量太大，可以在防火墙上开启策略命中统计，让设备自动记录每条策略的命中次数，省去人工分析日志的力气。

巡检的范围不要只盯着防火墙，还要包括交换机ACL、路由表、VLAN划分、Trunk放行列表。很多企业核心交换机上还留着几年前调试用的临时ACL，这些ACL优先级高、放行范围宽，危害不亚于防火墙上的问题策略。

5. 全流程避坑清单：我把踩过的坑都写在这里了

5.1 规划期最容易犯的错

规划期最常见的错误是"先分区后梳理"。不少项目一启动就急着画拓扑图、定网段，梳理资产和通信关系被当成杂活往后排。结果等到实施阶段，发现规划文档跟实际网络对不上，要么重新改规划，要么带着问题上线。我的建议是，资产梳理和通信矩阵的工作量至少要占到整个项目周期的三分之一，这三分之一花得越扎实，后面越省事。

还有一个坑是过度依赖现网抓包，把临时性流量当成常态需求。有一次我按抓包结果给一个系统放行了大量端口，后来才发现那些流量是管理员手动操作产生的，并不是业务常态。这导致策略过度放宽。正确的做法是：抓包结果只是线索，必须以业务负责人的确认意见为准。

5.2 实施期最容易犯的错

实施期最容易犯的错是忽略回退方案。每次在核心设备上做批量变更，都应该提前写好配置回滚脚本，测试环境先验证一遍。不要以为自己操作熟练就不会出错，核心设备上一次错误的路由发布就能让全网瘫痪，出问题时再翻配置等于在事故现场找答案。

另一个实施期坑是"没有做变更前基线备份"。我遇到过一种情况：某个区域策略改了以后，业务同事说"以前是通的"，但怎么也查不到演示。后来发现防火墙更换过，老规则根本没有迁移到新设备上。因此每次变更前都要完成配置备份，变更后再备份一次，形成可对比的基线。对关键设备的登录和操作行为，也要有审计记录，谁改了什么、什么时候改的，一笔一笔都能查。

5.3 运维期要注意的长期事项

运维期容易忘掉的是"让业务部门参与策略确认"。网络分段是IT的基础设施工程，但访问关系的真正所有者是业务系统负责人。运维团队可以替他们执行变更，但"这个端口是否还要开"的决策权必须在业务方。我见过最理想的做法是：通信矩阵保存在共享文档里，业务负责人时刻维护自己负责的访问关系，每个季度IT拉出清单让他们确认一次，业务不确认的策略自动进入冻结状态。

另一个长期事项是文档同步。VLAN规划、IP分配表、通信矩阵、防火墙策略清单、变更记录，这五份文档必须保持同步更新。很多企业在实施阶段文档做得很全，运维半年后就开始不更新，等到下一次审查或做大改造时，这些文档不仅帮不上忙，还会误导人。把文档更新写进变更流程里，每次操作完设备就顺手改文档，这个习惯比任何安全工具都值钱。

最后再分享一个我个人的习惯：每隔半年做一次"分段效果复盘"，找准一个真实的攻击路径做推演，比如模拟办公区一台终端沦陷，看它能够通过哪些已放行的路径触达核心业务。推演结果通常能发现几条不该开的策略或者遗漏的分区。这个做法不需要额外购买工具，只需要拉出策略清单、对照通信矩阵走一遍，就能让整个分段项目持续保持有效，而不是上线那天有效一次，之后就慢慢变成一张摆设。希望这套从规划到运维的落地流程，能帮你少走几圈弯路。