多层交换与DNS综合实训：从VLAN划分到内网域名解析全流程解析

发布时间：2026/10/23 3:57:40
多层交换与DNS综合实训：从VLAN划分到内网域名解析全流程解析
这个项目是网络课程里第六个综合实训名字很直白——把多层交换和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 地址规划表和设备角色要先定下来动手配置前建议先把地址规划表写出来这玩意就是整个网络的“地图”。项目里我通常建议用下面这样的规划区域VLAN网段网关用途办公区VLAN 10192.168.10.0/24192.168.10.254办公终端研发区VLAN 20192.168.20.0/24192.168.20.254研发终端服务器区VLAN 30192.168.30.0/24192.168.30.254DNS服务器、业务服务器等设备角色上一台三层交换机作为核心提供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”时系统会自动把第一个点转成所以实际意思就是adminlab.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记录类型速查与项目选型做这个项目不一定把所有记录类型都用上但了解哪些记录对应什么场景是基本功。记录类型作用项目中使用场景A域名到IPv4地址的正向映射www.lab.local → 192.168.30.11AAAA域名到IPv6地址的正向映射本项目不需要CNAME别名指向另一个域名可以给www加别名属于加分项MX邮件交换记录如果加mail记录可配套配置NS指定域名由哪台DNS服务器解析zone文件里必须有PTRIP地址到域名的反向映射反向zone文件里使用SOA起始授权记录标记权威信息与版本号zone文件必须存在TXT文本记录常见用于验证和服务发现一般暂不需要DNS解析方式也要区分一下。终端发送给DNS服务器的通常是递归查询请求意思是“你帮我查到底给我最终结果”。DNS服务器之间通常是迭代查询意思是一个服务器告诉你“去问下一台”。你的内网DNS如果不配置转发遇到lab.local之外的域名会尝试从根服务器开始迭代如果想让它把未命中的请求转给上游公共DNS可以在配置里加options { forwarders { 223.5.5.5; 119.29.29.29; }; };这样内网域名走本地权威解析公网域名转发到上游公共DNS处理更符合真实办公网的使用习惯。3.4 让终端通过DHCP真正用上内网DNSDNS服务器配好以后最关键的一步是把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地址。终端重新获取地址后用下列命令确认Windowsipconfig /all看“DNS Servers”那行。Linuxcat /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 cant 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 高频故障与排查速查表把项目里出现频率最高的故障整理成一张表排查时先对着看故障现象可能原因排查动作终端Ping不通网关接入端口VLAN配错或终端地址手滑配错查看交换机端口VLAN归属检查Access端口配置能Ping网关跨VLAN Ping不通三层交换机未启用路由或VLANIF接口未配/未启用查看路由表检查VLANIF接口状态和地址核心能Ping通DNS服务器终端不行Trunk漏放行VLAN30或ACL拦截查看Trunk放行列表查看ACL命中计数DHCP能拿到IP但DNS字段为空DHCP地址池里漏配dns-list检查DHCP地址池重新获取地址DNS服务已启动外部查询超时防火墙拦截UDP 53或BIND只监听本机回环查看服务监听地址检查系统防火墙规则解析返回NXDOMAINzone文件没有对应记录或记录名有误named-checkzonenslookup查询SOA解析返回SERVFAILSOA语法错误或zone文件权限问题查看BIND日志检查文件属主终端能解析域名但特别慢转发器配置了不可达的上游DNS向上游DNS测试连通性调整转发配置这张表基本覆盖了我在项目里遇到过的大部分问题。如果你遇到的问题不在表里也建议从网络层开始逐层排查。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 从实训走向真实网络的三个延展方向这个项目做完相当于掌握了一条小型园区网的核心链路。想让它更接近真实生产环境有三个方向可以继续往下走。第一个方向是双核心加高可用。把单台三层交换机换成两台之间部署堆叠或VRRPVLANIF地址作为虚拟网关在一台设备故障时另一台无缝接管。对于业务连续性要求高的场景这是标配。第二个方向是DNS主从和缓存分层。为主体DNS增加一台从服务器配置zone传输SOA序列号更新后主从之间的zone数据自动同步。再往上层加一层缓存DNS只做递归缓存不存权威数据能有效分担主服务器压力也提升终端解析速度。第三个方向是ACL和出口NAT。内网设备访问服务器区时可以用ACL控制哪些VLAN能访问服务器区的哪些端口访问外部网络时要通过NAT把私有地址转换出去同时配合安全策略对流量做管控。这三个方向全是这个综合项目的直接延伸也是真实网络里天天在用的东西。5.2 几点个人体会项目做了几轮之后我最大的体会是排查网络问题不能跳层。看起来是DNS解析失败根因经常在网络层。你一上来就怀疑BIND配置最后可能白折腾一小时回头发现只是哪个端口VLAN没划对。还有就是地址规划表和配置文档一定要留好。这个项目涉及VLAN、IP、网关、DNS、中继、路由表信息密度已经不算低了。没有一张清晰的地址规划表配到后面你自己都会绕晕。每完成一个阶段把配置保存下来改动之前备份万一改坏了还能快速回滚。最后分享一个小习惯做联调之前先在整个网络里找一个“基准点”。比如核心交换机能不能Ping通DNS服务器这个点通了说明核心和服务器区没问题再让终端Ping通网关就说明接入侧没问题。从核心向外逐步扩大测试范围比满网络乱试要高效得多。这个思路不仅适用于这个项目以后遇到任何多设备联调都能少走很多弯路。