简介：这份PDF文档面向云计算研究人员、系统管理员及OpenStack开发运维人员，聚焦多租户环境下云平台网络隔离的规划与部署难题。内容从OpenStack架构与Neutron、Nova等关键组件切入，系统梳理VLAN、VXLAN、GRE等二层隔离技术及路由隔离、安全组策略等三层方案，并提出综合设计思路，涵盖网络资源配置、租户创建与连接、访问控制与数据加密等安全策略，同时通过连通性测试、性能流量分析与异常排查验证方案有效性。资源包共1个PDF文件，约136KB，结构完整、章节清晰，便于按模块查阅。已有92人学习，适合需要理解隔离原理、对照实验步骤并获取优化建议的读者参考。
1. 多租户网络隔离：OpenStack 里最容易被低估的一层
很多团队把 OpenStack 云平台搭建起来之后，第一件翻车的事不是虚机起不来，而是两个租户的网段莫名其妙通了。表面上看是"网络配置问题"，实际上是隔离模型没吃透。OpenStack 环境下多租户网络隔离技术的应用研究，核心要回答的就一件事：在同一套物理网络上，怎么让 A 租户的流量绝对到不了 B 租户，同时每个租户还能自己定义 IP 段、自己管安全组。这背后靠的是 Neutron 的租户网络模型加上 VXLAN/GRE 隧道封装，再叠加安全组和 ACL 做二层到四层的收口。适合正在做私有云落地、被租户串网搞过的运维和云平台工程师，也适合准备基于 Packstack 快速验证隔离效果的人。下面按"模型怎么立 → 环境怎么搭 → 隔离怎么验 → 坑在哪"的顺序讲透。
2. 隔离模型先立住：Neutron 的租户网络到底隔离了什么
2.1 从"一个租户一个网络"说起
OpenStack 的多租户隔离不是靠物理交换机划 VLAN 那么简单。Neutron 的设计里，租户网络（Tenant Network）默认就是隔离的，隔离的边界是"网络"这个对象本身。每个网络有独立的网段、独立的 DHCP、独立的路由命名空间。两个租户各自建一个网络，哪怕网段都写成 192.168.1.0/24，也不会冲突，因为它们在数据面上被 VXLAN 的 VNI 分开了。
这里的关键概念是"网络域隔离"。你可以把每个租户网络理解成一个独立的二层广播域，VNI（VXLAN Network Identifier）就是它的身份证。VNI 有 24 位，理论上能撑 1600 万个隔离域，实际部署里受限于 VTEP 表和组播/单播复制方式，一般单集群几千个网络是稳的。
隔离分三层来看：
- 二层隔离：靠 VXLAN/GRE 隧道，不同 VNI 的流量物理上不互通。
- 三层隔离：靠 Neutron Router 的命名空间，租户路由默认不互相 import 路由。
- 四层隔离：靠安全组（Security Group）和 ACL，控制同网络内虚机之间的访问。
很多人只做了第一层就以为完事了，结果同租户内虚机互扫、跨租户通过共享网络串流，都是后两层没配。
2.2 三种隔离方案的选型对比
实际落地时，隔离方案不是只有一种。常见做法有三种，选错了后面全是坑。
| 方案 | 隔离粒度 | 适用场景 | 主要代价 |
|---|---|---|---|
| VLAN + 物理隔离 | 物理网络级 | 小规模、租户少、性能敏感 | VLAN 4094 上限，跨机房难 |
| VXLAN 租户网络 | 租户网络级 | 中大规模私有云 | 需要 VTEP，MTU 要调 |
| 安全组 + ACL 叠加 | 端口/规则级 | 所有场景的补充层 | 规则多了性能下降 |
我一般会推荐 VXLAN 租户网络打底，安全组做细粒度收口。VLAN 方案在租户超过几百个之后基本没法维护，而且跨物理网络要重新规划，后悔药都没得吃。
选 VXLAN 的理由很实在：它把隔离逻辑从物理交换机挪到了计算节点的 OVS 或 Linux Bridge 上，租户增减不用动交换机配置。代价是每个计算节点要有 VTEP 地址，且底层网络 MTU 必须 ≥ 1550（VXLAN 头 50 字节 + 内层 1500），否则大包会被静默丢弃，表现为"能 ping 通但 SSH 卡死"，这种玄学问题排查起来很费时间。
2.3 隔离边界上的三个对象
要把隔离讲清楚，必须盯住三个对象：
第一是 Network。它是隔离的最小单位，创建时指定租户，默认只有本租户可见。共享网络（Shared Network）是例外，一旦勾了 shared，所有租户都能看到，隔离就破了，除非配合 RBAC。
第二是 Router。租户路由默认只连本租户的子网。跨租户要通，必须显式做 router 接口对接或外部网关，这个动作本身就是一次"破隔离"，要有审批。
第三是 Security Group。它是端口级的，默认规则是出方向全通、入方向只通同安全组。很多串网事故就是有人把默认安全组改成了 0.0.0.0/0 全通。
提示：判断隔离是否成立，不要只看能不能 ping 通，要看 ARP 表里有没有对方的 MAC。二层隔离破了，ARP 会先暴露。
3. 用 Packstack 快速搭一套可验证隔离的 OpenStack
3.1 环境准备与 Packstack 安装
要验证多租户隔离，最省事的路径是 Packstack 单节点或双节点起一套 All-in-One。它把 Neutron、OVS、VXLAN 都配好了，省去手工调的时间。前提是 CentOS 或 Rocky Linux 8/9，内存至少 16G，双网卡（一块管理、一块租户隧道）。
先做基础准备：
# 关闭防火墙和 SELinux（实验环境，生产要按需放行） systemctl disable --now firewalld setenforce 0 sed -i 's/^SELINUX=.*/SELINUX=permissive/' /etc/selinux/config # 配置主机名和 hosts hostnamectl set-hostname openstack.local echo "192.168.10.10 openstack.local" >> /etc/hosts # 启用 OpenStack 仓库 dnf install -y centos-release-openstack-yoga dnf update -y dnf install -y openstack-packstack这段脚本做三件事：关掉会干扰 Neutron 的防火墙和 SELinux、固定主机名解析、装 Packstack。参数上，centos-release-openstack-yoga里的 yoga 是版本代号，换成你实际要用的版本即可，但要注意 Packstack 对新版本支持有滞后，Yoga 是相对稳的选择。
3.2 生成应答文件并开启 VXLAN
Packstack 默认可能用 VLAN 或 flat，要验证多租户隔离，必须显式开 VXLAN。先生成应答文件再改：
packstack --gen-answer-file=answer.txt # 关键项修改 sed -i 's/^CONFIG_NEUTRON_ML2_TENANT_NETWORK_TYPES=.*/CONFIG_NEUTRON_ML2_TENANT_NETWORK_TYPES=vxlan/' answer.txt sed -i 's/^CONFIG_NEUTRON_ML2_TYPE_DRIVERS=.*/CONFIG_NEUTRON_ML2_TYPE_DRIVERS=flat,vlan,vxlan/' answer.txt sed -i 's/^CONFIG_NEUTRON_OVS_TUNNEL_IF=.*/CONFIG_NEUTRON_OVS_TUNNEL_IF=eth1/' answer.txt sed -i 's/^CONFIG_NEUTRON_L2_AGENT=.*/CONFIG_NEUTRON_L2_AGENT=openvswitch/' answer.txt sed -i 's/^CONFIG_PROVISION_DEMO=.*/CONFIG_PROVISION_DEMO=n/' answer.txtCONFIG_NEUTRON_ML2_TENANT_NETWORK_TYPES=vxlan是核心，它决定租户网络用什么封装。CONFIG_NEUTRON_OVS_TUNNEL_IF=eth1指定隧道网卡，这块网卡必须是独立于管理网的，否则隧道流量和管理流量抢带宽。CONFIG_PROVISION_DEMO=n关掉演示租户，避免干扰我们自己的隔离测试。
改完执行安装：
packstack --answer-file=answer.txt安装完会生成keystonerc_admin，source 一下就能用 OpenStack 命令。
3.3 创建两个租户并验证隔离
装好之后，建两个租户、各建一个网络，验证它们不通。
source ~/keystonerc_admin # 建两个租户 openstack project create tenant_a openstack project create tenant_b # 建两个用户并绑定租户 openstack user create --password Passw0rd --project tenant_a user_a openstack user create --password Passw0rd --project tenant_b user_b # 用 admin 给租户建网络（实际应由租户自己建） openstack network create --project tenant_a net_a openstack subnet create --project tenant_a --network net_a \ --subnet-range 192.168.100.0/24 subnet_a openstack network create --project tenant_b net_b openstack subnet create --project tenant_b --network net_b \ --subnet-range 192.168.100.0/24 subnet_b注意这里两个租户用了完全相同的网段 192.168.100.0/24，这是故意的。如果隔离成立，它们不会冲突；如果隔离破了，路由会打架。建完用openstack network list确认两个网络都在，但各自租户只能看到自己的。
验证隔离最直接的方式是各起一台虚机，互 ping。但更快的验证是看 VNI：
# 查看网络的 VNI 分配 openstack network show net_a -c id -c name sudo ovs-vsctl show | grep -A3 br-tunbr-tun是 OVS 的隧道网桥，不同网络的流表里 VNI 不同。如果两个网络的 VNI 一样，说明隔离没生效，要回去查 ML2 配置。
注意：Packstack 装完默认安全组是出方向全通、入方向同组通。跨租户测试时，先确认安全组没被改成全通，否则你测的是安全组不是网络隔离。
4. 隔离验证与安全组、ACL 的叠加收口
4.1 用命名空间验证三层隔离
Neutron 的 router 和 DHCP 都跑在 Linux network namespace 里，这是验证三层隔离的好工具。
# 列出所有命名空间 sudo ip netns list # 进入某个租户的 router 命名空间 sudo ip netns exec qrouter-<router-id> ip route # 从租户 A 的命名空间 ping 租户 B 的网关 sudo ip netns exec qrouter-<router-a-id> ping -c 2 192.168.100.1如果隔离正常，租户 A 的 router 命名空间里根本没有租户 B 的路由条目，ping 会直接 network unreachable。这一步比 ping 虚机更干净，因为它排除了安全组和虚机防火墙的干扰，直接验证三层路由隔离。
qrouter-<router-id>是命名空间命名规则，<router-id>用openstack router list查。qdhcp-<net-id>是 DHCP 命名空间，同理可以进去看 DHCP 只服务本网络。
4.2 安全组规则的最小化配置
网络隔离是租户间的，安全组是租户内的。默认安全组太宽松，要收口。
# 查看默认安全组 openstack security group list # 创建严格安全组：只放行 SSH 和 ICMP，且限定源 openstack security group create strict_sg --project tenant_a openstack security group rule create --proto tcp --dst-port 22 \ --remote-ip 192.168.100.0/24 strict_sg openstack security group rule create --proto icmp \ --remote-ip 192.168.100.0/24 strict_sg # 删除默认的出方向全通规则（谨慎，会影响 DNS 等） openstack security group rule list default--remote-ip限定源网段是关键，不写就是 0.0.0.0/0。--proto icmp放行 ping 方便排查，生产可以去掉。删默认出方向规则要谨慎，很多服务依赖出方向访问元数据服务 169.254.169.254，删之前先确认。
安全组规则多了之后，OVS 流表会膨胀，性能下降。经验值是单端口超过 200 条规则就要考虑合并或改用 ACL。这是隔离和性能的权衡点。
4.3 用 ACL 做网络级收口
安全组是端口级，ACL 是网络级。Neutron 本身没有独立的 ACL 对象，但可以通过"网络 + 子网 + 路由"的组合实现类似效果，或者用 OpenStack 的 RBAC 控制网络可见性。
# 用 RBAC 让网络只对特定租户可见 openstack network rbac create --type network \ --action access_as_shared --target-project tenant_b net_aaccess_as_shared让 tenant_b 能"看到" net_a，但能不能通还要看路由和安全组。这是共享网络的正确用法，比直接勾 shared 安全，因为可以精确控制给哪个租户。
如果要更细的 ACL，常见做法是在计算节点用 iptables 或 nftables 在 OVS 流表上叠加规则，但这会绕过 Neutron 的管理，升级时容易丢。我一般不建议手工改 OVS 流表，除非你有一套自动化的流表同步机制。
提示：RBAC 的
access_as_shared只控制可见性，不控制连通性。可见不等于可通，别把两者混为一谈。
5. 多租户隔离的避坑与排查清单
5.1 坑一：MTU 没调，大包静默丢弃
现象：虚机之间能 ping 通，但 SSH 登录卡在认证阶段，或者 scp 传大文件卡死。
原因：VXLAN 封装要加 50 字节头，底层物理网卡 MTU 还是 1500，导致 1500 字节的包封装后超 MTU 被丢。ping 默认包小，所以能通。
解决：把物理网卡和 OVS 的 MTU 都调到 1550 以上，虚机内网卡 MTU 设 1450。
# 物理网卡 ip link set eth1 mtu 1550 # OVS 网桥 ovs-vsctl set interface br-tun mtu_request=1550 # 虚机内（在虚机里执行） ip link set eth0 mtu 14505.2 坑二：VNI 冲突导致跨租户串网
现象：两个租户的网络偶尔能通，重启后又好了。
原因：VNI 分配范围配置重叠，或者手工指定了重复 VNI。Neutron 默认自动分配，但如果有人手工指定过，可能撞车。
解决：查CONFIG_NEUTRON_ML2_VXLAN_VNI_RANGES，确保范围唯一且足够大。用openstack network show逐个确认 VNI 不重复。
5.3 坑三：安全组默认规则被改全通
现象：租户内虚机被外部扫描，或者跨租户能访问。
原因：有人图省事把默认安全组改成 0.0.0.0/0 全通，或者新建虚机时没指定安全组，用了 default。
解决：审计所有安全组规则，openstack security group rule list导出后 grep 0.0.0.0/0。新建虚机强制指定安全组，禁用 default。
5.4 坑四：共享网络忘了配 RBAC
现象：勾了 shared 的网络，所有租户都能看到并接入。
原因：shared 是全局可见，没有租户限制。
解决：取消 shared，改用 RBAC 的access_as_shared精确授权。已经共享的网络要逐个排查接入的租户。
5.5 坑五：隧道网卡和管理网卡混用
现象：隔离时通时不通，负载高时丢包严重。
原因：隧道流量和管理流量走同一块网卡，带宽抢占。
解决：隧道用独立网卡，CONFIG_NEUTRON_OVS_TUNNEL_IF指定专用接口。生产环境隧道网卡建议万兆起步。
6. 隔离效果的持续验证与一个实用技巧
隔离配好不是终点，租户在变、网络在变，隔离会悄悄失效。我一般会留一个"隔离巡检"脚本，定期跑一遍，比出事再查省事得多。
核心思路是：用 admin 权限遍历所有租户网络，检查三件事——VNI 是否唯一、安全组是否有 0.0.0.0/0 入方向规则、共享网络是否有 RBAC 记录。
#!/bin/bash # 隔离巡检：检查 VNI 重复、危险安全组规则、无 RBAC 的共享网络 source ~/keystonerc_admin echo "=== VNI 重复检查 ===" openstack network list -f value -c ID | while read nid; do vni=$(openstack network show "$nid" -f value -c provider:segmentation_id 2>/dev/null) [ -n "$vni" ] && echo "$vni $nid" done | sort | awk '{if($1==prev)print "重复VNI:",$1,$2,prev_id; prev=$1; prev_id=$2}' echo "=== 危险安全组规则（0.0.0.0/0 入方向）===" openstack security group rule list --long -f value \ | awk '$8=="ingress" && $6=="0.0.0.0/0" {print $2,$4,$5}' echo "=== 共享网络 RBAC 检查 ===" openstack network list --share -f value -c ID | while read nid; do cnt=$(openstack network rbac list --network "$nid" -f value 2>/dev/null | wc -l) [ "$cnt" -eq 0 ] && echo "共享但无RBAC: $nid" done这个脚本的逻辑很直白：第一段把所有网络的 VNI 拉出来排序，相邻相同就是重复；第二段筛出入方向源是 0.0.0.0/0 的规则，这些是隔离的漏洞；第三段找勾了 shared 但没有 RBAC 记录的网络，这些是全局暴露的。参数上，--long让安全组规则输出包含方向和源，-f value去掉表头方便 awk 处理。
跑这个脚本我踩过的坑是：provider:segmentation_id对 flat 网络是空的，awk 处理空值会误报，所以加了[ -n "$vni" ]过滤。另外 RBAC 列表对非共享网络会报错，用2>/dev/null吞掉。
巡检频率我一般设成每天一次，结果推到监控。隔离这种事，平时没人管，出事就是大事。与其等租户投诉串网，不如让脚本替你盯着。这套东西不复杂，但能省下大量排查时间，值得每个做 OpenStack 多租户的团队配一套。希望帮到你。
本文还有配套的精品资源，点击获取
