Ocserv
ocserv实际上是以socks连接的，使用netstat -npl | grep 443命令以后，会发现，init在监听443端口，那么这就出现了一个问题，443被占用了，Apache2的SSL要怎么办？
Linux的软件大多都可以根据实际的应用情况而灵活配置，我相信ocserv也不例外，详细查阅man手册和官网的文档，包括debian的Bug report，还是让我找到了蛛丝马迹。主要的解决办法可以参照链接。
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=837944
默认的情况下，直接修改ocserv的配置文件/etc/ocserv/ocserv.conf然后直接service ocserv restart是不会有任何作用的。原因就在于ocserv是以socks方式运行的，由systemd管理，由daemon守护。
修改/etc/ocserv/ocserv.conf中端口的设定之后，新建一下配置文件，添加如下配置信息
/etc/systemd/system/ocserv.socket.d/port.conf
[Socket]
ListenStream=
ListenDatagram=
ListenStream=10443
ListenDatagram=10443
使用以下命令重载配置文件
systemctl daemon-reload
service ocserv restart
注意，这里/etc/ocserv/ocserv.conf和/etc/systemd/system/ocserv.socket.d/port.conf这两个配置文件设置的端口值需要一致。
然后就会发现ocserv在监听10443端口，这样Apache的443就可以腾出来了。
后记：
其实我也搞不通，为什么ocserv为何默认会监听443端口，这点确实出乎意料。我发现此问题的原因是，在我使用certbot给站点升级https的时候发现，certbot的tls-sni-01证书challenge总是不成功，然后被迫使用DNS challenge的方式来验证主机的所有权，在完成证书的安装、https激活和确定站点的配置文件全部正常之后，打开站点主页，返回的竟是一个含有vpn的xml页面，怎么回事？
随手netstat -npl | grep 443 发现init在监听443，为嘛不是Apache在监听443？随即google,然后就发现有人提到ocserv端口占用的问题，使用systemctl status ocserv.socket验证一下，果然443被占用了。由于ocserv是很久之前就装上了，我几乎忘了这件事。这是一次由端口占用而导致的乌龙。