-
从崩溃到3G带宽！Panabit三种部署模式性能实测，这个坑千万别踩 我们前面学习了Panabit的两种部署方式（Panabit竟能无缝整合Ubuntu？用5MB升级包在Ubuntu极速安装Panabit），当我打算把他用起来时，发现有一点瑕疵，那就是安装完成之后只能调整CPU和网卡数量，不能调整内存规格，一旦调整了内存规格，要么无法引导；要么进入无限自检报错循环，无法启动服务。 我本来想着给他多分配一点资源，等配置完成之后简单测试一下性能的，看来得重装一台高规格的虚拟机了。切换到ESXi平台，我们按照之前的方法重新部署一台高规格虚拟机（误以为是外国货？这家国产SD-WAN神器竟能免费白嫖，附Panabit免费版体验全记录），先分配16核CPU、16 GB内存，结果安装完之后就进不了系统了。 最终，经过多次尝试，内存最高大概也就是能分配到3 GB，再大就启动异常了。所以，我们就得到了一台8核CPU、3 GB内存的“高”规格虚拟机。 在后台查看系统配置，生效8核CPU，总内存3002 MB，剩余1827 MB。 查看系统进程，发现有5个/usr/ramdisk/bin/panaos的进程，照此推断，分配6核CPU应该就够用了。 系统到位之后，我们测试一下Panabit的设备上线。 在WEB管理页面，点击工具栏的【上线指导】，网络模式我们先选择【网关模式】。 在网络配置环节，这里的配置挺有意思，通过按钮可以切换网卡角色是WAN接口还是LAN接口，通过点击网卡图标可以配置对应的网卡配置。按照它的默认配置，eth1是LAN接口，eth2是WAN接口，我对换了一下，配置WAN接口参数如下： 奇怪的是，配置接口IP地址竟然不需要配置掩码，不知道会下发成多少。 然后点击eth2配置LAN接口参数，可以直接配置DHCP相关参数。 确认配置参数，然后提交。 配置成功之后，可以在导航栏【网络设置】下的【网络接口】查看接口信息，其中方向对应接口角色，eth1是WAN口，方向对应接外；eth2是LAN口，方向对应接内。 还可以在【网络设置】下的【LAN/WAN】中查看接口配置。其中，LAN接口状态如下： WAN线路状态如下，仍然没有显示掩码长度信息： 在【网络设置】下的【路由/NAT】中，对于网关模式还默认创建了一条NAT规则，如下所示，可以看到，一条默认路由将流量全部引到WAN接口，并启用了NAT地址转换。 接下来，简单测试一下转发性能。 最高带宽3.22 Gbps，平均带宽2.98 Gbps，没有特别强，但也不是很拉胯。观察打流过程中的资源利用率，最高也就到200%，应该是资源分配问题，相比于空载下的100%，说明也就是一个新核心参与转发，基本上负载在CPU0上；理论上讲，提升空间还是很大的。 查看应用排名，它将iperf打流流量识别成了未知应用，统计到的累计流量为30.61 GB，按照iperf服务端的统计为29.02 GB，两者差的不多。 接下来，我们再次点击【上线指导】中，将网络模式修改为【透明网桥模式】。 在网络配置环节，可以通过拖动开交换网卡对接位置，按照前面的操作，我将eth1放到了接外一侧，将eth2放到了接内一侧。 确认配置环节，这个对端网卡有点跳戏，不过也能明白，确认提交。 配置生效之后，此时【网络设置】下的【LAN/WAN】中已经不展示接口了。 调整主机配置，先测试一下连通性。 然后测试一下转发性能，测得最高带宽3.42 Gbps，平均带宽2.99 Gbps；整个打流过程中，CPU利用率没有明显变化，像是没有处理转发的报文。对比网关模式，性能提升微乎其微；换言之，网关模式对比网桥模式几乎没有性能损耗，貌似也还可以。 虽然是网桥模式，但还是能统计到有12.22 GB的流量，相比于iperf服务端的统计的11.53 GB，还是存在一点小差异（5.6%），在可接受范围之内。 最后一种网络模式就是我们前面提到过的【旁路分析模式】了。 这里的合法IP指的是需要分析的内网IP网段，可以添加多个，设备通过内网网段来区分上下行流量，内网网段为源地址则是上行流量，内网网段为目的地址则是下行流量。 正常来讲需要配置端口镜像来进行分析，我ESXi内网环境简单，先简单演示一下。 此时【网络设置】下的【LAN/WAN】中同样不展示接口，在【网络接口】中查看，发现两个接口都设置成了【接内】方向的监控模式，有一点流入速率。 查看应用排行，只剩下ARP报文和ICMP报文了。 好了，Panabit的三种接入方式我们就介绍完了。 ***推荐阅读*** 误以为是外国货？这家国产SD-WAN神器竟能免费白嫖，附Panabit免费版体验全记录Panabit竟能无缝整合Ubuntu？用5MB升级包在Ubuntu极速安装Panabit48核+96GB内存！EVE-NG 6.2低配版安装实录，网络工程师必看！告别重装！Ubuntu 22.04直升24.04教程，零数据丢失的终极方案小白也能玩转VPP！Ubuntu 24.04使用APT极速部署VPPCentOS迁移指南：在Ubuntu上从零编译部署VPP+DPDK，解锁Ubuntu网络性能！从单网卡到全局，3种方法教你精准拿捏Ubuntu的IPv6IPv6隧道搭建指南：用WireGard轻松玩转IPv4/IPv6混合网络基于IPv6配置openVPN实战：告别双栈难题，一步打通IPv6隧道！无需公网IPv4！手把手教你配置基于IPv6的WireGard安全隧道手把手教你玩转IPv6 PPPoE：Ubuntu拨号+VSR服务器配置全解析运营商不会告诉你的秘密：企业级路由器能通过多拨叠加带宽，轻松跑满千兆！目前来看，ollama量化过的DeepSeek模型应该就是最具性价比的选择哪怕用笔记本的4070显卡运行DeepSeek，都要比128核的CPU快得多！帮你省20块！仅需2条命令即可通过Ollama本地部署DeepSeek-R1模型 -
零成本自建企业级SD-WAN！用Panabit手搓iWAN实战 我们前面提到过，最开始了解到Panabit，是因为他的SD-WAN产品（误以为是外国货？这家国产SD-WAN神器竟能免费白嫖，附Panabit免费版体验全记录）；现在发现，其SD-WAN的技术基础是iWAN，那肯定要研究一下iWAN。 按照官网介绍，iWAN可以分为3种角色：iWAN服务端、iWAN客户端和iWAN管理端，对应SD-WAN网络中的POP、CPE与控制器三种角色。其中iWAN服务端和iWAN客户端均可以通过Panabit来实现，而iWAN管理端则一般使用PanaCloud云平台。PanaCloud云平台负责管理所有CPE与POP点设备，对所有设备进行统一运维，包括隧道配置下发、整网拓扑管理、隧道状态维护等。这么看来，抛开PanaCloud云平台，我们用Panabit应该也能手搓一个简易SD-WAN网络。 从配置页面来看，iWAN位于虚拟专网分类下，那一定程度上讲，iWAN也是VPN隧道；既然如此，建立隧道肯定需要IP地址，那网络模式肯定是要使用网关模式。 比较有意思的是，Panabit还支持应用商店，这里有一个【拓扑图构建】的应用，我们就用它来画一下本次实验的拓扑图。 对于iWAN来说，设备角色分为服务端和客户端，本次实验中，我们期望将Panabit1配置为服务端，将Panabit2配置为客户端。 首先，我们要完成两台Panabit的上线配置，服务端Panabit1的网络配置如下： 客户端Panabit2的网络配置如下： 客户端需要能够访问到服务端的WAN口IP地址，在客户端侧使用系统自带的网络检测工具探测一下服务端是否可达。 接下来，我们先配置iWAN服务端。在【虚拟专网】下的【iWAN服务】中的【服务列表】页签，点击【添加】按钮，弹出【添加iWAN服务】对话框，配置很简单，需要补充服务器名称、服务器网关、认证方式和地址池等信息。 这里，我们首先要找到地址池配置。在【对象管理】下的【账号管理】模块，切换到【组织架构】页签，这里显示的地址池都是空的，应该不能使用。 点击【添加用户组组】，我们创建一个给iWAN服务用的用户组iWAN，看上去跟配置openVPN的服务端有点像（在Ubuntu系统手撸一个自动搭建openVPN服务端的SHELL脚本）。 对应本地认证的认证方式，我们还要点击【添加本地账号】来创建一个iWAN客户端账号。这个配置还挺丰富，可以限制账号的有效期、同时在线用户数、绑定IP等信息，就是不知道如果允许3个客户端同时在线时绑定IP地址还有效吗？ 配置完地址池和本地账号之后，回到【iWAN服务】页面，完成服务端的创建。 细心观察的话，可以看到后面还有一个【服务映射】的页签，创建好iWAN服务之后，这里自动将8000端口映射到了刚创建的iWAN服务上。 确认了一下，iWAN服务默认使用UDP端口8000，通过服务映射是不是可以同时启用多个iWAN服务了？ 到这里，iWAN服务端就搭建好了，我们继续配置iWAN客户端。在客户端Panabit2的WEB页面，在【虚拟专网】下的【iWAN客户端】模块，点击【添加】来创建一个iWAN客户端。 这里填入跟服务端匹配的服务器IP、服务器端口、iWAN账号和密码，令人意外的是，这里的加密竟然是个可选项，还支持二层转发。先使用默认配置，剩下的后面再测试。 提交之后，iWAN客户端上线成功，并且获取到了指定的IP地址10.13.1.3。 这时候，我们就能使用iWAN客户端测试iWAN服务端是否可达了。 测试通过之后，就可以在【路由/NAT】模块中添加iWAN客户端和服务端之间的内网路由了。首先是iWAN服务端一侧，必填项是策略序号、源/目地址和执行动作。 如果是目的路由，仅填入目的地址即可，如果同时填入源目地址，那就是策略路由了；执行动作选择【路由】，路由线路选择【iWAN】，下一跳填入iWAN客户端的IP地址。 对应的，完成iWAN客户端侧的路由配置。 此时，在两端的内网主机上进行测试，是无法互通的。差了官方的配置手册，经过多次测试验证，发现这个系统比较奇葩，竟然需要手工添加直连路由；也就是说，Panabit作为内网的网关，他可以直接访问局域网内的终端，但是没有路由条目，如果其他设备要访问进来，还得单独添加到LAN侧的路由。 我就说，怎么追踪路径，发现请求流量没有转发到内网，而是直接扔到了WAN接口上。 此时再进行测试，就能正常互通了。 但貌似也不太正常，为什么呢？分明中间过了隧道，为啥显示一跳就到了？ ***推荐阅读*** 误以为是外国货？这家国产SD-WAN神器竟能免费白嫖，附Panabit免费版体验全记录Panabit竟能无缝整合Ubuntu？用5MB升级包在Ubuntu极速安装Panabit从崩溃到3G带宽！Panabit三种部署模式性能实测，这个坑千万别踩48核+96GB内存！EVE-NG 6.2低配版安装实录，网络工程师必看！告别重装！Ubuntu 22.04直升24.04教程，零数据丢失的终极方案小白也能玩转VPP！Ubuntu 24.04使用APT极速部署VPPCentOS迁移指南：在Ubuntu上从零编译部署VPP+DPDK，解锁Ubuntu网络性能！从单网卡到全局，3种方法教你精准拿捏Ubuntu的IPv6IPv6隧道搭建指南：用WireGard轻松玩转IPv4/IPv6混合网络基于IPv6配置openVPN实战：告别双栈难题，一步打通IPv6隧道！无需公网IPv4！手把手教你配置基于IPv6的WireGard安全隧道手把手教你玩转IPv6 PPPoE：Ubuntu拨号+VSR服务器配置全解析运营商不会告诉你的秘密：企业级路由器能通过多拨叠加带宽，轻松跑满千兆！目前来看，ollama量化过的DeepSeek模型应该就是最具性价比的选择哪怕用笔记本的4070显卡运行DeepSeek，都要比128核的CPU快得多！
-
iWAN隧道实测：一次握手跑满2.3Gbps，白嫖的SD-WAN真能吊打专线？ 在上次实验中（零成本自建企业级SD-WAN！用Panabit手搓iWAN实战），我们使用Panabit初步完成了iWAN隧道的搭建，不过也遗留了几个问题。 首先，为什么两端的内网互通时，中间传输分明经过了隧道，但为啥显示一跳就到了？经过查询，发现有说法是iWAN隧道为点对点封装，中间路径不可见，现象对得上，但引入了一个新的疑问，那就是跟配置隧道时的【二层转发】还有什么区别？ 关于二层转发，需要升级专业版才能支持，这么一来，我们就测试不了了。与此同时，官方介绍iWAN还支持Segment Routing，这个也需要专业版授权才能支持，看来iWAN的测试要止步于站点互通了。 其次，查资料的时候发现，iWAN对比专线、IPsec VPN和L2TP VPN，均有一定的优势；尤其是在连接速度和传输效率方面。 这两个也好测试，直接抓包就能看出来。 首先，报文特征非常明显，都是UDP端口8000，没有使用其他端口。从协商过程来看，貌似是经过一次握手就完成了隧道协商，也就是最上面的两个报文，请求报文的数据长度为53字节，响应报文的数据长度为50字节；之后的报文间隔都是固定的2秒，应该是进入了保活阶段，并且报文的数据长度都是统一的52字节。 根据官方iWAN隧道技术白皮书介绍，iWAN只需要一次交互即可完成隧道建立，跟我们看到的情况一致；但对比时说传统VPN隧道需要几十次交互，有点夸张了。 当然，我们在配置时并没有启用加密，但是从报文封装来看，是对报文做了处理的。 我们的ping包原始长度为64字节，其实内层数据长度只有48字节，加上封装的长度为16字节的ICMP报文头，长度才达到64字节。实际上，ICMP报文头外层还封装了20字节的IP报文头，这时报文长度就达到了84字节，也就是iWAN封装前的报文长度；加上iWAN封装的8字节报文头，正好是数据报文长度92字节。而iWAN隧道接口默认的MTU为1420字节，实际传输效率能达到1420/1482=95.8%，确实挺高的。 根据官方iWAN隧道技术白皮书介绍，在后续版本里，Panabit还会继续压缩IP报文头，以继续减少额外报文头的大小，从而大幅度提升传输效率。但是其在稳定性对比中提到，iWAN轻安全，主要是依赖仅进行完整性校验实现的，如果对8字节报文头再进行压缩，性能提升不会很明显，安全性却会降得更低。 在未启用加密的情况下测试一下传输带宽，最高能够达到2.32 Gbps，平均也有1.85 Gbps。咱就说，白嫖免费版SD-WAN的用户里面，有几个出口带宽达到2 Gbps的？ 看完了未启用加密的情况，我们再看看启用加密的数据。 首先，看协商过程，第一轮隧道协商的握手报文都增加了3字节，应该是增加启用加密的字段；之后的保活报文间隔依然是固定的2秒，且报文的数据长度都是统一的52字节。 从ping包的封装长度来看，内层的数据报文长度依旧是92字节。咋回事？不是说了加密吗？ 我们再看看传输带宽是否有变化？ 加密后的带宽还是有变化的，最高带宽为1.63 Gbps，平均带宽为1.52 Gbps，相比于未启用加密时，性能降低大约18 %。不过话说回来，白嫖免费版SD-WAN的用户里面，出口带宽达到1.5 Gbps的也不多吧？ 观察后台的系统资源利用率，发现CPU利用率还没有正常打流时高，看来Panabit还手下留情了；如果放开的话，不知道能跑到多少呢。 所以，在实际使用中，你会选择开启加密吗？ ***推荐阅读*** 误以为是外国货？这家国产SD-WAN神器竟能免费白嫖，附Panabit免费版体验全记录零成本自建企业级SD-WAN！用Panabit手搓iWAN实战Panabit竟能无缝整合Ubuntu？用5MB升级包在Ubuntu极速安装Panabit从崩溃到3G带宽！Panabit三种部署模式性能实测，这个坑千万别踩48核+96GB内存！EVE-NG 6.2低配版安装实录，网络工程师必看！告别重装！Ubuntu 22.04直升24.04教程，零数据丢失的终极方案小白也能玩转VPP！Ubuntu 24.04使用APT极速部署VPPCentOS迁移指南：在Ubuntu上从零编译部署VPP+DPDK，解锁Ubuntu网络性能！从单网卡到全局，3种方法教你精准拿捏Ubuntu的IPv6IPv6隧道搭建指南：用WireGard轻松玩转IPv4/IPv6混合网络基于IPv6配置openVPN实战：告别双栈难题，一步打通IPv6隧道！无需公网IPv4！手把手教你配置基于IPv6的WireGard安全隧道手把手教你玩转IPv6 PPPoE：Ubuntu拨号+VSR服务器配置全解析运营商不会告诉你的秘密：企业级路由器能通过多拨叠加带宽，轻松跑满千兆！目前来看，ollama量化过的DeepSeek模型应该就是最具性价比的选择哪怕用笔记本的4070显卡运行DeepSeek，都要比128核的CPU快得多！