ARTICLE DETAIL

资讯详情

深耕网站视觉设计与运营推广的一线实战洞察。

OpenStack多租户网络隔离:Neutron与VXLAN实战指南

OpenStack多租户网络隔离:Neutron与VXLAN实战指南 简介这份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 分开了。这里的关键概念是网络域隔离。你可以把每个租户网络理解成一个独立的二层广播域VNIVXLAN Network Identifier就是它的身份证。VNI 有 24 位理论上能撑 1600 万个隔离域实际部署里受限于 VTEP 表和组播/单播复制方式一般单集群几千个网络是稳的。隔离分三层来看二层隔离靠 VXLAN/GRE 隧道不同 VNI 的流量物理上不互通。三层隔离靠 Neutron Router 的命名空间租户路由默认不互相 import 路由。四层隔离靠安全组Security Group和 ACL控制同网络内虚机之间的访问。很多人只做了第一层就以为完事了结果同租户内虚机互扫、跨租户通过共享网络串流都是后两层没配。2.2 三种隔离方案的选型对比实际落地时隔离方案不是只有一种。常见做法有三种选错了后面全是坑。方案隔离粒度适用场景主要代价VLAN 物理隔离物理网络级小规模、租户少、性能敏感VLAN 4094 上限跨机房难VXLAN 租户网络租户网络级中大规模私有云需要 VTEPMTU 要调安全组 ACL 叠加端口/规则级所有场景的补充层规则多了性能下降我一般会推荐 VXLAN 租户网络打底安全组做细粒度收口。VLAN 方案在租户超过几百个之后基本没法维护而且跨物理网络要重新规划后悔药都没得吃。选 VXLAN 的理由很实在它把隔离逻辑从物理交换机挪到了计算节点的 OVS 或 Linux Bridge 上租户增减不用动交换机配置。代价是每个计算节点要有 VTEP 地址且底层网络 MTU 必须 ≥ 1550VXLAN 头 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 快速搭一套可验证隔离的 OpenStack3.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.*/SELINUXpermissive/ /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 生成应答文件并开启 VXLANPackstack 默认可能用 VLAN 或 flat要验证多租户隔离必须显式开 VXLAN。先生成应答文件再改packstack --gen-answer-fileanswer.txt # 关键项修改 sed -i s/^CONFIG_NEUTRON_ML2_TENANT_NETWORK_TYPES.*/CONFIG_NEUTRON_ML2_TENANT_NETWORK_TYPESvxlan/ answer.txt sed -i s/^CONFIG_NEUTRON_ML2_TYPE_DRIVERS.*/CONFIG_NEUTRON_ML2_TYPE_DRIVERSflat,vlan,vxlan/ answer.txt sed -i s/^CONFIG_NEUTRON_OVS_TUNNEL_IF.*/CONFIG_NEUTRON_OVS_TUNNEL_IFeth1/ answer.txt sed -i s/^CONFIG_NEUTRON_L2_AGENT.*/CONFIG_NEUTRON_L2_AGENTopenvswitch/ answer.txt sed -i s/^CONFIG_PROVISION_DEMO.*/CONFIG_PROVISION_DEMOn/ answer.txtCONFIG_NEUTRON_ML2_TENANT_NETWORK_TYPESvxlan是核心它决定租户网络用什么封装。CONFIG_NEUTRON_OVS_TUNNEL_IFeth1指定隧道网卡这块网卡必须是独立于管理网的否则隧道流量和管理流量抢带宽。CONFIG_PROVISION_DEMOn关掉演示租户避免干扰我们自己的隔离测试。改完执行安装packstack --answer-fileanswer.txt安装完会生成keystonerc_adminsource 一下就能用 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_request1550 # 虚机内在虚机里执行 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($1prev)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 $8ingress $60.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 多租户的团队配一套。希望帮到你。本文还有配套的精品资源点击获取
返回列表