HQY 一个和谐有爱的空间

很多同学都在问我要这些NFV的镜像。其实，绝大多数的NFV镜像都是可以从H3C官网直接下载的，非常开放！我之前也不止一次提到，H3C对于从业者和学习者的开放态度，完全比华为高出不止一个层级。比较常用的NFV镜像有虚拟路由器VSR、虚拟防火墙vFW、虚拟负载均衡vLB、虚拟交换机vSW、虚拟DHCP服务器vDHCP、虚拟宽带接入服务器vBRAS、虚拟无线控制器vAC等等，这些都是可以在H3C官网进行下载的。其中，vDHCP、VSR和vBRAS都在软件下载页面下的“NFV”产品线下，1000系列指的

我们前面介绍了一种VPP和openVPN组合使用的解决方案（openVPN + VPP = openVPP），我美其名曰为“openVPP”。在openVPP的组网中，分支设备VPP73使用普通网络，不具有公网IP地址，同时向总部设备建立穿越NAT设备的IPsec VPN隧道；同时有居家办公的员工使用openVPN接入公司网络，需要和分支的设备进行互通。然后就有小伙伴讲了，openVPN已经过时了，现在流行用Wireguard。那好吧，我试试能不能把VPP和Wireguard组合起来用一下，姑且

我们设想这么一种场景，某公司总部设备VPP72使用专线接入互联网，具有公网IP地址；该公司分支设备VPP73使用普通网络，不具有公网IP地址，同时向总部设备建立穿越NAT设备的IPsec VPN隧道；同时有居家办公的员工使用openVPN接入公司网络，需要和分支的设备进行互通。考虑到主要组件是openVPN和VPP，那我们姑且就将这种方案叫做openVPP方案吧！openVPP的组网示意图和互访流量示意图如下：这里面涉及的接口配置、IPsec配置、openVPN配置和NAT配置，我们前面都已经做

在实验中，我们使用两台VPP进行组网，配置发起方使用IKEv2协议来发起协商，进而实现自动协商生成SA。对等体之间通过IKE协议自动协商生成SA，并由IKE协议维护该SA。在正常情况下，IKEv2只需要进行两次交互，使用4条消息就可以完成一个IKEv2 SA和一对IPsec SA的协商建立，即第一阶段的交互生成IKEv2 SA，第二阶段的交互生成IPsec SA。通过上次的配置，我们发现VPP的IKEv2自动协商方式没有注明支持野蛮模式和NAT穿越，但是强调了设备角色区分发起者和响应者。往之前的

介绍一下VPP如何配置IPsec VPN。前面，我们已经讲了几十篇和VPN相关的文章了，有需要的小伙伴请参考合集（VPN合集）。简单回顾一下，IPsec（IP Security，IP安全）是IETF制定的三层（网络层）隧道加密协议，也是一种三层VPN（Virtual Private Network，虚拟专用网络），它可以为互联网上传输的数据提供了高质量的、基于密码学的安全保证。IPsec通过在特定通信方之间（例如两个安全网关之间）建立“通道”，来保护通信方之间传输的用户数据，该通道通常称为IPs

首先安装一个CentOS 7的操作系统，然后简单更新一下系统。yum list && yum update -y查看更新后的操作系统，可以看到系统版本为7.9.2009。接下来安装依赖包mbedtls和python36，这两个需要epel-release源，所以把这3个一起安装了。yum install -y epel-release mbedtls python36新建fdio-

不用半小时，最快8分钟即可在CentOS上完成VPP的部署进度条，百分之11前面介绍了从零开始安装一个VPP要多久？半小时，不能再多了！实际上，从安装虚拟机到测试结束，用时25分钟；如果不算安装和更新系统的时间，10分钟是足够的。如果操作熟练的话，差不多六七分钟能结束。

安装VPP后（VPP基本安装），直接进行了网卡纳管。配置DPDK接管虚拟机网口ens36，纳管前需将其down掉才可以纳管：配置文件startup.config在/etc/vpp目录下。配置前需要确认网卡对应的PCI号：要接管的网卡ens36 PCI为02:04.0，vi /etc/vpp/startup.conf，取消dpdk的注释，在## Set interface name下添加如下信息：dev 0000:02:04.0 { name eth0 }name可以自己定义，如下截图所示：然后安

本实验使用VPP 接管两个网卡，分别模拟WAN侧和LAN侧，WAN侧连接Vmnet8，接入互联网，LAN侧连接Vmnet2,在Ubuntu中搭建一个dhcp server,使另外一台虚拟机能够自动获取ip上网。环境Ubuntu 版本：20.04VPP 版本：23.02拓扑配置虚拟网络VMnet2 ：主机模式，连接一台windows 虚拟机VMnet8 ：NAT 模式，用于给VPP提供互联网 Ubuntu （VPP 运行的机器）创建两个网卡，VMnet2 和NATWin10 虚

我们之前介绍过如何配置WireGuard互联（在Ubuntu快速配置WireGuard互联），但是WireGuard不支持开机自动配置。不只是WireGuard，openVPN的客户端也不支持开机自启动，只有服务端支持。其实观察我们之前的配置，仅使用一条wg-quick命令就能快速实现WireGuard的配置，如下所示：wg-quick up /root/wg0.conf按照我们之前介绍VPP时的做法（Wireguard + VPP = WireVPP），我们可以将启动命令写

WireGuard的对标选手主要是IPsec和openVPN，目标是比IPsec更快、更简单、更精简、更有用，比 OpenVPN 性能更高。对比IPsec部分，我们之前也测试过了（2个报文即完成隧道建立！WireGuard的报文交互竟然比野蛮模式还快！），在Windows系统中，WireGuard确实相比传统的IPsec有了较大的改进，一般需要至多6次报文交互即可完成隧道建立；并且，传统的IPsec在转发层和接口层是分离的，而WireGuard则直接新建了一个虚拟接口来进行转发。性能部分，虽然我

一、前言因为家里宽带没有公网IP也不支持ipv6，一直使用 frps 作为内网穿透的工具。后来发现了 wireguard，于是就将家里的服务器与具有公网IP的云服务器组网，实现内网穿透功能。这里主要介绍 wireguard 的安装以及本人在用的两种组网方式，能够满足正常工作、学习所需了。二、 安装 wireguardwireguard 的安装，有内核版本的要求，所以低内核版本的系统，在安装时候需要先升级内核版本（5.0以上内核版本可以跳过）。因为本人使用的时 cen

Windows通过netsh命令配置IPsec前面介绍过IPsec协议规范和相关的配置实验（IPsec合集）。协议规范（IPsec：RFC2401-互联网协议的安全架构）里面也提及了，IPsec定义了两种类型的SA：传输模式和隧道模式。传输模式 SA 是两个主机之间的安全联盟。隧道模式SA是两个安全网关之间的安全联盟。既然之前测试的都是安全网关之间的隧道模式的IPsec，那我想你大概率没有接触过主机之间的传输模式的IPsec。那怎么测试呢？那就用两台Windows创建IPsec试一下吧。首先铺垫

本文将以netsh和MMC两种方式配置主机间的IPsec，也就是一台使用netsh方式，另一台使用MMC方式。组网图实验环境VM1：Microsoft Windows Server 2008 R2 Datacenter（6.1.7601 Service Pack 1 Build 7601）VM2：Microsoft Windows Server 2012 R2 Datacenter（6.3.9600 暂缺 Build 9600）vFW：Version 7.1.064, ESS 1171P13实验

结合RFC2401（IPsec：RFC2401-互联网协议的安全架构）、RFC2402（AH：RFC2402-IP Authentication Header）、RFC2406（ESP：RFC2406-IP Encapsulating Security Payload）的相关说明：IPsec SA（Security Association，安全联盟）分为两种类型：传输模式和隧道模式。传输模式 SA 是两个主机之间的安全联盟。在 ESP 的情况下，传输模式 SA 仅为这些更高层协议提供安全服务，而

IPsec实验测试了两端不同子网的隧道打通，那能不能打通两端相同的子网呢？原则上是不行的，因为不同站点的网段在设计时就要求不能冲突，这样会影响报文的正常转发。当分支数量大于2个时，也会导致不同隧道的保护流量源目地址段重复，进而导致数据转发异常。但是，大二层网络技术都已经实现了，为什么IPsec不能用呢？我们来一步一步地分析一下具体原因和解决办法。组网需求和组网图和上个实验相同。在RT1和RT2之间建立一条IPsec隧道，对PCA（192.168.1.101/24）与PCB（192.168.1.1

前面的文章中（IPsec：RFC2401-互联网协议的安全架构、IPsec小实验：手工方式建立保护IPv4报文的IPsec-ESP隧道、为什么IPsec两端内网的网段能不能重复？分明可以实现！、填坑：IPsec不同安全协议的报文封装结构对比、还能这么玩？Windows通过netsh命令配置IPsec、使用MMC和netsh两种方式配置Windows Server传输模式IPsec），我们用了很大篇幅来说明IPsec支持的两种封装模式：传输模式和隧道模式。传输模式SA是两个主机之间的安全联盟。在E

实际应用场景中，如果和SD-WAN结合起来，很少会使用这种两端直连的场景（IKE主模式及预共享密钥认证配置）。或者说，两个子网的互通可能是通过第三台设备来实现的。举例说明一下，上次的实验中，RTB和RTC是直接建立的IPsec隧道，而实际应用中，有可能是RTA和RTB、RTC之间分别建立IPsec隧道，再实现RTB和RTC两台设备下挂子网的互通。组网需求某SD-WAN使用场景，组网使用3台路由器。图中RTA为总部设备，RTB、RTC为分支设备，RTA和RTB、RTC之间分别建立IPsec隧道，对

测试VPP的性能和性能调优时，我查阅了VPP官网的相关资料，其中有一条让我有点意外。对于虚拟化扩展功能，前面讲必须启用“英特尔虚拟化扩展”（用于VT-x）和VT-d（用于直接IO）以及DMA重新映射（DMAR）。VT-d启用PCIe直通所需的IOMMU虚拟化功能。此外，应启用中断重新映射，以便可以将硬件中断重新映射到VM以进行PCIe传递。但是后面又说“建议禁用VT-d一致性支持以获得更高的性能”。至于最后提到的Intel Sandy Bridge架构的CPU，如果需要高性能，则不建议使用San

现在我们已经有了穿越NAT场景下的Full-Mesh组网（HPE VSR配置穿越NAT场景下的ADVPN案例），并且还知道了分支之间互访的Spoke-Spoke隧道的转发是不需要经过HUB节点的（ADVPN的S-S捷径到底有没有从总部绕转？）。我们也配置了基于IPsec VPN的VXLAN“专线”（一种基于IPsec的VXLAN“专线”解决方案），那把这几种整合起来，是不是就有了一张跨越在公网上的大二层网络交换机了呢？实验组网如下图所示：为了不受公网带宽影响，方便测试性能，3台设备我们都使用本地