不知道大家有没有这种体会学网络的时候单独学交换、单独学路由甚至单独配一台DNS服务器其实都挺顺的。但一旦要把这些技术揉进同一个项目里让它们像真实企业网络那样协同工作很多人就卡住了。我最近刚好把一个“多层交换机和DNS综合项目”从头到尾完整实施了一遍从拓扑设计、VLAN划分、三层转发再到域名解析服务上线整个过程踩了不少坑也积累了一些书本上不会明说的经验。这篇东西就是记录整个项目的设计和落地过程。不管你是正在准备综合实验的在校学生还是刚入职想搞懂企业网络真实拓扑的初级工程师或者是打算把家里的网络设备整理成“麻雀虽小五脏俱全”的折腾型选手这个项目都能给你一个从零到一的完整参考。它不是一个单纯的命令堆砌而是一套“先想清楚为什么再动手敲命令”的实操逻辑。1. 项目需求与整体设计思路1.1 为什么非要把多层交换和DNS放在一起做先说个很多人容易忽略的点DNS这个服务单独看它就是一个解析域名的软件似乎和交换机八竿子打不着。但在真实的企业网络里DNS却是整个网络的“导航系统”。你没有DNS客户端就没法通过名字访问服务器而你没有一套合理的三层网络架构DNS服务器就算配置得再完美也可能因为广播域隔离、路由不可达、接口策略等奇奇怪怪的原因“隐身”。所以这个综合项目的第一层价值是强迫你站在全局视角看问题交换层解决“数据能不能通”DNS解决“用户能不能用名字找到资源”。前者是管道后者是门牌号。把这两者联动起来才算是把一个“能跑起来”的网络变成“好用”的网络。我这套项目的假定场景是这样的一家中小型公司内部划分了三个业务部门比如研发部、市场部、财务部另外还有一个独立的服务器区域专门用来跑内部OA、文件共享和DNS解析服务。公司内部的员工电脑希望通过固定的域名来访问OA系统而不是每次去背IP地址。整个网络要求做到部门间互访可控、服务器区域单独保护、DNS解析稳定高效。1.2 核心需求拆解与设计决策接到这种需求别急着开模拟器或者拿真机插线先把需求拆成几个明确的技术问题第一广播域隔离问题。三个部门加上服务器区如果全怼在一个网段里广播报文会把整张网络拖慢而且部门之间没有隔离安全上也说不过去。所以必须做VLAN划分。很多入门者说“我划分了VLAN各配各的网段”但忘了部门之间还要通信结果两边直接就ping不通了。这就是引出多层交换的第一个关键点——VLAN间路由。第二路由转发问题。传统思路是“不同VLAN用路由器去路由”用一台路由器接多个物理接口每个接口一个网段。但真实场景里更简洁的做法是用三层交换机来做。三层交换机相当于“交换机和路由器的合体”不同VLAN之间通过虚拟接口SVI直接路由转发速度比普通路由器快得多而且节省物理接口。这里我最终选择的是三层交换方案具体的原理对比后面会展开。第三命名解析问题。整个网络里有好几台服务器、几十台终端IP地址如果要靠脑袋记太痛苦。DNS要承担两个方向的解析一是正向解析把名字翻译成IP二是有条件的话做反向解析方便网络设备做日志记录和排障。另外企业内部域名不需要暴露到公网所以DNS服务器只需要对内服务不需要完全照搬公网DNS那套复杂的递归逻辑。1.3 拓扑规划与地址分配方案拓扑规划是整个项目的骨架骨架歪了后面填肉再努力也白搭。我建议先画一张明确的拓扑图再动手配置防止配置到一半自己都糊涂了。我的整体规划分三层核心设备是一台三层交换机下面挂两台二层接入交换机也可以再增加冗余链路但初版不建议加太多先把基础打通终端和服务器分别接入对应的VLAN。具体地址规划可以参考我这份表区域/部门VLAN ID网段网关说明研发部10192.168.10.0/24192.168.10.254终端接入VLAN间路由由SVI承担市场部20192.168.20.0/24192.168.20.254终端接入财务部30192.168.30.0/24192.168.30.254终端接入访问范围建议收紧服务器区100192.168.100.0/24192.168.100.254DNS、OA、文件服务器所在区域地址规划有几个容易忽略的细节一是VLAN ID不要用1因为默认VLAN 1承载管理流量容易出安全问题二是服务器区的网段和终端区尽量分开方便在交换机上做访问控制三是DNS服务器建议用固定的静态IP这个后面配置的时候会反复用到。2. 多层交换机的核心原理与配置要点2.1 三层交换和路由器到底差在哪很多人第一次看到“三层交换机”这个概念会有点懵交换机不是二层设备吗怎么还能跑路由这里要说清楚一个关键原理。二层交换机处理的是数据帧靠MAC地址表转发但MAC地址表只能写同一个广播域里学习到的MAC。VLAN划分之后广播域被隔离了PC-A在VLAN 10PC-B在VLAN 20它们的数据帧根本没有机会互相见面。要通信怎么办只能借助IP——也就是把数据包先送到一个能理解IP路由的“出口”再由这个出口做转发决策。路由器就是干这件事的。但传统路由器的问题是接口数量有限而且处理转发大部分走软件速度和时延都不够理想。三层交换机的思路则是把路由能力做进硬件芯片里同时把“每个VLAN对应一个虚拟接口”这个逻辑做成默认功能。一个VLAN配置一个SVI接口VLAN 10的网关就是192.168.10.254数据包进入三层交换机后查路由表、改源目MAC、从目标VLAN的接口转发出去全程硬件处理速度滚瓜烂熟。用一个简单的类比来说路由器像是小区大门外的市政道路你出小区要绕一圈才能去隔壁楼三层交换机则像是小区内部直接修了一条快速干道楼与楼之间串门根本不用出小区。所以在这个项目里用三层交换机做VLAN间路由是最贴合中小型园区网需求的选择。2.2 接口类型、VLAN划分与Trunk链路配置在动任何命令之前先想清楚交换机的接口角色。接入终端的接口是Access口一个口只能属于一个VLAN交换机与交换机之间的连接口是Trunk口它允许承载多个VLAN的流量。很多新手配置完毕之后VLAN间不通回头排查发现是两台交换机之间的接口配成了Access口数据全被挡在一个VLAN里了。三层交换机作为核心设备它的接口有两种角色面向接入交换机的口走Trunk面向服务器等需要独立策略的设备可以直接配成三层路由口interface L3或者继续用VLAN划分。我当时的做法是核心交换机的G0/0/1口接接入层交换机AG0/0/2口接接入层交换机B两个口都放行对应VLAN。同时核心交换机上为每个VLAN创建SVI接口作为各网段网关。需要注意一个小细节Trunk链路默认放行所有VLAN但生产环境建议用allow命令显式放行自己需要的VLAN不要把内部的VLAN放得满天飞减少广播和故障域蔓延。这算是安全习惯也是排障时减少干扰项的有效手段。2.3 DHCP与网关的协同配置思路前面只规划了静态IP给服务器那终端电脑怎么办如果一台台手工设IP几十台设备配到怀疑人生。这个项目里我引入了DHCP服务但注意一个关键点DHCP服务可以跑在交换机上也可以在Windows服务器上做二选一。我这里让三层交换机承担DHCP的分配任务因为交换机和各VLAN是直连关系给每个VLAN配置一个DHCP地址池逻辑上很直接。配置DHCP时有个最容易被忽视的地方如果终端所在VLAN和DHCP服务器不在同一广播域需要配置DHCP中继。三层交换机作为网关其实自己就天然知道该找哪个DHCP如果你用的是外部DHCP服务器就一定得在SVI接口上配置ip helper-address之类的命令把客户端的广播请求转为单播转发给DHCP服务器。很多人做完实验发现PC拿不到地址十有八九就是漏了这一步。我在这套项目里最终选择的是核心交换机直接分配配置相对少也少了一层排障难度。如果将来网络规模变大、要支持跨网段的集中IP管理再考虑迁到独立的DHCP服务器更合适。3. DNS服务选型、搭建与联动配置3.1 自建DNS还是用路由器的DNS转发很多人在做综合项目时对于DNS这块的想法还停留在家用路由器上。家用路由器那个DNS功能本质上是“DNS转发器”它自己不维护域名记录只是把客户端的查询请求转给上游公共DNS再返回结果。但企业内部网络有自己的服务器和内部域名公共DNS根本不知道你内部那台OA服务器的名字对应什么IP。这种场景必须有一台“权威DNS”或者说“内部DNS服务器”专门维护企业内部域名记录。所以在选型之前先想清楚你需要的是“解析公网域名”的能力还是“解析内部域名”的能力通常答案是两者都要同时还要能处理“内部记录优先公网域名走转发”的策略。这就决定了你需要自建一台能同时充当“权威服务器”和“递归解析器/转发器”的DNS服务。操作系统层面我见过两种主流路线Windows Server上装DNS角色图形化界面点起来直观Linux上用BIND或dnsmasq配置文件驱动适合批量管理和脚本化运维。考虑到这个项目的场景是中小型公司内部网络而且后期要和各种网络设备联动我选择的是Linux上的BIND方案灵活性和可控性都更高。当然如果大家习惯Windows操作Windows DNS也完全可以参考同样的逻辑。3.2 DNS区域、解析记录与视图配置规划DNS区域的时候我给内部域名取了一个不会和公网冲突的名字比如example.internal或者corp.local。不建议直接用公司在公网上注册的真实域名未加区分地作为内部域名否则后面如果要做公司官网的公网解析和内部解析容易产生“分叉”和冲突。核心配置分两大部分正向查找区域和反向查找区域。正向区域里我添加了几条必要的A记录dns、oa、fileserver等分别指向对应服务器的IP。反向区域则用于把IP解析回主机名这个在排障时非常有用。比如你在三层交换机上做ACL日志或者服务器日志里看到某台机器一直在尝试连接你就可以通过反向DNS快速看清这个IP是谁。这里还有个容易被忽略的“视图”概念。如果企业内部DNS同时需要处理“内网用户解析内网域名”和“内网用户解析公网域名”两个需求一种简单做法是配置转发器把本地区域之外的查询统一转发给公共DNS比如运营商DNS或者公共DNS地址。但要注意这属于“递归询问外部”只建议在可控的网络里使用不要把这个能力开放给不可信的外部用户否则你的DNS服务器可能被当成开放递归解析器滥用变成流量放大的工具。这一点在生产环境中务必警惕。3.3 从交换机到服务器的联动机制DNS为何要依赖网络可达前面已经把交换机和DNS分别说了一轮但综合项目的“综合”二字恰恰体现在两者的联动上。DNS解析的正常工作依赖一个前提客户端能通过路由找到DNS服务器而且沿途的设备都允许DNS流量通过。举个例子我在这套项目里让研发部VLAN 10的终端去访问OA服务器访问流程是用户输入oa.internal先由客户端向DNS服务器发查询这个查询包要从VLAN 10经过三层交换机路由转发到VLAN 100的DNS服务器DNS服务器返回解析结果然后客户端拿着解析出来的IP再次经过三层交换机去访问OA服务器。你看任何一环不通用户看到的都是网页打不开但实际上原因可能完全不一样。所以配置完网络之后不要直接跳去配置DNS应当先用ping和traceroute确认VLAN间路由通不通、DNS服务器所在网段是否可达。在这个项目里我强烈建议把网络连通性测试作为DNS配置的前置条件这样后续排查时问题域能收窄很多。实践经验是先把“管道”修好再让“门牌号”发挥价值。3.4 DNS服务器的高可用和备份思路企业网络最怕什么DNS挂了全公司所有域名都解析不了感觉像断网了一样。虽然这个综合项目是一个基础版但我在实施的时候还是做了两手准备一是定期备份DNS配置文件二是考虑用两台DNS服务器做主备或者主从。主从的搭建原理不难主DNS服务器维护区域数据通过区域传送把数据同步给从DNS服务器客户端把主用和备用DNS地址都写上主DNS挂了之后自动切到从DNS解析。不过要注意配置安全性区域传送不能向全世界开放应当只允许指定的从服务器IP来拉取数据。哪怕在这个小项目里不做主从至少在交换机上给DNS服务器做定期连通性探测或者给自己留好恢复手册也不至于出问题时手足无措。4. 从零到一的完整实操过程记录4.1 第一阶段先把网络管道打通模拟环境我就不提具体平台了真机或者各类网络模拟器都行。核心是先建立“先二层后三层”的配置节奏不要一上来就写SVI路由免得基础问题淹没在高阶配置里。第一优先配置的是VLAN和Trunk链路。在核心交换机上创建VLAN 10、20、30、100每台接入交换机创建对应的VLAN。接入交换机与核心交换机相连的接口配置为Trunk并放行相关VLAN连接终端的接口划入对应VLAN配置为Access。配置完成后用display vlan或者show vlan确认一下。一个常见的低级错误是终端接入了交换机但交换机的接口没划入任何VLAN默认在VLAN 1里终端自然获取不到正确的网络参数。第二优先是在核心交换机上创建各VLAN的SVI接口并配置IP。SVI接口启用之前可以在配置里先把它shutdown等所有VLAN都创建完毕再统一启用避免一些模拟环境出现接口状态异常的情况。配置好之后核心交换机上就有了四个网关地址。这时候要注意接入交换机本身可能还需要管理IP这个管理IP最好也放在某个VLAN里并保证可以和核心交换机互通否则以后远程管理交换机就成了奢望。第三优先是配置VLAN间路由。三层交换机默认启用了IP路由能力也不用额外写太多只要SVI接口都是UP状态路由表里会自动生成直连路由。此时从核心交换机任意SVI接口去ping其他VLAN的网关IP应该都能通。这一层通了VLAN间路由的骨架就算立住了。4.2 第二阶段让终端自动获取IP在核心交换机上启用DHCP服务为每个终端VLAN配置一个地址池。配置时注意几个关键参数网段、网关、DNS地址、租期。DNS地址这里不要填公网DNS要先填内部DNS服务器的IP如果你想留个备份再填公共DNS。这个顺序很重要因为客户端拿到DNS地址后会优先用第一个做解析。我第一次配置时图省事只填了公共DNS结果内网域名解析全部失败这是个比较容易踩的坑。地址池配置完毕后拿一台终端设备设置成DHCP获取看看能不能拿到对应网段的地址、网关和DNS。如果拿不到地址优先查DHCP地址池是否和接口同网段以及接口是否开启了DHCP服务功能。如果是独立的DHCP服务器而不是交换机分配那就需要回到前面说的ip helper-address配置上去做检查。4.3 第三阶段部署DNS服务并验证解析Linux下安装BIND关键配置分为三个部分主配置文件设置监听的地址默认监听本机的53端口设置允许查询的网段只允许内网网段查询配置递归和转发逻辑本地区域之外的查询转发到公共DNS。区域文件定义正向区域和反向区域分别写入A记录和PTR记录。这里有个极容易被新手的错误区域文件里的域名结尾忘了打点导致域名解析时少了一个根。比如“oa.internal”这条记录如果写成“oa.internal”而不是“oa.internal.”BIND会把当前域自动拼上去最后变成“oa.internal.internal”解析直接失败。权限和属主BIND对配置文件权限比较敏感属主不对或者权限太开放服务起不来或者配置被忽略。我遇到过莫名其妙不生效的情况最后发现是配置文件权限写成了全局可写BIND为了安全拒绝加载部分配置。所以配置完记得chown和chmod然后重启服务。DNS服务起来之后先用nslookup手动测试第一在DNS服务器本机解析内网域名应该能直接返回记录第二在一台终端上把DNS指向DNS服务器解析内网域名和公网域名都应该成功第三用dig命令查看响应来源确认是本机返回而不是其他位置。4.4 第四阶段联动测试和策略收尾联动测试是整个项目最有意思的部分。我在终端上做了这样几组验证从研发部PC解析OA域名返回的IP是否直接可访问从市场部PC访问文件服务器域名是否也正常再从财务部这个我刻意加了更严策略的区域去访问服务器区看看是否能通过。如果ACL策略允许就通畅如果策略阻止了访问也要能确认是策略导致的拒绝而不是DNS解析出问题。最后一件事是配置NTP。我的个人体会是DNS和NTP在综合项目里容易被忽略但网络设备、服务器时间不同步会导致日志分析和故障定位变得极其痛苦。你排查了半天结果发现设备日志时间差了八个小时根本对应不上故障节点。所以最好在核心交换机、服务器上统一配置NTP把时间同步问题解决掉这是实操中非常加分的“专业细节”。5. 常见问题与排查技巧实录5.1 网络不通类问题速查现象可能原因排查思路同一VLAN内可以互访跨VLAN不通SVI接口没有启用或终端网关配错确认每个VLAN的SVI接口状态确认终端网关指向对应网段的SVI地址跨交换机同VLAN不通Trunk链路没有放行该VLAN在接入交换机上检查接口部署模式用show interfaces trunk确认放行列表所有终端都拿不到IPDHCP地址池配置错误或接口未启用DHCP检查地址池网段与接口是否一致检查是否误以为DHCP服务默认开启从服务器区访问终端区不同缺少路由三层交换机负责路由时检查有无静态路由或过滤策略干预5.2 DNS解析失败类问题速查现象可能原因排查思路nslookup内网域名返回超时DNS服务器未监听正确接口或防火墙拦截UDP 53用ss或者netstat查看监听地址在交换机上检查ACL是否放行DNS端口内网域名解析成错误IP区域文件记录错误或“视图”逻辑导致返回了不同结果逐条检查A记录IP用dig dns_server确认实际返回公网域名无法解析转发器配置不对或上游DNS不可达检查转发器地址是否可先ping通然后看BIND日志确认转发是否被拒绝解析延迟很高递归查询链路太长或DNS服务器尝试做迭代查询反复超时把log配置打开看查询到底卡在哪一层检查是否网关联动异常服务能启动但客户端查询都拒绝允许查询的网段白名单未包含客户端网段检查配置文件中allow-query和allow-recursion确保包含了所有终端网段5.3 联动场景下的坑DNS和ACL谁挡了谁这个项目里最典型的一类问题是终端解析域名成功但访问服务器失败。很多人下意识觉得是DNS配置没问题那就完事了。但实际去查可能是三层交换机上设置的访问控制策略把服务器区域的访问给挡了。DNS解析用的是UDP/TCP 53端口访问OA用的可能是HTTP的80端口两者经过的路径不完全一样。排查这种问题的时候要建立一个“分层验证”的思维第一步先确认基础连通性直接ping服务器的IP地址看看通不通第二步确认DNS解析结果是否正确用nslookup解析出IP第三步再测试具体端口是否可达用telnet或者nc去访问目标端口。三步走完问题基本就能定位到是路由、策略还是服务本身的问题而不是拿着一句“访问不了”在那里瞎猜。5.4 一个很隐蔽的问题DNS缓存带来的假故障在项目实施过程中我一度遇到“明明改了DNS记录但客户端还是解析到旧地址”的情况。排查到最后发现有两个缓存层一是客户端本机DNS缓存二是DNS服务器自身的缓存。如果你修改了区域文件DNS服务器缓存的TLL还没过期它依然会返回旧记录。这时候最优做法是修改完区域数据之后手动重启DNS服务或者用命令清除缓存再重新查询。这样可以确保客户端拿到的是最新的记录。后来我把这个经验总结成一条习惯凡是改了DNS记录一定要同时检查两台设备的缓存一个是作为解析端的电脑一个是作为解析源的DNS服务器两个地方都不能忽略。6. 测试验证与网络设备日常维护心得6.1 三层交换机侧的巡检命令与状态确认项目做完不是终点设备在运行过程中是否健康才是日常工作的重点。三层交换机上有几个状态值我建议每周至少看一次。第一个是CPU使用率有些交换机在处理大量路由转发或ACL匹配时会突然飙高需要尽早发现。第二个是接口的丢包和错误包计数比如入方向错包持续增加可能要检查双工模式、线缆质量或者广播风暴。第三个是路由表中的直连路由是否稳定如果有接口反复up/down路由表也会跟着抖动。在综合项目的配置中我习惯把snmp服务也顺手开启用监控工具定期抓取交换机的CPU、内存和接口流量。虽然这属于“运维前置”的活儿但对于一个要长期运行的项目来说早做比晚做强。6.2 DNS服务器的日志监控与定期备份BIND的日志体系比较丰富但默认配置可能不会输出太多内容。我建议单独配置查询日志和错误日志至少把错误日志写到独立文件。这样当用户反馈“解析不了”的时候先看错误日志再决定要不要开调试级别的日志避免一开始就把日志刷爆。配置文件备份这方面我养成一个习惯每次修改配置前先复制一份带时间戳的备份文件。BIND的配置都是文本文件备份成本极低但恢复时作用极大。配合前面说的主从DNS方案即使主服务器配置文件损坏或者被误改也可以快速从备份或者从服务器恢复区域数据。6.3 整网文档化让项目可持续演化这个项目做完之后我额外做了一份“网络信息清单”内容包括VLAN和网段对应表、所有服务器IP和DNS记录对照表、交换机的管理IP和远程登录方式、DHCP地址池范围和保留地址、ACL策略规则清单。看着像“杂事”但在后续任何一次故障排查、扩容、割接中这份文档都是绕不开的地基。很多时候项目里的“综合”二字考验的远不止技术层面的连通性。它考验的是你能否把交换、路由、DNS、DHCP、安全策略这些独立能力拼成一个逻辑自洽的整体。我建议每个做这个项目的人都给自己留点时间做文档沉淀不要觉得“能通就行”。只有把每一步为什么这么做想清楚再从这个项目里跳出来才算真正把这些知识内化。这也就是为什么我一直觉得综合项目最有价值的产出通常不是那几台能用的设备而是你在实施过程中建立起来的“全链路思维”——从敲下第一条命令开始就知道整个网络的每一层、每一个服务之间是怎么相互依赖的。有了这个底子以后不管碰到多复杂的网络环境你都会习惯性地从全局去拆解问题而不是头痛医头、脚痛医脚。
不知道大家有没有这种体会学网络的时候单独学交换、单独学路由甚至单独配一台DNS服务器其实都挺顺的。但一旦要把这些技术揉进同一个项目里让它们像真实企业网络那样协同工作很多人就卡住了。我最近刚好把一个“多层交换机和DNS综合项目”从头到尾完整实施了一遍从拓扑设计、VLAN划分、三层转发再到域名解析服务上线整个过程踩了不少坑也积累了一些书本上不会明说的经验。这篇东西就是记录整个项目的设计和落地过程。不管你是正在准备综合实验的在校学生还是刚入职想搞懂企业网络真实拓扑的初级工程师或者是打算把家里的网络设备整理成“麻雀虽小五脏俱全”的折腾型选手这个项目都能给你一个从零到一的完整参考。它不是一个单纯的命令堆砌而是一套“先想清楚为什么再动手敲命令”的实操逻辑。1. 项目需求与整体设计思路1.1 为什么非要把多层交换和DNS放在一起做先说个很多人容易忽略的点DNS这个服务单独看它就是一个解析域名的软件似乎和交换机八竿子打不着。但在真实的企业网络里DNS却是整个网络的“导航系统”。你没有DNS客户端就没法通过名字访问服务器而你没有一套合理的三层网络架构DNS服务器就算配置得再完美也可能因为广播域隔离、路由不可达、接口策略等奇奇怪怪的原因“隐身”。所以这个综合项目的第一层价值是强迫你站在全局视角看问题交换层解决“数据能不能通”DNS解决“用户能不能用名字找到资源”。前者是管道后者是门牌号。把这两者联动起来才算是把一个“能跑起来”的网络变成“好用”的网络。我这套项目的假定场景是这样的一家中小型公司内部划分了三个业务部门比如研发部、市场部、财务部另外还有一个独立的服务器区域专门用来跑内部OA、文件共享和DNS解析服务。公司内部的员工电脑希望通过固定的域名来访问OA系统而不是每次去背IP地址。整个网络要求做到部门间互访可控、服务器区域单独保护、DNS解析稳定高效。1.2 核心需求拆解与设计决策接到这种需求别急着开模拟器或者拿真机插线先把需求拆成几个明确的技术问题第一广播域隔离问题。三个部门加上服务器区如果全怼在一个网段里广播报文会把整张网络拖慢而且部门之间没有隔离安全上也说不过去。所以必须做VLAN划分。很多入门者说“我划分了VLAN各配各的网段”但忘了部门之间还要通信结果两边直接就ping不通了。这就是引出多层交换的第一个关键点——VLAN间路由。第二路由转发问题。传统思路是“不同VLAN用路由器去路由”用一台路由器接多个物理接口每个接口一个网段。但真实场景里更简洁的做法是用三层交换机来做。三层交换机相当于“交换机和路由器的合体”不同VLAN之间通过虚拟接口SVI直接路由转发速度比普通路由器快得多而且节省物理接口。这里我最终选择的是三层交换方案具体的原理对比后面会展开。第三命名解析问题。整个网络里有好几台服务器、几十台终端IP地址如果要靠脑袋记太痛苦。DNS要承担两个方向的解析一是正向解析把名字翻译成IP二是有条件的话做反向解析方便网络设备做日志记录和排障。另外企业内部域名不需要暴露到公网所以DNS服务器只需要对内服务不需要完全照搬公网DNS那套复杂的递归逻辑。1.3 拓扑规划与地址分配方案拓扑规划是整个项目的骨架骨架歪了后面填肉再努力也白搭。我建议先画一张明确的拓扑图再动手配置防止配置到一半自己都糊涂了。我的整体规划分三层核心设备是一台三层交换机下面挂两台二层接入交换机也可以再增加冗余链路但初版不建议加太多先把基础打通终端和服务器分别接入对应的VLAN。具体地址规划可以参考我这份表区域/部门VLAN ID网段网关说明研发部10192.168.10.0/24192.168.10.254终端接入VLAN间路由由SVI承担市场部20192.168.20.0/24192.168.20.254终端接入财务部30192.168.30.0/24192.168.30.254终端接入访问范围建议收紧服务器区100192.168.100.0/24192.168.100.254DNS、OA、文件服务器所在区域地址规划有几个容易忽略的细节一是VLAN ID不要用1因为默认VLAN 1承载管理流量容易出安全问题二是服务器区的网段和终端区尽量分开方便在交换机上做访问控制三是DNS服务器建议用固定的静态IP这个后面配置的时候会反复用到。2. 多层交换机的核心原理与配置要点2.1 三层交换和路由器到底差在哪很多人第一次看到“三层交换机”这个概念会有点懵交换机不是二层设备吗怎么还能跑路由这里要说清楚一个关键原理。二层交换机处理的是数据帧靠MAC地址表转发但MAC地址表只能写同一个广播域里学习到的MAC。VLAN划分之后广播域被隔离了PC-A在VLAN 10PC-B在VLAN 20它们的数据帧根本没有机会互相见面。要通信怎么办只能借助IP——也就是把数据包先送到一个能理解IP路由的“出口”再由这个出口做转发决策。路由器就是干这件事的。但传统路由器的问题是接口数量有限而且处理转发大部分走软件速度和时延都不够理想。三层交换机的思路则是把路由能力做进硬件芯片里同时把“每个VLAN对应一个虚拟接口”这个逻辑做成默认功能。一个VLAN配置一个SVI接口VLAN 10的网关就是192.168.10.254数据包进入三层交换机后查路由表、改源目MAC、从目标VLAN的接口转发出去全程硬件处理速度滚瓜烂熟。用一个简单的类比来说路由器像是小区大门外的市政道路你出小区要绕一圈才能去隔壁楼三层交换机则像是小区内部直接修了一条快速干道楼与楼之间串门根本不用出小区。所以在这个项目里用三层交换机做VLAN间路由是最贴合中小型园区网需求的选择。2.2 接口类型、VLAN划分与Trunk链路配置在动任何命令之前先想清楚交换机的接口角色。接入终端的接口是Access口一个口只能属于一个VLAN交换机与交换机之间的连接口是Trunk口它允许承载多个VLAN的流量。很多新手配置完毕之后VLAN间不通回头排查发现是两台交换机之间的接口配成了Access口数据全被挡在一个VLAN里了。三层交换机作为核心设备它的接口有两种角色面向接入交换机的口走Trunk面向服务器等需要独立策略的设备可以直接配成三层路由口interface L3或者继续用VLAN划分。我当时的做法是核心交换机的G0/0/1口接接入层交换机AG0/0/2口接接入层交换机B两个口都放行对应VLAN。同时核心交换机上为每个VLAN创建SVI接口作为各网段网关。需要注意一个小细节Trunk链路默认放行所有VLAN但生产环境建议用allow命令显式放行自己需要的VLAN不要把内部的VLAN放得满天飞减少广播和故障域蔓延。这算是安全习惯也是排障时减少干扰项的有效手段。2.3 DHCP与网关的协同配置思路前面只规划了静态IP给服务器那终端电脑怎么办如果一台台手工设IP几十台设备配到怀疑人生。这个项目里我引入了DHCP服务但注意一个关键点DHCP服务可以跑在交换机上也可以在Windows服务器上做二选一。我这里让三层交换机承担DHCP的分配任务因为交换机和各VLAN是直连关系给每个VLAN配置一个DHCP地址池逻辑上很直接。配置DHCP时有个最容易被忽视的地方如果终端所在VLAN和DHCP服务器不在同一广播域需要配置DHCP中继。三层交换机作为网关其实自己就天然知道该找哪个DHCP如果你用的是外部DHCP服务器就一定得在SVI接口上配置ip helper-address之类的命令把客户端的广播请求转为单播转发给DHCP服务器。很多人做完实验发现PC拿不到地址十有八九就是漏了这一步。我在这套项目里最终选择的是核心交换机直接分配配置相对少也少了一层排障难度。如果将来网络规模变大、要支持跨网段的集中IP管理再考虑迁到独立的DHCP服务器更合适。3. DNS服务选型、搭建与联动配置3.1 自建DNS还是用路由器的DNS转发很多人在做综合项目时对于DNS这块的想法还停留在家用路由器上。家用路由器那个DNS功能本质上是“DNS转发器”它自己不维护域名记录只是把客户端的查询请求转给上游公共DNS再返回结果。但企业内部网络有自己的服务器和内部域名公共DNS根本不知道你内部那台OA服务器的名字对应什么IP。这种场景必须有一台“权威DNS”或者说“内部DNS服务器”专门维护企业内部域名记录。所以在选型之前先想清楚你需要的是“解析公网域名”的能力还是“解析内部域名”的能力通常答案是两者都要同时还要能处理“内部记录优先公网域名走转发”的策略。这就决定了你需要自建一台能同时充当“权威服务器”和“递归解析器/转发器”的DNS服务。操作系统层面我见过两种主流路线Windows Server上装DNS角色图形化界面点起来直观Linux上用BIND或dnsmasq配置文件驱动适合批量管理和脚本化运维。考虑到这个项目的场景是中小型公司内部网络而且后期要和各种网络设备联动我选择的是Linux上的BIND方案灵活性和可控性都更高。当然如果大家习惯Windows操作Windows DNS也完全可以参考同样的逻辑。3.2 DNS区域、解析记录与视图配置规划DNS区域的时候我给内部域名取了一个不会和公网冲突的名字比如example.internal或者corp.local。不建议直接用公司在公网上注册的真实域名未加区分地作为内部域名否则后面如果要做公司官网的公网解析和内部解析容易产生“分叉”和冲突。核心配置分两大部分正向查找区域和反向查找区域。正向区域里我添加了几条必要的A记录dns、oa、fileserver等分别指向对应服务器的IP。反向区域则用于把IP解析回主机名这个在排障时非常有用。比如你在三层交换机上做ACL日志或者服务器日志里看到某台机器一直在尝试连接你就可以通过反向DNS快速看清这个IP是谁。这里还有个容易被忽略的“视图”概念。如果企业内部DNS同时需要处理“内网用户解析内网域名”和“内网用户解析公网域名”两个需求一种简单做法是配置转发器把本地区域之外的查询统一转发给公共DNS比如运营商DNS或者公共DNS地址。但要注意这属于“递归询问外部”只建议在可控的网络里使用不要把这个能力开放给不可信的外部用户否则你的DNS服务器可能被当成开放递归解析器滥用变成流量放大的工具。这一点在生产环境中务必警惕。3.3 从交换机到服务器的联动机制DNS为何要依赖网络可达前面已经把交换机和DNS分别说了一轮但综合项目的“综合”二字恰恰体现在两者的联动上。DNS解析的正常工作依赖一个前提客户端能通过路由找到DNS服务器而且沿途的设备都允许DNS流量通过。举个例子我在这套项目里让研发部VLAN 10的终端去访问OA服务器访问流程是用户输入oa.internal先由客户端向DNS服务器发查询这个查询包要从VLAN 10经过三层交换机路由转发到VLAN 100的DNS服务器DNS服务器返回解析结果然后客户端拿着解析出来的IP再次经过三层交换机去访问OA服务器。你看任何一环不通用户看到的都是网页打不开但实际上原因可能完全不一样。所以配置完网络之后不要直接跳去配置DNS应当先用ping和traceroute确认VLAN间路由通不通、DNS服务器所在网段是否可达。在这个项目里我强烈建议把网络连通性测试作为DNS配置的前置条件这样后续排查时问题域能收窄很多。实践经验是先把“管道”修好再让“门牌号”发挥价值。3.4 DNS服务器的高可用和备份思路企业网络最怕什么DNS挂了全公司所有域名都解析不了感觉像断网了一样。虽然这个综合项目是一个基础版但我在实施的时候还是做了两手准备一是定期备份DNS配置文件二是考虑用两台DNS服务器做主备或者主从。主从的搭建原理不难主DNS服务器维护区域数据通过区域传送把数据同步给从DNS服务器客户端把主用和备用DNS地址都写上主DNS挂了之后自动切到从DNS解析。不过要注意配置安全性区域传送不能向全世界开放应当只允许指定的从服务器IP来拉取数据。哪怕在这个小项目里不做主从至少在交换机上给DNS服务器做定期连通性探测或者给自己留好恢复手册也不至于出问题时手足无措。4. 从零到一的完整实操过程记录4.1 第一阶段先把网络管道打通模拟环境我就不提具体平台了真机或者各类网络模拟器都行。核心是先建立“先二层后三层”的配置节奏不要一上来就写SVI路由免得基础问题淹没在高阶配置里。第一优先配置的是VLAN和Trunk链路。在核心交换机上创建VLAN 10、20、30、100每台接入交换机创建对应的VLAN。接入交换机与核心交换机相连的接口配置为Trunk并放行相关VLAN连接终端的接口划入对应VLAN配置为Access。配置完成后用display vlan或者show vlan确认一下。一个常见的低级错误是终端接入了交换机但交换机的接口没划入任何VLAN默认在VLAN 1里终端自然获取不到正确的网络参数。第二优先是在核心交换机上创建各VLAN的SVI接口并配置IP。SVI接口启用之前可以在配置里先把它shutdown等所有VLAN都创建完毕再统一启用避免一些模拟环境出现接口状态异常的情况。配置好之后核心交换机上就有了四个网关地址。这时候要注意接入交换机本身可能还需要管理IP这个管理IP最好也放在某个VLAN里并保证可以和核心交换机互通否则以后远程管理交换机就成了奢望。第三优先是配置VLAN间路由。三层交换机默认启用了IP路由能力也不用额外写太多只要SVI接口都是UP状态路由表里会自动生成直连路由。此时从核心交换机任意SVI接口去ping其他VLAN的网关IP应该都能通。这一层通了VLAN间路由的骨架就算立住了。4.2 第二阶段让终端自动获取IP在核心交换机上启用DHCP服务为每个终端VLAN配置一个地址池。配置时注意几个关键参数网段、网关、DNS地址、租期。DNS地址这里不要填公网DNS要先填内部DNS服务器的IP如果你想留个备份再填公共DNS。这个顺序很重要因为客户端拿到DNS地址后会优先用第一个做解析。我第一次配置时图省事只填了公共DNS结果内网域名解析全部失败这是个比较容易踩的坑。地址池配置完毕后拿一台终端设备设置成DHCP获取看看能不能拿到对应网段的地址、网关和DNS。如果拿不到地址优先查DHCP地址池是否和接口同网段以及接口是否开启了DHCP服务功能。如果是独立的DHCP服务器而不是交换机分配那就需要回到前面说的ip helper-address配置上去做检查。4.3 第三阶段部署DNS服务并验证解析Linux下安装BIND关键配置分为三个部分主配置文件设置监听的地址默认监听本机的53端口设置允许查询的网段只允许内网网段查询配置递归和转发逻辑本地区域之外的查询转发到公共DNS。区域文件定义正向区域和反向区域分别写入A记录和PTR记录。这里有个极容易被新手的错误区域文件里的域名结尾忘了打点导致域名解析时少了一个根。比如“oa.internal”这条记录如果写成“oa.internal”而不是“oa.internal.”BIND会把当前域自动拼上去最后变成“oa.internal.internal”解析直接失败。权限和属主BIND对配置文件权限比较敏感属主不对或者权限太开放服务起不来或者配置被忽略。我遇到过莫名其妙不生效的情况最后发现是配置文件权限写成了全局可写BIND为了安全拒绝加载部分配置。所以配置完记得chown和chmod然后重启服务。DNS服务起来之后先用nslookup手动测试第一在DNS服务器本机解析内网域名应该能直接返回记录第二在一台终端上把DNS指向DNS服务器解析内网域名和公网域名都应该成功第三用dig命令查看响应来源确认是本机返回而不是其他位置。4.4 第四阶段联动测试和策略收尾联动测试是整个项目最有意思的部分。我在终端上做了这样几组验证从研发部PC解析OA域名返回的IP是否直接可访问从市场部PC访问文件服务器域名是否也正常再从财务部这个我刻意加了更严策略的区域去访问服务器区看看是否能通过。如果ACL策略允许就通畅如果策略阻止了访问也要能确认是策略导致的拒绝而不是DNS解析出问题。最后一件事是配置NTP。我的个人体会是DNS和NTP在综合项目里容易被忽略但网络设备、服务器时间不同步会导致日志分析和故障定位变得极其痛苦。你排查了半天结果发现设备日志时间差了八个小时根本对应不上故障节点。所以最好在核心交换机、服务器上统一配置NTP把时间同步问题解决掉这是实操中非常加分的“专业细节”。5. 常见问题与排查技巧实录5.1 网络不通类问题速查现象可能原因排查思路同一VLAN内可以互访跨VLAN不通SVI接口没有启用或终端网关配错确认每个VLAN的SVI接口状态确认终端网关指向对应网段的SVI地址跨交换机同VLAN不通Trunk链路没有放行该VLAN在接入交换机上检查接口部署模式用show interfaces trunk确认放行列表所有终端都拿不到IPDHCP地址池配置错误或接口未启用DHCP检查地址池网段与接口是否一致检查是否误以为DHCP服务默认开启从服务器区访问终端区不同缺少路由三层交换机负责路由时检查有无静态路由或过滤策略干预5.2 DNS解析失败类问题速查现象可能原因排查思路nslookup内网域名返回超时DNS服务器未监听正确接口或防火墙拦截UDP 53用ss或者netstat查看监听地址在交换机上检查ACL是否放行DNS端口内网域名解析成错误IP区域文件记录错误或“视图”逻辑导致返回了不同结果逐条检查A记录IP用dig dns_server确认实际返回公网域名无法解析转发器配置不对或上游DNS不可达检查转发器地址是否可先ping通然后看BIND日志确认转发是否被拒绝解析延迟很高递归查询链路太长或DNS服务器尝试做迭代查询反复超时把log配置打开看查询到底卡在哪一层检查是否网关联动异常服务能启动但客户端查询都拒绝允许查询的网段白名单未包含客户端网段检查配置文件中allow-query和allow-recursion确保包含了所有终端网段5.3 联动场景下的坑DNS和ACL谁挡了谁这个项目里最典型的一类问题是终端解析域名成功但访问服务器失败。很多人下意识觉得是DNS配置没问题那就完事了。但实际去查可能是三层交换机上设置的访问控制策略把服务器区域的访问给挡了。DNS解析用的是UDP/TCP 53端口访问OA用的可能是HTTP的80端口两者经过的路径不完全一样。排查这种问题的时候要建立一个“分层验证”的思维第一步先确认基础连通性直接ping服务器的IP地址看看通不通第二步确认DNS解析结果是否正确用nslookup解析出IP第三步再测试具体端口是否可达用telnet或者nc去访问目标端口。三步走完问题基本就能定位到是路由、策略还是服务本身的问题而不是拿着一句“访问不了”在那里瞎猜。5.4 一个很隐蔽的问题DNS缓存带来的假故障在项目实施过程中我一度遇到“明明改了DNS记录但客户端还是解析到旧地址”的情况。排查到最后发现有两个缓存层一是客户端本机DNS缓存二是DNS服务器自身的缓存。如果你修改了区域文件DNS服务器缓存的TLL还没过期它依然会返回旧记录。这时候最优做法是修改完区域数据之后手动重启DNS服务或者用命令清除缓存再重新查询。这样可以确保客户端拿到的是最新的记录。后来我把这个经验总结成一条习惯凡是改了DNS记录一定要同时检查两台设备的缓存一个是作为解析端的电脑一个是作为解析源的DNS服务器两个地方都不能忽略。6. 测试验证与网络设备日常维护心得6.1 三层交换机侧的巡检命令与状态确认项目做完不是终点设备在运行过程中是否健康才是日常工作的重点。三层交换机上有几个状态值我建议每周至少看一次。第一个是CPU使用率有些交换机在处理大量路由转发或ACL匹配时会突然飙高需要尽早发现。第二个是接口的丢包和错误包计数比如入方向错包持续增加可能要检查双工模式、线缆质量或者广播风暴。第三个是路由表中的直连路由是否稳定如果有接口反复up/down路由表也会跟着抖动。在综合项目的配置中我习惯把snmp服务也顺手开启用监控工具定期抓取交换机的CPU、内存和接口流量。虽然这属于“运维前置”的活儿但对于一个要长期运行的项目来说早做比晚做强。6.2 DNS服务器的日志监控与定期备份BIND的日志体系比较丰富但默认配置可能不会输出太多内容。我建议单独配置查询日志和错误日志至少把错误日志写到独立文件。这样当用户反馈“解析不了”的时候先看错误日志再决定要不要开调试级别的日志避免一开始就把日志刷爆。配置文件备份这方面我养成一个习惯每次修改配置前先复制一份带时间戳的备份文件。BIND的配置都是文本文件备份成本极低但恢复时作用极大。配合前面说的主从DNS方案即使主服务器配置文件损坏或者被误改也可以快速从备份或者从服务器恢复区域数据。6.3 整网文档化让项目可持续演化这个项目做完之后我额外做了一份“网络信息清单”内容包括VLAN和网段对应表、所有服务器IP和DNS记录对照表、交换机的管理IP和远程登录方式、DHCP地址池范围和保留地址、ACL策略规则清单。看着像“杂事”但在后续任何一次故障排查、扩容、割接中这份文档都是绕不开的地基。很多时候项目里的“综合”二字考验的远不止技术层面的连通性。它考验的是你能否把交换、路由、DNS、DHCP、安全策略这些独立能力拼成一个逻辑自洽的整体。我建议每个做这个项目的人都给自己留点时间做文档沉淀不要觉得“能通就行”。只有把每一步为什么这么做想清楚再从这个项目里跳出来才算真正把这些知识内化。这也就是为什么我一直觉得综合项目最有价值的产出通常不是那几台能用的设备而是你在实施过程中建立起来的“全链路思维”——从敲下第一条命令开始就知道整个网络的每一层、每一个服务之间是怎么相互依赖的。有了这个底子以后不管碰到多复杂的网络环境你都会习惯性地从全局去拆解问题而不是头痛医头、脚痛医脚。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
