VPC、子网、虚拟网卡、ACL这四个词放在一起乍一看像四张互不相干的考卷题目其实是同一张云上网络地图的不同部位。我这些年做云上项目给新人讲网络时几乎每次都要从这四个概念开始。今天就把这套东西用大白话拆开讲——它们分别干什么、怎么配合、实际配置时有哪些坑一篇说透。想搞懂云网络或者正准备上手VPC、子网、ACL配置的同学这份内容可以直接当入门地图用。1. VPC先搞懂这个“筐”到底装了啥1.1 为什么云上非要搞一个“私有网络”出来先说一个老传统以前在机房自己拉线运维服务器插在同一台交换机上IP地址段经常撞车。你规划了192.168.1.0/24隔壁项目也规划了192.168.1.0/24两台机器一上架谁发广播都串味。更麻烦的是物理网络的安全隔离全靠网络工程师手工配VLAN、配防火墙改一次配置就是一次割接。云环境跟传统机房最大的区别是“多租户”成千上万个客户跑在同一批物理服务器和物理交换机上。如果大家共用一个大广播域A客户的内网流量能被B客户抓到IP地址随意冲突那云上就没法做生意了。所以云厂商必须给每个客户划出一块“与世隔绝”的网络空间这块空间就是VPC。VPC其实可以理解成云厂商给你开的一个“独立小机房”里面你可以自由选择私网网段创建子网配路由表挂网关装虚拟网卡加ACL规则。从你这个客户视角看你拥有一个完全自管的二层网络和三层路由从云厂商视角看你只是在系统里的一条虚拟机配置记录跟别人互不相干。还有个实际原因云上的资源是API创建、销毁的。传统机房拉根网线要半天云上创建VPC可能几秒就完成。如果底层不做逻辑隔离这种“秒级交付”根本没法落地。所以VPC不光是安全问题更是云资源编排的基本单元。你在控制台创建的第一台云服务器几乎都是先落进某个VPC里才拿到IP地址。1.2 VPC和VLAN的区别别再把两者混为一谈很多人听说VPC就联想VLAN这俩确实都有“隔离”的意思但根本不是一个层面的东西。VLAN是二层概念解决的是“在一台物理交换机上把端口分成不同的广播域”。一个标准VLAN ID总共就4094个可用而且VLAN的隔离范围基本局限在同一台交换机或者同一个二层网络中。你要跨三层就需要路由器配合隔离粒度也比较粗。VPC是网络虚拟化概念底层通过Overlay技术把物理网络“包”起来给每个租户呈现一张独立的三层网络。它的特点是VPC里的网段可以规划成任意私网段跨交换机、跨区域都能逻辑隔离创建、删除、调整都由控制面自动完成VPC里还能继续叠加子网、路由、ACL、安全组这些细粒度控制。打个比方VLAN是在一个大房间里装了几个隔断隔断只能到天花板大家还在同一栋楼VPC是给你一把独立别墅的钥匙从电表到门禁全是你的别人根本不知道这栋别墅存在。实际工作中如果你还在传统网络环境VLAN隔离够用一旦上云请以VPC为思考单位别再拿VLAN的思路去理解云网络的边界。2. 子网把大房子切成小房间2.1 CIDR和子网划分的“算术题”VPC创建时你必须先给它指定一个CIDR网段。云厂商通常会建议你用10.0.0.0/8、172.16.0.0/12、192.168.0.0/16这些私网段但实际规划时大多数人会在10.0.0.0/8里面挑一块。比如你选了10.0.0.0/16这个网段一共有2的16次方个地址也就是65536个可用IP范围从10.0.0.0到10.255.255.255。子网就是在VPC这个大网段里再切一刀。把10.0.0.0/16切成若干10.0.X.0/24每个子网就有256个地址其中网络地址、网关地址、广播地址会被占用具体占几个看云厂商。阿里云默认保留前3个AWS默认保留前5个总之能被你分配给云服务器的地址数是“总数减预留数”。选/24是最常见的做法但如果你只有一个测试环境只有三五台机器划一个/24会浪费大量IP划一个/2816个地址可能更合适反之如果业务扩容很快一开始就划/16也许更省事。所以子网划分本质是一道算术题数一数当前机器数量预估未来两年的增量再留出至少一倍缓冲。云上子网划分完以后基本没法改网段只能重建所以宁可一开始多规划别抠门。我见过不少人在VPC创建时随手填一个/16然后所有资源全堆在同一个/24子网里后续做环境隔离、做流控、做NAT全都得从头折腾。正确做法是先按业务模块切前端一个子网、后端一个子网、数据库一个子网互相之间用路由和安全规则控制这才是子网真正的价值——不是为了数IP而是为了划分管控边界。2.2 子网之间怎么“串门”路由表子网划好之后子网之间怎么通信这就轮到路由表登场。VPC里有一个“系统路由表”它默认包含了到本VPC内所有子网的路由所以大多数云平台上同一VPC内的子网默认互通。比如说你的VPC是10.0.0.0/16划分了10.0.1.0/24和10.0.2.0/24两个子网系统路由表里就会有两条直连路由去往10.0.1.0/24的下一跳是子网1的网关去往10.0.2.0/24的下一跳是子网2的网关。两台ECS之间发包底层早已由云网络转发层搞定用户不需要操心。那什么时候要动路由表最常见的是“出公网”子网里的服务器要访问互联网就需要一条默认路由0.0.0.0/0指向NAT网关或互联网网关还有“连接专线”你办公室跟云上VPC打通时需要在VPC路由表里加一条指向专线网关的路由。这些都是自定义路由的典型场景。2.3 划分子网的几条实战建议第一规划前先画一张“业务拓扑图”把前端、后端、数据库、管理网分开不同模块放不同子网以后配ACL和安全组时才不会误伤。第二子网大小按“头一年用量乘2”来定。假设生产环境预计30台机器/24已经富余但别一上来就/16IP地址多了反而让人失去规划意识。第三跨高可用区域时要保证每个可用区都有对应子网。云上同城容灾通常靠多可用区如果你的子网全挤在一个可用区容灾扩缩容都会受限。第四不要跟业务抢地址。很多人习惯用192.168.0.0/16但家里路由器也是这个网段以后做专线互联或者混合云组网时地址冲突会让你怀疑人生。能用10.0.0.0/8里的独立段就尽量避开常见家用网段。3. 虚拟网卡虚拟机连网的“最后一步”3.1 虚拟网卡到底是怎么工作的传统服务器要上网得有物理网卡、网线、交换机端口这三个要素。虚拟机里没有硬件网卡引擎盖下面由Hypervisor虚拟出一个“虚拟网卡”缩写vNIC用软件模拟了物理网卡的收发能力。虚拟机里面看到的eth0或者“以太网适配器”就是它。数据流向大概是这样的虚拟机里的应用发包 → 操作系统网络协议栈交给虚拟网卡 → Hypervisor把包从vNIC收下转给虚拟交换机vSwitch→ vSwitch根据MAC地址和VLAN策略把包送到对应的物理网卡 → 物理网卡把包发到物理交换机。反过来收包也是同样链路。这里有个关键词叫“驱动”。在KVM这类虚拟化环境里虚拟网卡通常用virtio半虚拟化驱动性能接近物理网卡。如果Windows虚拟机没装virtio驱动网卡会显示成“以太网控制器未识别”或者工作在半虚拟化模式下的慢速兼容层网络吞吐会掉得很厉害。很多云平台在装系统时就能自动附带驱动但如果你自己上传ISO装系统第一件事就是装驱动否则后续配置IP、登录远程桌面都是空谈。3.2 实操Windows Server 2019装完Hyper-V后怎么配虚拟网卡很多人搜“Windows Server 2019安装HyperV后如何配置虚拟网卡”是因为装完Hyper-V角色之后宿主机莫名其妙断网了。原因是创建“外部虚拟交换机”时Hyper-V把物理网卡绑定到了vSwitch上宿主机的网络连接从物理网卡挪到了新生成的虚拟网卡“vEthernet (交换机名称)”上原物理网卡上的IP配置不会自己迁移。我惯用的操作顺序是这样在“服务器管理器”里安装Hyper-V角色重启。打开“Hyper-V管理器”点右侧“虚拟交换机管理器”新建虚拟网络交换机。选择“外部”绑定你实际接入上联的物理网卡。这里最关键的一步是勾选“允许管理操作系统共享此网络适配器”不勾的话宿主机自己就会失去这个网卡的上网能力。创建完成后打开“网络连接”面板找到新的vEthernet虚拟网卡手动填入原来的IP地址、掩码、网关和DNS。宿主机网络通了之后再给VM分配虚拟网卡绑定到这个外部交换机上进虚拟机里配上同一网段的IP就能互通。这个过程中的坑我全踩过绑定错物理网卡导致上联全断忘记勾选共享导致宿主机只有虚拟交换机没有管理地址还有一次物理网卡上有多个VLAN标签Hyper-V需要额外配置VLAN ID才能让VM走指定Tag。如果是多块网卡的宿主机建议干净利落地区分“管理网卡”和“业务网卡”管理网卡不要绑进外部交换机避免一失手把自己锁在门外。3.3 云服务器上的虚拟网卡操作习惯云上服务器的“虚拟网卡”一般指控制台里看到的“弹性网卡”它比Hyper-V的vNIC粒度更细一台云服务器可以挂多块网卡分别属于不同子网用于不同的业务面。比如一块管理网卡走运维通道一块业务网卡走数据流量再挂一块网卡给备份服务互不干扰。操作上有个容易被忽略的点云平台上改网卡配置时比如给网卡加辅助私网IP或者把网卡从一个子网迁移到另一个子网最好先在机器内执行对应系统的网络命令刷新而不是直接重启。有些系统重启后会因为DHCP租约没释放把辅助IP丢掉误以为平台配置没生效。我一般会在变更后查看系统内的网卡配置文件和网卡状态确认无误再继续下一步。4. ACL网络世界的门禁规则4.1 ACL规则是怎么“排队”的ACL全称Access Control List翻译过来就是访问控制列表。它是一串有序的规则每条规则包含匹配条件和动作。匹配条件可以精细到源IP、目的IP、源端口、目的端口、协议类型TCP/UDP/ICMP等动作只有两个放行或者拒绝。ACL最核心的要点是“顺序敏感”。绝大多数设备逐条从上到下匹配命中第一条就不再往后看了。所以范围越具体的规则要放前面范围越宽的兜底规则放后面。比如你写一条“拒绝所有”放在前面后面再怎么写“允许Web流量”都不生效因为流量全被前面拦了。这里就不得不提“ACL默认流行为”。不同设备、不同云平台的默认动作不一样有的平台在没有规则命中时默认拒绝所有流量有的平台默认允许。华为设备上一条空ACL被用于流量过滤时的行为也容易让新手困惑——如果你不确定就直接显式写出一条规则要么写一条permit/deny对应默认流量要么在测试环境先验证。千万别假定“不写就是不通”或者“不写就是全通”这是最容易翻车的地方。4.2 安全组和ACL的分工云平台里ACL经常跟安全组放一起讲但它俩不是一回事。安全组是“实例级”的绑定在虚拟网卡上而且是有状态的。什么叫有状态你发出去的请求回应报文会被自动放行不需要单独配置回包规则。安全组能精确到某台云服务器比如“只允许从办公网访问这台机器的22端口”。网络ACL是“子网级”的绑定在子网边界是无状态的。无状态意味着你放行了入方向的请求出方向的回应包不会自动放行必须再显式配置一条出方向规则。如果你在云上把层级搞混最容易出现的现象就是数据库子网的入方向ACL放行了来自应用子网的3306但出方向没放行回包结果应用连数据库“通一半”——新建连接握手卡住超时重试。我建议的配合方式是外层用网络ACL做子网级别的大范围拦截比如“整个数据库子网禁外网访问”内层用安全组做实例级别的精细放行比如“只有应用服务器能访问某一台数据库”。这样层次分明排查问题时也容易定位到底是谁拦的。4.3 实操华为/华三路由器ACL配置的固定套路传统网络设备上配ACL虽然和云控制台点点鼠标不一样但思路通用。华为设备上基本ACL编号范围是2000~2999只能匹配源IP高级ACL编号范围是3000~3999可以匹配协议、端口、目的地址等。华三的语法略有差异通常用“advanced ACL”加编号。举个最常见的内网访问控制例子只允许办公网192.168.10.0/24访问公网WEB服务器10.10.10.10的443端口其他外部访问一律拒绝acl number 3001 rule 5 permit tcp source 192.168.10.0 0.0.0.255 destination 10.10.10.10 0.0.0.0 destination-port eq 443 rule 10 deny ip注意华为ACL用的是反掩码0.0.0.255表示匹配前三段固定、最后一段任意。然后在接口上应用interface GigabitEthernet0/0/1 traffic-filter inbound acl 3001华三设备的绑定命令一般是在接口下用“packet-filter 3001 inbound/outbound”具体以设备版本为准但“先定义ACL、再绑定接口”的套路是一样的。IPv6的ACL实验我做过一段华三的语法顺序和IPv4也类似acl ipv6 advanced 3001 rule 5 permit tcp source 2001:db8:1::/64 destination 2001:db8:2::/64 destination-port eq 80还有人问“ACL和ACLLite有什么区别”。就我接触过的设备而言ACLLite更像是一个精简版ACL通常用于硬件转发的快速匹配支持的字段少、规则数量也可能受限适合对“只做简单放行/拒绝”的场景完整版ACL支持时间段、报文分片匹配、流量统计等高级能力。具体差异一定以机器上敲“display acl”和查对应手册为准别拿网上说法直接套。ACL还可以配合“策略路由”使用ACL负责识别出“哪些流量需要特殊路由”策略路由负责决定“这些流量下一跳走哪里”。比如让来自办公网的流量走专线路由其他流量走公网出口就是把ACL和策略路由串起来用的典型场景。5. 实操踩坑虚拟网卡与ACL的高频问题5.1 常见报错速查表下面这些报错和问题都是工作群和论坛里反复出现的我把它们整理成一张速查表报错/现象可能原因处理思路拉起虚拟网卡失败虚拟化驱动未安装/被禁用或宿主服务异常检查设备管理器里是否有未被识别的网络控制器重装virtio/netkvm驱动确认相关虚拟化服务已启动请确保虚拟网卡已经安装在系统上并处于启用状态系统网卡驱动丢失、适配器被禁用或登录时网卡无有效IP用控制台VNC进入系统启用网卡重装驱动确认IP获取成功后再重新登录检测到虚拟网卡上存在未知协议可能导致虚拟网卡被截流安全软件/DPI误报或驱动兼容性问题升级网卡驱动关闭协议卸载功能如RSS、LRO、GRO给安全软件加白名单避免安装来路不明的流量整形工具无法启动虚拟网卡适配任务操作权限不足或平台Agent异常确认账号有网络管理权限重启平台Agent服务必要时工单联系厂商ACL规则ID自动增加设备默认步长为5不指定rule编号会自动按步长递增想精确控制顺序就显式指定编号例如rule 7、rule 10ACL默认行为不明确不同平台/默认动作不一致先查询默认动作再显式写一条兜底规则不要赌默认行为5.2 排查网络问题的分层思路不管是服务器不通、ACL拦错、还是网卡异常我的排查习惯都是“四层漏斗”。先看链路层虚拟网卡是否up、是否获得了IP再看一层的网关能不能ping通网关网关配置是否和子网一致然后看路由从源到目的的路由表项是否存在最后才看安全控制ACL、安全组、系统防火墙。很多人一上来就翻ACL规则结果发现网关就没通纯属浪费时间。我印象最深的一次是某项目两套VPC之间做专线互通应用连接总是不稳定。翻了一圈路由表和网卡配置都没问题最后发现是安全组只加了入方向规则把回应流量拦截了——因为云上安全组虽然状态化但如果你用“禁止出方向所有流量”的策略做了收紧回包也会被拒。从那以后凡是网络不通我都会先确认“双向”的规则。最后说点个人体会VPC、子网、虚拟网卡、ACL这四个概念本质是把传统网络里交换机、路由器、防火墙、网线的那套思路软件化、云化。刚开始接触时不要急着背配置命令先做到能把“包从虚拟机到哪里、被谁转发、被谁拦截”这条链路讲清楚再多的概念也唬不住你。我自己带新人时也总爱让他们找一张白纸把这四层画出来画明白了问题就解决了一半。
