利用VeeamPN做SitetoSitePNV

对于一般企业要做Site to Site PNV 一般配置比较麻烦和有点复杂，

成都创新互联坚持“要么做到，要么别承诺”的工作理念，服务领域包括：网站设计制作、做网站、企业官网、英文网站、手机端网站、网站推广等服务，满足客户于互联网时代的石家庄网站设计、移动媒体设计的需求，帮助企业找到有效的互联网解决方案。努力成为您成熟可靠的网络建设合作伙伴！

但是 Veeam 为了方便备份到Azure 上，在2017年出了一下能够打通企业内网到Azure云 的通信，

推出了一个免费的产品：Veeam PN

利用它可以方便的做 Site to Site /point to Site 的PNV

veeam PN 从2.0 开始 可以在ubuntu 18.04上直接安装，而不用下载他的OVA的虚拟机文件了。

接下来，我就来在ubuntu 上直接安装Veeam PN 来实现 site to site PNV

以下是我测试的环境：

SiteA: 10.11.12.0/24

SiteB: 172.16.8.0/24

VeeamPN Hub 部署在 Site A (有公网IP)

VeeamPN Hub 内网IP: 10.11.12.9

VeeamPN Gateway 部署在 Site B (无公网IP)

VeeamPN Gateway 内网IP：172.16.8.8

VeeamPN System Requirements

• Ubuntu 18.04
• 1 vCPU (Minimum)
• 1 GB vRAM (Minimum)
• 16 GB of Hard Drive space
• External Network Connectivity

1.在ubuntu 18.04 VeeamPN

登录site A ubuntu 配置hostname : ni-pnv 配置静态IP :10.11.12.9

vi /etc/hostname

vi /etc/netplay/01-necfg.yaml

netplan apply 应用配置：

下载并添加Veeam Software Repository Key：

curl -k http://repository.veeam.com/keys/veeam.gpg | apt-key add -

出错了,原因是gnupng2 没有安装

apt install gnupg gnupg2 gnupg1

添加VeeamPN 的 APT source list 文件：

vi /etc/apt/sources.list.d/veeampn.list

或：

echo "deb [arch=amd64] http://repository.veeam.com/pn/public pn stable" > /etc/apt/sources.list.d/veeampn.list

然后运行 apt update

添加 WireGuard apt Repository:

apt-add-repository ppa:wireguard/wireguard

apt install software-properties-common -y

安装完后，重新运行apt-add-repository ppa:wireguard/wireguard

接下来就可以正式安装 VeeamPN:

apt  install veeam-pnv-ui veeam-pnv-svc

直到安装完成：

在浏览中打开Veeam PN web Portal:

更改root密码：

正式开始部署Veeam PN Hub:

将这个配置文件保存下来，将在配置Site B 端的Veeam PN 时要用到的。

完成Site A 端的 Veeam PN的配置，

然后在Site A 端的防火墙上配置到Site B 端的默认路由。

到这里，Site A 端就全部配置完毕。

接下来在Site B 端 的Ubuntu 上安装Veeam PN

方法和Site A 完全一样。这里省略….

安装Veeam PN 完后，在 浏览器中打开 Veeam PN web portal:

找到在Site A 配置 Client 时下载的xml配置文件：

点击 ：finish 完成配置。

接下来看到 server Connected :

接下来我们看看，从site A 到 site B 是否能连通：

在Site A 的系统上运行cmd

到这里为止，从Site A 到 Site B 是可以通信的。

最后我们要看一下从Site B 到 Site A是否能通信？

在site B 端的防火墙上添加一条 到site A 的静态路由：

然后看看，在site B 的系统上ping Site A 是否能通：

这样看来，site B 到 Site A 是无法通信的。

通过对比 site A 和 B 的 Veeam PN上的路由表，我们发现在 Site B 的 Veeam PN 上没有到 Site A的路由：

Site A 的路由表：

Site B 的路由表：

现在试着在Site B 上手工添加一条到 site B 的路由是不是可以呢：

结果是：

之前是请求超时，加了路由后是 无法访问目标该机

跟踪路由发现应该是site B 端的 veeam pn  无法转发 到 site A 的通信。

此问题暂时无解，后续再看看应该是wireguard 的配置问题。

这个问题在官方的文档里都没有体现，Veeam 在这上面有点过分，

记得 veeam PN 1.0 出现同样的问题，手工添一条路由就可以相互通信的。

现在Veeam PN 2.0 同样的问题还是没有在官方的文档上提到，

https://helpcenter.veeam.com/docs/veeampn/userguide/how_to_local_sites.html?ver=20

官方论坛里有人提到：https://forums.veeam.com/veeam-tools-for-microsoft-azure-f36/veeampn-working-but-only-in-one-direction-t62278.html

附：

解决方法：

通过对比Site A 和 Site B 上的 Wireguard的配置发现：

site A :

Site B:

发现在site B 配置中的allowed ips 中并示包括 site A 的地址段：10.11.12.0/24

所以我们要在site B 的WireGuard 的allowed ips配置中添加 10.11.12.0/24 这段地址：

wg set wg.veeampn peer  ************  allowed-ips 10.11.12.0/24,10.211.0.0/16,10.210.0.0/16

现在来看看 site B 到 Site A是否能正常通信：

这样现在是可以正常通信的。

所以，从这件事可以看出有时候完全按官方文档来操作也是会出问题，

而且像veeam PN 这样的在连续几个版本的更新都存在同样问题视而不见，

直不知写那个官方文档的人是否真正做过测试，还是想当然的凭空来写的文档。

通过测试发现手动添加的路由和修改，系统重启后会消失的。

可以考虑让这几条命令在系统启动时自动加载

由于Ubuntu 18.04 默认不启用rc.local,因些先得启用：

ubuntu18.04不再使用 inited 管理系统，改用 systemd，

systemd 默认会读取 /etc/systemd/system 下的配置文件，该目录下的文件会链接 /lib/systemd/system/ 下的文件。一般系统安装完 /lib/systemd/system/ 下会有 rc-local.service 文件，将 /lib/systemd/system/rc-local.service 链接到 /etc/systemd/system/ 目录下面来：

ln -fs /lib/systemd/system/rc-local.service /etc/systemd/system/rc-local.service

vim /etc/systemd/system/rc-local.service

在文件末尾增加：

[Install]

WantedBy=multi-user.target
Alias=rc-local.service

编辑/etc/rc.local

vim /etc/rc.local

内容为：

#!/bin/bash

sleep 90

wg set wg.veeampn peer ************ allowed-ips 10.11.12.0/24,10.211.0.0/16

route add -net 10.11.12.0/24 dev wg.veeampn

exit 0

这样就实现真正的site to site 之间的相互通信了。