写这个系列第二篇之前我翻了翻评论区大家的留言发现不少朋友已经会拖Server出来、会连线了但接下来就卡住了这个像Linux终端一样的东西到底能干嘛为什么我把它连到交换机上ping不通路由器为什么我明明开了DHCP服务客户端却拿不到地址这些问题我在刚开始玩华三HCL仿真平台的时候全都遇到过甚至有一段时间觉得Server就是个摆设。后来真正把它用到DHCP、NAT、ACL、VXLAN这些实验里才发现它其实是整个仿真环境里最灵活的一台“万能测试机”。这一篇我把Server放在三个具体实验场景里讲清楚怎么当DHCP服务器发地址怎么伪装成公网那台Web服务器去验证NAT和ACL以及怎么当“抓包器”和连通性标尺来协助排查VXLAN这类复杂隧道。适合已经把HCL装好、设备能启动、想让实验更贴近真实网络环境的朋友参考。1. 先立个框架Server在HCL里到底是什么角色1.1 Server的真实身份一台能干活、能干杂活的Linux主机很多人习惯把HCL仿真平台里的Server和其他网络设备分开看觉得它只是一个可有可无的“挂在边上的终端”。但我的理解完全相反它本质上是一台跑着精简Linux系统的主机只是没有显示器、没有键鼠你通过HCL的窗口直接操作它的命令行。既然是Linux主机那它能干的事情就很明确了。它可以配多个网卡接口每个接口分配独立IP可以查看和修改路由表可以ping、可以telnet、可以curl可以启动HTTP、FTP、DHCP、DNS这些常见服务还可以通过抓包工具去观察进出接口的报文。真机上能完成的很多基础网络验证在它身上都能完成。这个定位非常重要。因为华三HCL仿真平台里的路由器、交换机说到底只能让你看端口状态、看协议表项、看流量统计但“用户实际访问Web页面时看到的是什么”、“DHCP客户端到底有没有拿到地址”这一类最接地气的问题必须有一台“端到端的主机”来验证。Server就是干这个的。1.2 我常用的一份Server能力清单在动手做实验之前先把我平时会用到的一些Server能力整理出来可以把它当作一份“检查表”省得每次实验前还要翻找功能应用角色常见功能典型实验场景DHCP服务器给其他Server分配IP三层交换机/路由器地址池联动测试DHCP客户端自动获取IP验证中继/地址池DHCP Relay实验、多网段自动分配HTTP服务器提供Web访问记录访问日志NAT会话验证、ACL封禁80端口效果验证FTP服务器上传下载文件查看会话统计防火墙策略、ASPF应用层过滤DNS服务器提供域名解析设备侧DNS代理配置、内网域名解析抓包工具观察进出接口的报文VXLAN报文封装、ACL放通与丢弃判断普通客户端ping、telnet、curl目标地址路由可达性测试、跨VLAN通信验证服务器和客户端的身份并不是写死的。同一台Server今天可以是DHCP服务器明天就可以变成一台“内网PC”。这正是它灵活的地方。我在做综合实验时经常会给一台Server上开两个网卡一个网卡接内网当客户端另一个网卡接服务器区当服务端一台机器同时扮演两个角色拓扑能简洁不少。2. 重头戏一让Server当DHCP服务器把手动地址改成自动获取2.1 实验拓扑与地址规划思路第一个我特别推荐实际动手做的实验是用Server当一台DHCP服务器给另一台Server当作PC自动下发IP地址。这个实验看起来基础但它是理解DHCP整个交互过程的最好方式同时也能让不熟悉Server网卡配置的人把虚拟网卡、VLAN、网关这些概念一次理清。拓扑是这样交换机S1作为二层设备下接两台ServerServer1的网卡接S1的GigabitEthernet1/0/1Server2的网卡接S1的GigabitEthernet1/0/2S1的上联口接R1的G0/0口R1的G0/0配置网关地址192.168.20.1。接口编号以你拖出来的实际设备型号为准不同型号可能是GigabitEthernet开头也可能是Ten-GigabitEthernet开头不影响实验逻辑。地址规划如下表对象网卡/接口IP地址说明R1 G0/0连接S1上联口192.168.20.1/24终端网关S1二层交换机不需要IP只需将所有端口放通到同一VLANServer1eth0192.168.20.2/24静态DHCP服务器本机地址Server2eth0自动获取用来验证DHCP分配效果这个规划的精髓在于Server1的地址是静态固定的因为整个网段所有的终端都要靠它来“服务器”如果它自己也靠DHCP获取一旦地址变了其他终端就找不到它了。实际生产环境里DHCP服务器一定使用静态地址这是不用想的约定。2.2 设备侧与Server侧的配置步骤第一步先在HCL里连线启动设备。等待R1、S1两台设备和两台Server全部启动后先在S1上做二层配置把所有接口放到同一个VLANsystem-view vlan 20 quit interface GigabitEthernet1/0/1 port link-type access port access vlan 20 quit interface GigabitEthernet1/0/2 port link-type access port access vlan 20 quit interface GigabitEthernet1/0/3 port link-type access port access vlan 20 quit然后R1上配置网关地址system-view interface GigabitEthernet0/0 ip address 192.168.20.1 255.255.255.0接下来配置Server1。在HCL中双击Server1打开操作窗口它看起来就是一个Linux终端。先给eth0配置静态IP并启动接口ip addr add 192.168.20.2/24 dev eth0 ip link set eth0 up ip route add default via 192.168.20.1配好之后先用ping命令确认Server1能通到网关ping 192.168.20.1通了再继续。这里千万不要跳步——很多后面“客户端怎么都拿不到地址”的问题本质是Server的网卡没起来或者IP没配对先拿网关验证一遍能省掉一大半排错时间。然后在Server1上开启DHCP服务。HCL新版界面里Server窗口右侧会直接给出DHCP服务的配置入口你只需要填上分配网段192.168.20.0/24、掩码、网关192.168.20.1、租期等参数服务启动即可。老版本没有图形配置入口的可以用命令行方式编辑dhcpd配置。无论哪种方式核心参数就三样地址池网段、分配的网关、租期或DNS。Server2作为客户端就更简单了。同样打开终端把eth0改成自动获取dhclient eth0等一两秒再执行ip addr show eth0如果看到eth0上出现了一个192.168.20.x的地址而且网关、DNS都一并分配下来了说明整套流程已经打通。2.3 这个实验里最容易翻车的三个点第一Server的网卡默认可能是down状态。你配了IP但没执行ip link set eth0 up那接口依然不通。这个操作在HCL里比真机更容易被忽略因为窗口里没有任何指示灯告诉你eth0是up还是down。我建议每个人都养成习惯配置完IP后顺手看一眼ip addr确认网卡状态不是DOWN。第二地址池和网关不在同一个网段。DHCP虽然能把地址下发出去但Client拿到地址后如果网关不对它依然出不了网。地址池内网段、默认网关、Server1自己所在的网段这三者必须一致。第三交换机上只放通了VLAN 20是够的但如果你把Server接到的是某些“默认处于shutdown状态”或“没有配置access VLAN”的端口上还是会不通。HCL里设备启动后接口默认是开启的但有一种情况很隐蔽你之前在某台设备上save过配置后来又改了VLAN结果忘了保存下次打开实验是旧配置。所以每次做实验前先看一下端口状态。3. 重头戏二把Server打扮成“公网Web服务器”验证NAT和ACL的真实效果3.1 为什么说这个实验能一石三鸟在HCL里配置NAT很多人会在路由器上敲完nat outbound后自我感觉良好地认为“肯定通了”。但真通了吗内网PC访问公网服务器经过NAT转换后的源地址是什么ACL策略到底有没有挡住某个流量这些光看命令回显是看不到的。这个实验的设计思路就是把一台Server伪装成公网Web服务器暴露在外网侧把另一台Server伪装成内网PC。通过Server上记录的访问日志和抓包结果直接看到NAT的转换效果和ACL的过滤效果。练一次等于同时把NAT、ACL、路由排错三件事都过了一遍。3.2 拓扑和完整配置过程拓扑Server_pc内网PC接交换机交换机上联R1的G0/0R1的G0/1直连Server_web公网侧。先把交换机的两个下联口划到同一个VLAN例如VLAN 30命令和上一章完全一样只是VLAN号不同这里不重复贴。IP规划对象接口IP地址说明Server_pceth0192.168.30.2/24网关192.168.30.1模拟内网用户R1 G0/0连接内网192.168.30.1/24内网网关R1 G0/1连接公网侧202.100.10.254/24NAT出接口Server_webeth0202.100.10.100/24网关202.100.10.254模拟公网Web服务器先把Server_web上的HTTP服务开启并在服务目录放一个测试页面。然后给Server_pc配上IP和网关。在没有NAT的情况下内网PC访问公网服务器会因为私网地址到公网段的报文没有转换而被丢弃——直连路由会告诉你报文能出接口但公网服务器收到一个源地址为192.168.30.2的报文回包根本发不回去。这也是很多初学者搞混NAT作用的点。接着在R1上配置一条基础的出接口NATsystem-view acl basic 2000 rule 5 permit source 192.168.30.0 0.0.0.255 quit interface GigabitEthernet0/1 nat outbound 2000这条配置的意思是从192.168.30.0/24这个网段发起的、从G0/1出去的流量源地址会被自动转换成G0/1接口的地址202.100.10.254。然后在Server_pc上用curl去访问Server_web的测试页面curl http://202.100.10.100/此时再去Server_web的HTTP服务日志里看你会发现访问来源是202.100.10.254而不是192.168.30.2。这就直接证明了NAT转换生效了。接下来追加ACL测试。在R1上继续配置高级ACL拒绝内网访问公网Web服务器的80端口acl advanced 3000 rule 0 deny tcp source 192.168.30.0 0.0.0.255 destination 202.100.10.100 0 destination-port eq 80 rule 5 permit ip quit interface GigabitEthernet0/1 packet-filter 3000 outbound应用策略之后再回Server_pc上执行curl这次会卡住直到超时。把ACL移除后再次curl又立即能访问。这一通操作下来ACL的过滤规则是否生效你会有非常直观的体感。3.3 从Server日志和抓包里看懂数据流转做这个实验的时候我强烈建议你在Server_web上把服务日志打开。日志里记录的是“到达这台服务器的源地址”。如果只看到202.100.10.254说明NAT把源地址换了。这就是NAPT出接口转换最经典的证据。如果你还想进一步看报文可以在Server_web上执行抓包命令观察来自202.100.10.254的TCP三次握手、HTTP GET请求、ACK响应。能够看到完整的三次握手说明路由、NAT、ACL这一整条链路上都没有问题如果只看到SYN发出但没有SYN-ACK回来问题往往出在NAT回包路径或ACL入方向漏配了。这个排查思路比单纯在路由器上看计数器要直接得多。4. Server的隐藏技能当“抓包器”和“连通性标尺”用4.1 HCL里抓包的正确打开方式HCL本身在设备视图里也带了报文抓取功能但它的粒度比较粗很多时候你只能在端口上看到收到了多少包、丢了多少包看不到具体报文内容。Server这个角色正好可以补上这块短板。在Server上抓包思路跟在一台真实Linux服务器上一样用tcpdump这类命令行工具。比如我想确认Server_web在收到curl请求后回包有没有正常出去可以在它的eth0上执行抓包过滤条件写端口80即可。抓包结果能直接看到TCP标志位、序列号、源目地址这些细节画面非常直观。需要注意的是HCL里Server的性能受宿主机影响比较大因此抓包时过滤条件一定要写准不然同时跑多个服务时窗口会刷得飞快。我一般会先确认目的端口再针对性地抓避免全量收包导致的窗口卡顿。4.2 一次VXLAN实验中Server是怎么帮我定位问题的华三vxlan命令一直是社区里的热门话题确实VXLAN这种隧道技术是HCL平台上比较能体现“模拟器价值”的实验之一。它涉及的设备配置多、中间环节多一旦不通排查链路比普通路由实验复杂得多。我自己的做法是在VXLAN两端各放一台Server用它们当“标尺”。场景大致是两个站点各有一台VXLAN交换机站点A的Server_A地址是10.1.1.10/24站点B的Server_B地址是10.1.1.20/24底层网络是三层可达的。两台交换机之间建立VXLAN隧道实现跨站点的二层互通。配置过程会涉及bridge-domain、VXLAN隧道接口、VTEP地址等一大堆参数具体命令每台设备型号有差异这里不过多展开。配置完成后我在Server_A上去ping Server_B。通了说明VXLAN的二层转发没问题不通我在Server_A上抓包看ICMP报文有没有正常发出去再在VTEP连接底层网络的接口上抓包看VXLAN封装后的UDP报文里VNI字段是不是正确、外层源目IP是不是双方VTEP地址。这些信息在设备上看不到那么细但在关键节点抓包一目了然。这个“标尺”思路后来被我扩展到了很多实验里做VRRP主备切换我在Server上持续ping网关做BGP路由选路我在Server上curl两个方向的服务做IRF堆叠我用Server验证堆叠后跨成员端口流量是否正常。本质上都是把Server当成一台“最贴近真实应用的探针”比任何一条命令回显都让人放心。5. HCL Server相关的高频故障排查实录启动失败、连接闪断、不通5.1 设备启动失败先别急着重装HCL和Server相关的最常见问题其实是设备启动失败。这些年在不同版本的HCL上都遇到过包括老的2.x、新的3.0以及云实验平台这类Web版本问题表现几乎一样点启动设备过一会提示启动失败或者设备窗口一直黑屏。根据我自己的排查经验第一优先看VirtualBox环境。HCL依赖VirtualBox作为虚拟化底座Win11系统经常因为VirtualBox版本过旧或者和系统的内核隔离功能不兼容而出现启动即退。解决思路是装一个和HCL版本匹配的VirtualBox版本或把系统内核隔离关掉再以管理员身份运行HCL。第二检查资源占用。如果宿主机内存8G不到同时开两台路由器、两台交换机和三台Server很容易有一台设备卡死。第三端口占用。有些安全软件会占用虚拟网卡用的端口导致设备通信异常可以暂时退掉安全软件再测试。这一块很费时间但它其实有一个共性问题往往不在某一次实验配置而在宿主机环境。所以我习惯在做大型实验前先把所有用不到的程序关掉给HCL留出尽量多的内存和CPU资源。5.2 Server到设备不通按照这个顺序排查第二个高频问题是Server明明连到设备上了但怎么都ping不通。这时候除非你运气不好遇到HCL的bug否则问题基本都出在下面这五个环节里。我按排查顺序列一下端口状态。HCL连线上如果显示红色/灰色说明链路没起来问题可能在连线方式或者对应设备的接口处于shutdown状态。Server网卡。ip addr看一眼确认IP和掩码正确、网卡不是DOWN、网关配了对。VLAN放通。中间交换机上Server所接端口和上联端口是否在同一VLAN里链路是否放行了目标VLAN。三层路由。跨网段通信时Server的default gateway是否正确设备上是否有回程路由。策略拦截。最后才是ACL、防火墙域间策略等安全配置拦住了流量。我自己踩过最大的一个坑是第四步。有一次做跨VLAN实验Server ping不通对端我在交换机上反复查VLAN、查trunk折腾了半天最后发现是Server的默认网关没有配置。Server终端里不会像Windows那样提示“默认网关缺失”只有ping不通时才暴露出来。提示这个排查顺序里最容易被跳过的是第4步。我见过太多人在交换机上反复查VLAN配置最后发现是Server自己没写默认路由。所以如果你排查到第三步还是没结果一定要回头再看一下Server的路由表顺手执行ip route show确认default路由在不在。6. 把Server用得越来越顺手的三个习惯6.1 IP规划要有“一眼看得懂”的体系Server这类虚拟终端最容易被忽略的问题就是命名和IP规划混乱。我用HCL做综合实验时会给自己定一个规则Server名字说明角色IP段的最后一个字段说明设备编号。比如Server_DHCP是192.168.20.2Server_Web服务器是202.100.10.100Server_PC是192.168.30.2。这样即使隔了一个月再打开工程也一眼能看懂这台Server当初是干什么用的排错时省下大量回忆时间。6.2 实验进度随做随存重要节点另存快照HCL支持保存整个工程而且可以在关键节点做快照。我的习惯是每完成一个实验步骤并且验证通过就保存一次工程如果这套配置后面还要复现我会另存为一个带编号的版本。这样做的好处是后面一旦配置改崩了可以直接回到上一个稳定点不用从零开始。对Server来说尤其重要——因为Server上的服务配置一旦丢了重新配一遍同样麻烦。6.3 新手建议从“Server当客户端”开始练手如果你是第一次玩Server我不建议一上来就配置DHCP服务或者HTTP服务而是先从最简单的“Server当客户端”练起。比如启动一台设备、一台Server给设备配好接口IP 192.168.99.1/24给Server的eth0配好同网段IP 192.168.99.2/24再配上默认网关192.168.99.1然后在Server上ping网关。通了之后试着把默认网关删掉再ping一次观察不通的现象。这一步走通了你对Server的网卡配置、接口状态查看、HCL连线逻辑都会有直观理解。我自己的体会是Server这层窗户纸捅破之后后面再做复杂实验反而越来越依赖它。之前总觉得模拟器里少了点真实感现在只要在这些关键位置挂一台Server整个实验的可信度立刻就上来了。典型的例子就是VXLAN实验没有Server当标尺光靠设备命令回显你永远只能“觉得通”不能确定真的通。建议你也亲手跑一遍这个系列里的三个实验跑完就会明白模拟器里能说话的“最终用户”比任何一条静态配置都有说服力。