数据库与应用层应划分为独立子网，核心目标是实现流量方向隔离、端口级访问控制及故障收敛；需配合路由限制、状态化防火墙策略、主机绑定ip和dns隔离等三层协同控制。
明确隔离目标再动子网掩码
数据库通常只接受来自应用服务器的特定端口（如3306、1433、5432）连接，不对外提供HTTP服务；应用层则需面向用户或API网关开放80/443等端口。两者流量方向、协议类型、信任等级完全不同。因此子网划分首要目标是：让数据库子网默认拒绝所有入向流量，仅放行应用子网IP段+指定端口；同时应用子网禁止直连互联网出口（通过反向代理或WAF），也不允许终端设备直接访问数据库子网。
合理规划地址空间与掩码长度
以私有C类网段 192.168.10.0/24 为例：
• 应用层子网：分配 192.168.10.0/26（64个地址，可用62台主机），覆盖Web服务器、API服务、负载均衡器等；
• 数据库子网：分配 192.168.10.64/27（32个地址，可用30台主机），专用于主库、从库、哨兵节点等；
• 预留扩展区：如 192.168.10.96/27 可留给缓存集群（Redis/Memcached），192.168.10.128/26 留给管理与监控节点。
这样既避免地址浪费，又为后续横向扩展留出连续网段，也便于ACL策略按网段批量配置。
配套实施关键控制点
子网只是逻辑边界，真正实现隔离依赖三层协同：
• 路由层面：核心交换机或防火墙上禁用数据库子网与用户终端子网、DMZ区之间的直通路由；
• 防火墙策略：在应用子网与数据库子网之间部署状态化规则，仅允许TCP目标端口3306且源IP属于应用子网CIDR；
• 主机配置：数据库服务器操作系统关闭ICMP响应、禁用非必要服务端口，并绑定监听地址为0.0.0.0以外的具体内网IP（如192.168.10.65）；
• DNS与服务发现：数据库域名（如db.internal）仅在应用子网DNS服务器中解析，不向其他区域泄露记录。
避免常见设计陷阱
• 不要将数据库和应用部署在同一VLAN或同一二层广播域——即使用了不同IP子网，ARP泛洪和MAC表溢出仍可能引发干扰；
• 不要使用全0或全1子网（如192.168.10.0/27 和 192.168.10.224/27）作为生产数据库网段，部分老旧设备或监控工具对这类地址识别异常；
• 不要跨子网复用相同服务端口做负载均衡（例如用同一个VIP指向应用子网和数据库子网），这会破坏网络意图，也增加排错难度。
