HCL仿真平台Server实战：从DHCP到VXLAN的万能测试机

写这个系列第二篇之前，我翻了翻评论区大家的留言，发现不少朋友已经会拖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能力整理出来，可以把它当作一份“检查表”，省得每次实验前还要翻找功能：

服务器和客户端的身份并不是写死的。同一台Server，今天可以是DHCP服务器，明天就可以变成一台“内网PC”。这正是它灵活的地方。我在做综合实验时，经常会给一台Server上开两个网卡，一个网卡接内网当客户端，另一个网卡接服务器区当服务端，一台机器同时扮演两个角色，拓扑能简洁不少。

2. 重头戏一：让Server当DHCP服务器，把手动地址改成自动获取

2.1 实验拓扑与地址规划思路

第一个我特别推荐实际动手做的实验，是用Server当一台DHCP服务器，给另一台Server（当作PC）自动下发IP地址。这个实验看起来基础，但它是理解DHCP整个交互过程的最好方式，同时也能让不熟悉Server网卡配置的人把虚拟网卡、VLAN、网关这些概念一次理清。

拓扑是这样：交换机S1作为二层设备，下接两台Server；Server1的网卡接S1的GigabitEthernet1/0/1，Server2的网卡接S1的GigabitEthernet1/0/2；S1的上联口接R1的G0/0口，R1的G0/0配置网关地址192.168.20.1。接口编号以你拖出来的实际设备型号为准，不同型号可能是GigabitEthernet开头，也可能是Ten-GigabitEthernet开头，不影响实验逻辑。

地址规划如下表：

这个规划的精髓在于：Server1的地址是静态固定的，因为整个网段所有的终端都要靠它来“服务器”，如果它自己也靠DHCP获取，一旦地址变了，其他终端就找不到它了。实际生产环境里，DHCP服务器一定使用静态地址，这是不用想的约定。

2.2 设备侧与Server侧的配置步骤

第一步先在HCL里连线，启动设备。等待R1、S1两台设备和两台Server全部启动后，先在S1上做二层配置，把所有接口放到同一个VLAN：

system-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/0；R1的G0/1直连Server_web（公网侧）。先把交换机的两个下联口划到同一个VLAN，例如VLAN 30，命令和上一章完全一样，只是VLAN号不同，这里不重复贴。

IP规划：

先把Server_web上的HTTP服务开启，并在服务目录放一个测试页面。然后给Server_pc配上IP和网关。在没有NAT的情况下，内网PC访问公网服务器，会因为私网地址到公网段的报文没有转换而被丢弃——直连路由会告诉你报文能出接口，但公网服务器收到一个源地址为192.168.30.2的报文，回包根本发不回去。这也是很多初学者搞混NAT作用的点。

接着在R1上配置一条基础的出接口NAT：

system-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，否则问题基本都出在下面这五个环节里。我按排查顺序列一下：

1. 端口状态。HCL连线上如果显示红色/灰色，说明链路没起来，问题可能在连线方式，或者对应设备的接口处于shutdown状态。
2. Server网卡。ip addr看一眼，确认IP和掩码正确、网卡不是DOWN、网关配了对。
3. VLAN放通。中间交换机上，Server所接端口和上联端口是否在同一VLAN里，链路是否放行了目标VLAN。
4. 三层路由。跨网段通信时，Server的default gateway是否正确，设备上是否有回程路由。
5. 策略拦截。最后才是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.2，Server_Web服务器是202.100.10.100，Server_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当标尺，光靠设备命令回显，你永远只能“觉得通”，不能确定真的通。建议你也亲手跑一遍这个系列里的三个实验，跑完就会明白，模拟器里能说话的“最终用户”，比任何一条静态配置都有说服力。