对于一般企业要做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 之间的相互通信了。