企业官网建设流程全解析

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，划一个/28（16个地址）可能更合适；反之如果业务扩容很快，一开始就划/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已经富余，但别一上来就/16，IP地址多了反而让人失去规划意识。

第三，跨高可用区域时，要保证每个可用区都有对应子网。云上同城容灾通常靠多可用区，如果你的子网全挤在一个可用区，容灾扩缩容都会受限。

第四，不要跟业务抢地址。很多人习惯用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配置不会自己迁移。

我惯用的操作顺序是这样：

1. 在“服务器管理器”里安装Hyper-V角色，重启。
2. 打开“Hyper-V管理器”，点右侧“虚拟交换机管理器”，新建虚拟网络交换机。
3. 选择“外部”，绑定你实际接入上联的物理网卡。这里最关键的一步是勾选“允许管理操作系统共享此网络适配器”，不勾的话宿主机自己就会失去这个网卡的上网能力。
4. 创建完成后，打开“网络连接”面板，找到新的vEthernet虚拟网卡，手动填入原来的IP地址、掩码、网关和DNS。
5. 宿主机网络通了之后，再给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 常见报错速查表

下面这些报错和问题，都是工作群和论坛里反复出现的，我把它们整理成一张速查表：

5.2 排查网络问题的分层思路

不管是服务器不通、ACL拦错、还是网卡异常，我的排查习惯都是“四层漏斗”。先看链路层：虚拟网卡是否up、是否获得了IP；再看一层的网关：能不能ping通网关，网关配置是否和子网一致；然后看路由：从源到目的的路由表项是否存在；最后才看安全控制：ACL、安全组、系统防火墙。很多人一上来就翻ACL规则，结果发现网关就没通，纯属浪费时间。

我印象最深的一次是某项目两套VPC之间做专线互通，应用连接总是不稳定。翻了一圈路由表和网卡配置都没问题，最后发现是安全组只加了入方向规则，把回应流量拦截了——因为云上安全组虽然状态化，但如果你用“禁止出方向所有流量”的策略做了收紧，回包也会被拒。从那以后，凡是网络不通，我都会先确认“双向”的规则。

最后说点个人体会：VPC、子网、虚拟网卡、ACL这四个概念，本质是把传统网络里交换机、路由器、防火墙、网线的那套思路软件化、云化。刚开始接触时不要急着背配置命令，先做到能把“包从虚拟机到哪里、被谁转发、被谁拦截”这条链路讲清楚，再多的概念也唬不住你。我自己带新人时，也总爱让他们找一张白纸，把这四层画出来，画明白了，问题就解决了一半。