企业官网建设流程全解析

这个项目是网络课程里第六个综合实训，名字很直白——把多层交换和DNS放在一起做。我接触过不少做这个项目的同学，单项实验都还不错，VLAN会划，VLANIF会配，DNS也能跑起来，但一旦联调，问题就冒出来了：终端能Ping通网关，浏览器却打不开内网域名；DNS服务看着起来了，解析却一直不给结果；甚至有人配了半天发现，终端拿到的IP地址都是错的。这些现象背后，其实把网络分层模型里从数据链路层到应用层的内容全部串了一遍。这篇文章从拓扑设计讲起，到交换机侧配置、DNS配置、再到常见的联调故障，完整走一遍这个项目，同时把实操里容易踩的坑一并写出来，希望能给正在做这个项目的你一点实在的参考。

1. 项目整体设计：先想清楚拓扑和地址再动手

1.1 这个项目到底在模拟一张什么网

这个综合项目并不是简单练某一台设备的配置，而是在模拟一个典型的小型单位网络：有办公区、有研发区、有一个独立的服务器区，终端之间需要互通，终端还要能通过域名访问服务器区里的业务系统。

我在给同学讲这个项目时，经常把场景说得更具体一点：某单位有两层楼，一层办公区，一层研发区，机房单独划一个服务器区。三台交换机组成一张网，其中一台三层交换机作为核心网关，另外两台二层交换机分别负责两个区域的终端接入。DNS服务器放在服务器区，所有终端通过DHCP自动获取地址，并通过DNS完成内网业务域名的解析。

把这个场景落到设备上，就需要解决三个问题：第一，不同部门的终端要隔离广播域，同时又要能互相通信；第二，终端不能手动配地址，要能自动获取到正确的IP、网关和DNS；第三，终端输入一个域名，要能通过DNS服务器拿到对应的服务器IP。这三个问题正好对应VLAN划分、三层路由、DHCP和DNS配置。

1.2 为什么DNS故障要从交换机找原因

很多人做这个项目有个误区，觉得DNS是应用层的事，跟交换机关系不大。实际上DNS查询报文从终端发出去，到DNS服务器返回结果，中间要穿过接入交换机的二层转发、核心交换机的三层路由、还要经过Trunk链路和VLANIF网关。任何一个环节配置错误，DNS都会“理所当然”地解析失败。

这个项目最有价值的地方就在这里：它把数据链路层、网络层、传输层和应用层串成了一条完整的数据通路。Ping不通IP是网络层问题，DNS解析失败则可能是网络层、传输层或应用层任意一层出的问题。排查这类综合故障，必须自底向上验证，不能一上来就怀疑DNS配置。这个习惯在真实运维里非常重要。

1.3 地址规划表和设备角色要先定下来

动手配置前，建议先把地址规划表写出来，这玩意就是整个网络的“地图”。项目里我通常建议用下面这样的规划：

设备角色上，一台三层交换机作为核心，提供VLAN10、VLAN20、VLAN30的VLANIF网关；两台二层交换机作为接入，分别接办公区和研发区的终端；DNS服务器放在服务器区，固定IP建议用192.168.30.10。

网关地址选.254而不是.1，是实际工程里比较常见的习惯：把.1这类地址留给网络设备管理地址，把.10、.20这类固定地址预留给服务器，避免以后加设备时地址冲突。这个细节看似不起眼，但能在后面的配置中省去很多麻烦。

还有一点要提醒：如果终端数量不多，核心交换机也可以直接兼做接入；但项目要求是“多层交换机综合”，所以核心加接入的结构能让你把Trunk、链路聚合、VLANIF这些知识点全部覆盖到，做起来更完整。

2. 交换机侧配置：VLAN、SVI、链路聚合与DHCP一条线

2.1 VLAN划分与端口类型选择

VLAN的核心作用是隔离广播域。同一个VLAN里的终端能直接二层互通，不同VLAN的终端默认是不能互通的，必须靠三层路由转发。在这个项目里，办公区、研发区、服务器区分别对应三个VLAN。

配置前先要分清端口类型：

• Access端口：一般用来接终端，端口只属于一个VLAN，发出去的帧不带Tag。
• Trunk端口：一般用来连接交换机之间，承载多个VLAN，帧带着802.1Q Tag在链路上传输。

以常见企业级设备命令行风格为例，核心交换机上的VLAN创建和接口划分大概是这样的：

system-view vlan batch 10 20 30 interface GigabitEthernet 0/0/1 port link-type access port default vlan 10 interface GigabitEthernet 0/0/2 port link-type access port default vlan 20 interface GigabitEthernet 0/0/24 port link-type trunk port trunk allow-pass vlan 10 20 30

如果用的是其他品牌的设备，命令关键字会略有差异，思路完全相同。接入交换机上也一样，连接终端的口设成Access并划入对应VLAN，连接核心的上联口设成Trunk并放行所有相关VLAN。

这里最容易踩的坑是：核心交换机上创建了VLANIF，但接入交换机上联口的Trunk列表里忘了放行某个VLAN，导致那个VLAN的终端连网关都不通。配置完后，一定要在交换机上查看端口允许通过的VLAN，不要想当然。

2.2 SVI网关配置：VLANIF的配置逻辑

三层交换机为什么能承担网关角色？靠的就是SVI，也就是交换虚拟接口，俗称为VLANIF接口。它是为某个VLAN创建的三层逻辑接口，既作为该VLAN内终端的网关地址，又能参与三层路由转发。

配置非常简单：

interface Vlanif10 ip address 192.168.10.254 255.255.255.0 interface Vlanif20 ip address 192.168.20.254 255.255.255.0 interface Vlanif30 ip address 192.168.30.254 255.255.255.0

配完后，终端把网关指向VLANIF地址，核心交换机就能在VLAN之间做路由转发。这个过程怎么理解呢？终端发来的数据帧到达交换机后，交换机会剥掉VLAN Tag，把报文交给对应的VLANIF接口，相当于报文进入了三层模块，然后交换机查路由表找下一跳，再把报文从另一个VLANIF转发出去，重新打上新的VLAN Tag。

这里有个容易忽略的细节：有些三层交换机默认不开启IP路由转发功能，需要显式执行类似“ip routing”的命令，否则VLANIF之间不会互相转发。配置完以后，可以用查看路由表的命令确认一下，看到VLAN10、VLAN20、VLAN30三个网段的路由条目都在，才算真正配好。

另外还要注意，VLANIF接口能不能up，取决于有没有物理端口在这个VLAN里。如果某个VLAN没有接入任何端口，VLANIF会一直处于down状态，三层路由也会受影响。所以配置顺序应该是：先创建VLAN，再把端口划入VLAN，最后配VLANIF地址。

2.3 上联链路聚合：别让一条线拖垮全盘

在实际网络里，接入交换机到核心交换机之间一般不会只连一根线，而是用两条甚至更多物理链路做链路聚合，也就是Eth-Trunk。链路聚合的核心作用有两点：增加带宽和提供冗余。

很多人误解链路聚合就是“两条线带宽翻倍”，其实没那么简单。以太网链路聚合的负载分担一般按哈希因子分配，常见的是源MAC、目的MAC、源IP、目的IP或者五元组。一条TCP流只会在某一条成员链路上传输，不会把同一流拆成两半，否则会产生乱序问题。所以如果一个终端占了很大流量，聚合链路的总带宽看起来并没有达到两倍，这是正常现象，不要以为是配置错了。

配置链路聚合时，两端都要配置同样的成员口。核心交换机上：

interface Eth-Trunk 1 port link-type trunk port trunk allow-pass vlan 10 20 30 interface GigabitEthernet 0/0/23 eth-trunk 1 interface GigabitEthernet 0/0/24 eth-trunk 1

接入交换机上同样要把两个物理口加入Eth-Trunk，并配置相同的Trunk设置。两端成员口的速率、双工模式、VLAN配置必须一致，否则协商会失败。还有一个工程经验：物理口加入聚合组之后，这个口上原有的配置会被清空，所以要先把聚合口配置好，再加入成员口，避免配置丢失后出现VLAN放行不一致。

2.4 DHCP下发地址与中继的真实配置

终端数量多的时候，不可能一台台手动配IP，必须用DHCP自动下发。这个项目里，DHCP服务放在哪台设备上有两种选择。

第一种，由核心交换机直接做DHCP Server。在小规模网络里很常见：

ip pool vlan10 network 192.168.10.0 mask 255.255.255.0 gateway-list 192.168.10.254 dns-list 192.168.30.10 interface Vlanif10 dhcp select global

第二种，DHCP服务器放在服务器区，由核心交换机做DHCP中继。这种方式更接近真实企业的集中管理模型。因为DHCP的发现报文是广播报文，不能跨VLAN，所以需要在VLANIF接口上开启中继功能，让交换机把这类广播报文转换为单播，转发给指定的DHCP服务器：

interface Vlanif10 dhcp select relay dhcp relay server-ip 192.168.30.10 interface Vlanif20 dhcp select relay dhcp relay server-ip 192.168.30.10

用中继模式时，DHCP服务器上要为每个网段分别创建地址池，并在地址池里指定对应的网关和DNS。很多人在这一步漏掉dns-list配置，导致终端能拿到IP，但拿不到DNS服务器地址，后面解析内网域名全部失败。记住一句话：DHCP不只下发IP，还负责下发网关和DNS。

2.5 路由与ACL：让DNS报文去回畅通

三层交换机配好VLANIF之后，VLAN10和VLAN20的访问请求要靠路由表走向服务器区。如果DNS服务器就在VLAN30里，VLANIF30和VLANIF10、VLANIF20都在核心交换机上，属于直连路由，配置VLANIF地址后路由表会自动出现。如果DNS服务器在另一台设备上、不是直连网段，就要配置静态路由指向对端设备。

从三层到DNS服务器的方向也要考虑：DNS服务器收到终端查询请求后，回复报文要能原路返回核心交换机。很多时候排查网络问题会发现“有去无回”，原因就是服务器侧的网关指向错误，回复报文不知道往哪走。

如果交换机上配置了ACL安全策略，还要记得放行UDP和TCP的53端口。DNS默认走UDP 53，响应报文如果太大或需要可靠传输时会切到TCP 53。ACL里只放行UDP没放行TCP，某些大响应解析会失败，这种问题比较隐蔽，建议直接把两条都放行。

3. DNS服务配置：内网域名解析从零开始

3.1 一条DNS查询报文从PC到服务器的完整路径

先理解DNS流量在网络里走的路，后面排错就有方向了。假设办公区终端要解析 www.lab.local：

终端读取本机的DNS配置，构造一个DNS查询报文，目的IP是192.168.30.10，源端口是随机的高端口，目的端口是53。终端发现目的IP不在本网段，就把报文交给默认网关192.168.10.254。

这个报文到达核心交换机的VLANIF10后，交换机查路由表，目的地址192.168.30.0/24是直连网段，于是报文从VLANIF30转发出去，最终到达DNS服务器。DNS服务器查到对应记录后，把响应报文按原路返回给终端。

在这个过程中，只要接入交换机的VLAN划分有问题、Trunk放行漏了VLAN30、VLANIF30没配地址、路由表缺条目、或者ACL拦截了53端口，任何一步出错，终端DNS解析都会失败。这就是为什么我在前面反复强调：DNS问题的根源经常不在DNS服务器本身。

3.2 Linux BIND内网DNS搭建实例

项目里DNS服务器我建议用Linux系统加BIND9软件，免费且贴近真实生产环境。以Debian/Ubuntu系统为例：

apt update apt install bind9

装好后，编辑BIND的主配置文件，比如/etc/bind/named.conf.local，添加两个zone，一个正向，一个反向：

zone "lab.local" { type master; file "/etc/bind/db.lab.local"; allow-transfer { none; }; }; zone "30.168.192.in-addr.arpa" { type master; file "/etc/bind/db.192.168.30"; };

正向解析zone文件db.lab.local：

$TTL 1D @ IN SOA ns.lab.local. admin.lab.local. ( 2025011601 ; serial 1H ; refresh 15M ; retry 1W ; expire 1D ; minimum ) @ IN NS ns.lab.local. ns IN A 192.168.30.10 www IN A 192.168.30.11 mail IN A 192.168.30.12

反向解析zone文件db.192.168.30：

$TTL 1D @ IN SOA ns.lab.local. admin.lab.local. ( 2025011601 ; serial 1H ; refresh 15M ; retry 1W ; expire 1D ; minimum ) @ IN NS ns.lab.local. 10 IN PTR ns.lab.local. 11 IN PTR www.lab.local. 12 IN PTR mail.lab.local.

注意写SOA记录时，域名后面的点不能漏。写“ns.lab.local”会被当成相对域名，自动拼上zone名变成“ns.lab.local.lab.local”；必须写成“ns.lab.local.”。邮箱写“admin.lab.local”时，系统会自动把第一个点转成@，所以实际意思就是admin@lab.local。

配置完成后，用系统自带的检查工具验证语法：

named-checkconf named-checkzone lab.local /etc/bind/db.lab.local

然后重启服务：

systemctl restart named systemctl status named

在实操中，很多人把zone文件放在root的主目录下，结果BIND以named用户身份运行，权限不够读不了文件，服务一直起不来。zone文件路径建议放在/etc/bind/下，并确认属主和权限正确。

3.3 DNS记录类型速查与项目选型

做这个项目不一定把所有记录类型都用上，但了解哪些记录对应什么场景是基本功。

DNS解析方式也要区分一下。终端发送给DNS服务器的通常是递归查询请求，意思是“你帮我查到底，给我最终结果”。DNS服务器之间通常是迭代查询，意思是一个服务器告诉你“去问下一台”。你的内网DNS如果不配置转发，遇到lab.local之外的域名，会尝试从根服务器开始迭代；如果想让它把未命中的请求转给上游公共DNS，可以在配置里加：

options { forwarders { 223.5.5.5; 119.29.29.29; }; };

这样内网域名走本地权威解析，公网域名转发到上游公共DNS处理，更符合真实办公网的使用习惯。

3.4 让终端通过DHCP真正用上内网DNS

DNS服务器配好以后，最关键的一步是把DNS地址下发给所有终端。推荐的方式是前面提到的，在DHCP地址池里配置dns-list字段，指向192.168.30.10。

在交换机上，如果是用全局地址池的方式下发，就在地址池里写：

ip pool vlan10 network 192.168.10.0 mask 255.255.255.0 gateway-list 192.168.10.254 dns-list 192.168.30.10

如果DHCP服务器是外置的，比如Windows服务器或Linux上的DHCP服务，就在对应网段的地址池选项里填DNS地址。

终端重新获取地址后，用下列命令确认：

• Windows：ipconfig /all，看“DNS Servers”那行。
• Linux：cat /etc/resolv.conf，看nameserver那行。

有些同学为了省事，手动在终端网卡里填DNS地址，也能解决问题，但真实网络中不建议这么做。集中下发DNS是基本功，尤其设备多了以后，手工配置根本管不过来。

4. 联调验证与典型故障排查实录

4.1 联调必须遵守的验证顺序

这个项目做完所有配置后，别急着直接nslookup域名。验证要一层一层往上走，每一步都确认通过后再进行下一步。

我总结的顺序是：

• 第1步：终端Ping自己的网关。Ping不通，先查接入端口VLAN、网线、终端IP配置。
• 第2步：跨VLAN Ping。办公区终端Ping研发区网关或对端终端，验证三层路由是否正常。
• 第3步：Ping DNS服务器的IP地址。能Ping通，说明路由器可达；Ping不通，查VLANIF30、Trunk放行、ACL。
• 第4步：nslookup刚才配置的域名。能解析，整个链路就通了。

这个顺序不能跳。如果终端Ping DNS服务器IP都不通，直接去看DNS配置，无异于修了一个根本没坏的东西。在我接触的案例里，至少一半人的DNS问题其实就是网络层问题。

4.2 nslookup和dig怎么看

nslookup是Windows和Linux都带的基础工具，适合快速验证。输入：

nslookup www.lab.local

正常时输出会显示：

Server: 192.168.30.10 Address: 192.168.30.10#53 Name: www.lab.local Address: 192.168.30.11

如果看到“connection timed out; no servers could be reached”，说明终端到DNS服务器的网络连通有问题，或者DNS服务没监听。如果显示“server can't find www.lab.local: NXDOMAIN”，说明DNS服务器能访问，但zone里没有这条记录，需要检查正向zone文件。

Linux下我更推荐用dig，信息更完整：

dig www.lab.local

关注输出的status字段：

• NOERROR：正常，有答案。
• NXDOMAIN：域名不存在，查zone文件里的记录名。
• SERVFAIL：服务器故障，最常见的原因是SOA记录格式不对、zone文件权限不对、或者无法联系上游DNS。
• REFUSED：服务器拒绝查询，检查allow-query和allow-recursion配置。

看到SERVFAIL时，第一时间看BIND日志，一般会有文件加载失败的详细原因。很多问题都能从日志里直接找到答案，比自己瞎猜快得多。

4.3 高频故障与排查速查表

把项目里出现频率最高的故障整理成一张表，排查时先对着看：

这张表基本覆盖了我在项目里遇到过的大部分问题。如果你遇到的问题不在表里，也建议从网络层开始逐层排查。

4.4 三个我踩过的坑，你最好避开

第一个坑是zone文件路径。我有一次帮同学排查SERVFAIL，查了半天发现他把正向zone文件放在/root目录下，权限是600，属主是root。BIND以named身份运行，根本读不了这个文件。服务哪怕刚重启过，加载zone时也会失败。把文件挪到/etc/bind/下并改属主，问题立刻消失。

第二个坑是Trunk接口漏放行VLAN30。核心交换机上VLANIF30配得好好的，DNS服务器地址也Ping得通，但是办公区终端访问不了服务器区。最后发现接入交换机连接核心的Trunk口只放行了VLAN10和20，把30漏了。核心侧配置没问题，接入侧漏了放行，等于断了一截路。提醒各位，排查链路问题时，两端都要看，别只看核心。

第三个坑是DHCP下发DNS地址后，客户端缓存了旧配置。很多人改完DHCP地址池，觉得不行就让终端“重新获取”，但Windows有时候没有真正释放旧地址，导致看起来不对。正确的做法是先执行ipconfig /release，再执行ipconfig /renew，必要时重启网卡。这个看起来很小，但实测非常容易踩中。

5. 做完之后值得保留的经验与扩展方向

5.1 从实训走向真实网络的三个延展方向

这个项目做完，相当于掌握了一条小型园区网的核心链路。想让它更接近真实生产环境，有三个方向可以继续往下走。

第一个方向是双核心加高可用。把单台三层交换机换成两台，之间部署堆叠或VRRP，VLANIF地址作为虚拟网关，在一台设备故障时另一台无缝接管。对于业务连续性要求高的场景，这是标配。

第二个方向是DNS主从和缓存分层。为主体DNS增加一台从服务器，配置zone传输，SOA序列号更新后，主从之间的zone数据自动同步。再往上层加一层缓存DNS，只做递归缓存不存权威数据，能有效分担主服务器压力，也提升终端解析速度。

第三个方向是ACL和出口NAT。内网设备访问服务器区时，可以用ACL控制哪些VLAN能访问服务器区的哪些端口；访问外部网络时，要通过NAT把私有地址转换出去，同时配合安全策略对流量做管控。这三个方向全是这个综合项目的直接延伸，也是真实网络里天天在用的东西。

5.2 几点个人体会

项目做了几轮之后，我最大的体会是：排查网络问题不能跳层。看起来是DNS解析失败，根因经常在网络层。你一上来就怀疑BIND配置，最后可能白折腾一小时，回头发现只是哪个端口VLAN没划对。

还有就是地址规划表和配置文档一定要留好。这个项目涉及VLAN、IP、网关、DNS、中继、路由表，信息密度已经不算低了。没有一张清晰的地址规划表，配到后面你自己都会绕晕。每完成一个阶段，把配置保存下来，改动之前备份，万一改坏了还能快速回滚。

最后分享一个小习惯：做联调之前，先在整个网络里找一个“基准点”。比如核心交换机能不能Ping通DNS服务器，这个点通了，说明核心和服务器区没问题；再让终端Ping通网关，就说明接入侧没问题。从核心向外逐步扩大测试范围，比满网络乱试要高效得多。这个思路不仅适用于这个项目，以后遇到任何多设备联调，都能少走很多弯路。