假设，你是一个中小微型企业的网管。

现在有员工需要做远程接入，不过老板不是很想花钱买商业公司的VPN解决方案，而且员工急用呢，很急很急

现在让你解决一下这个问题，你会怎么做？

前言

引言这个问题有很多解决方案，但是解决方案有很多问题，先把结论放在前面：各种看起来合适的方案只能说是『还凑合』，并不能达到完美的需求。当然如果我们放宽一点要求，还是可以找到一些适合你的方案的：

• OpenConnect
• OpenVPN
• IKEv2-MSCHAPv2
• WireGuard

具体的优劣对比会放在下面，有需要的可以点击目录列表查看

本文纯粹是一篇吐槽文章，但是并不介意各位读者在评论区推荐你正在用的VPN，以及，如果有企业网管的话，不妨分享一下你们的选择。

毕竟笔者毕业之后大概率还是做一个苦逼网工，也就打打水晶头，拉拉网线，维持下生活这样子。

主要考虑的问题

我们先来看看引言到底在说什么：

你是一个中小微型企业的网管

废话，大型企业根本不需要担心这个问题，基本上都会联系VPN供应商来解决这个问题（一方面包括技术方面的，另一方面是合规性方面的，比如网络等保，比如安全接入，等等等等），钱给到位很多都好说；或者大型企业有自己的IT团队，有办法在内部解决掉这个问题。太小的企业呢，可能又没有此方面的需求（很多都是云上办公了现在，部分小微企业甚至已经把自己的OA系统迁移到了钉钉上面）

被夹在中间的中小企业就处于一个很微妙的地位：自己的体量有需要用到VPN（例如你是MCN，在公司的存储服务器上有各种资源，又不方便直接开放到公网，也不好全部上传到网盘），但是又不一定可以支付得起商业公司的VPN成套方案的费用。而且，不是笔者话多，很多时候上头领导真的只是让你赶紧想一个work around出来，急着用，对于接入之后的事情他真的不在乎。说句不好听的，你指望一个内网只能敲IP的中小企业老板去理解什么叫做安全？领导只会让你赶紧干，干不了就走人，你不干有得是人干。所以在这里也提醒各位网工，再说句不好听的，得把责任弄清楚，虽然说你要保证VPN接入的安全，但是现在是老板让你这么干的，是他不想出钱，所以最好还是提醒下他相关问题

什么？提醒了但是他说『哎呀现在时期艰难，没那么多钱啊』？行呗，那咱们继续聊

翻了一下相关法律定义，不同行业对于小微企业定义的标准（具体来说是人数）不同，但是基本上可以认为是：

信息传输业：小于10人为微型，10-100为小型，100-2000为中型
软件和信息技术服务业：小于10人微型，10-100人小型，100-300中型

为了方便计算起见，尤其是考虑到并不是每个员工都有出差的需求，能同时联系过来的供应商数量也有限，我们暂时取一个平均的数字：80个会话数，作为VPN系统的最大容量。

80个会话这个数字老实说比较典型，一方面数量不少了，不适合手动编辑配置文件的方式来开槽位，或者你愿意复制粘贴80条密码或者别的配置也行；另一方面数量也不算多，一个/24网段也能够塞下所有用户，甚至还有很多空间可以用来做后期的扩展，甚至数量多两倍也能放得下。

现在有员工需要做远程接入

鬼知道什么原因，出差？居家办公？和供销商做安全对接？反正就是有远程接入的需求，并非站点到站点（Site-2-Site）VPN，而且更多的是和公司之间的纵向连接，并非出差员工之间的横向连接。

此外，员工不是IT人士，因此所有操作一定要简洁，简便，直观。就比如，远古时期有个著名笑话：

英语阅读：小明在饕鬄麤齾虋纞鷩蘩找到了驫鸜齾虋纞灥灪，靃纛欻欂了之后觉得靆麷纛黻
问：什么是驫鸜齾虋纞灥灪，为什么会觉得靆麷纛黻

别笑，这其实是很多人的困境：很多知识隔行如隔山，你不能指望一个普通员工（可能是主播，美工，写手，摄影师，文案，甚至是某个登陆到系统做账的会计）知道什么叫做证书，什么叫做路由表，什么叫做MSCHAPv2，他们知道的只有账号密码，顶多加一个网址。因此选型的一个很重要因素是：尽可能零配置（严格来说是少配置），把专业的事情留给专业的人干。

此外，移动端的需求也在日益增长，如果一个协议无法在移动端使用，那么也可以把优先级往后排排了。

商业公司，和急用的员工

上面提到的深信服EasyConnect是一个例子，其他例子还包括思科AnyConnect，或者如果你是清华大学的一份子，可能还会用上Pulse Secure。

先说作用层面。像这种闭源的VPN解决方案，一般都会针对企业这个应用场景做优化，比如深信服有做企业内零信任的，也有做审计的；另外就是对于目标用户做了优化，主要是极大的简化了用户配置的复杂度（基本上做到只要安装好客户端，输入链接甚至是识别码，然后输入登录信息，就可以连接成功），不必让用户去折腾加密配置，协商配置，网络配置，等等等等。此外的话，可能还有一些增值服务，比如零信任安全，出口网关什么的，一般都会打包卖给你，所以顺便提一下。不过这些内容和本文关系不大，所以不作介绍。

不过这就带来了一个问题：由于这些深度定制的VPN（现在有了更多好听的名字，比如什么零信任网关，SD-WAN组网网关，资源安全访问网关，通信行业很喜欢创建新名词，都不知道为啥）都是由商业公司出品的，功能丰富是不错，但是在授权费上就能砍你一刀。回到刚刚的例子，80个会话数，深信服授权费是多少，笔者不清楚，但是假设就按照10元一个会话数来计算（比这个价格低就更好了，但估计可能性不太行），80个会话数的价格那就是800元，这还不算VPN网关的钱。你看向你的老板，他表示没钱，并把锅扔回来给你了。

此外还有一个不太算是原因的原因，很多商业VPN网关，为了提供质量较为统一的服务（当然也为了增大破解授权的难度），送到公司手上的真的就是一台设备，至少也是一个完整的系统镜像（且一般不对普通企业提供），对于需要快速部署的情况来说，并不显得太简便。

技术选型

又到了聊技术的时间，看过我博客的朋友都知道，站长最喜欢的就是技术环节了。人文社科的内容呢，除非真的有感而发，不然还是很难挤出来多少字的。

行了，你把该说的都跟老板说了，但是老板还是让你想一下凑合用的方案。毕竟世界就是个草台班子，你我都是草台班子的成员，配合一下得了。

开写之前需要提一嘴，下面不会讨论GRE，IPIP，VxLAN之类一看就不是给一般人用的东西，而且他们还没有加密，所以如果不是特殊需求，没必要去应付这些东西。

PPTP

结论：别用PPTP，打死也别用，除非设备只支持PPTP

PPTP，点对点隧道协议，应该可以说是历史最为悠久的VPN协议之一，通过TCP 1723端口进行链路协商，通过魔改版IP 47（GRE）进行实际的链路通信。也许你还记得十几年前（2012年之前吧），用PPTP科学上网的时候。那时候已经有类似机场的形式了，你网银转账过去，他发PPTP账号密码过来，你在你电脑上敲地址和账号密码，就连上了。如果你是大牛（没开玩笑，当时能这么玩确实是大牛了），想要自己搭建PPTP服务器，那么你还得费心思检测你用的服务器支不支持起tun，尤其是当年OpenVZ小鸡满天飞，你还得黑着脸去开工单让老板开母鸡的tun权限....说多了都是泪。

能知道这幅图出处的朋友估计也不年轻了

话题回来。PPTP他的优点是，可以通过用户名密码进行认证，而且设置简便。就这样。没了。PPTP的缺点远大于优点，这也就是站长想把他扔到垃圾桶的原因。

首先是加密问题。PPTP使用的MPPE加密，在刚推出来的时候（别忘了那可是1999年）其实还是不错的，有点加密总比完全裸奔要好，可以看作是对于GRE的一个补充。但是随着电脑算力增强，MPPE所使用的加密（40或者128位RC4）已经变得弱不禁风，再加上协议设计存在缺陷，根据笔者查到的资料的说法，基本上可以认为是能用简单的工具进行穷举破解。而且因为PPTP不支持PFS（完美前向保密），密钥被爆出来了，之前和之后的通信内容也就全都被解密了。

退一万步来说，即使你的企业不在乎这个安全性，即使你传输的内容就是一些毫无保密需求的东西，比如上班摸鱼看的小说，PPTP也不推荐在今天的环境下使用，原因很简单：PPTP无法穿透没有打开PPTP ALG的NAT（严格来说是NAPT）。这里的NAT包括但不限于员工家里的路由器，员工在饭店吃饭时候的路由器，员工手机热点，以及员工家里宽带ISP的CGNAT。原因很简单：上面也提到了，PPTP依赖IP 47进行通信，这玩意可没有什么端口号给你玩NAPT，所以如果不打开网关的PPTP ALG功能，NAT设备就只能丢弃这些包了，连接自然也就无法建立。

此外还有一个问题：各类设备正在逐渐放弃PPTP。最显然的是，iOS（苹果那个）早就不支持PPTP连接，Android 12开始，PPTP协议就已经从系统VPN协议中移除了，而Windows Server也在不久之前宣布放弃PPTP的入站支持，虽然客户端还支持出站连接（尤其是考虑到社会上还存在大批量跑Win7的设备），但是很显然，PPTP的未来可以说是一片阴暗。

所以，老实说，非常不推荐PPTP，现有的PPTP设施也应该尽快更换。

IPSec

结论：笔者不推荐IKEv1/IPSec来给员工使用

本来的话，按照一般的惯例，PPTP会和L2TP对举，但是为了照顾下文连续性起见，这里先把IPSec提前。

先发个牢骚：如果你问我，『你碰到的混乱名词都有什么』，笔者可以告诉你，IPSec绝对算一个。网上有的说IPSec不安全，有的说IPSec很安全，有的说IPSec不适合，有的说IPSec很适合，甚至可以出现左右脑互搏的情况。更进一步，如果你搜索『为什么IPSec不安全』，下面甚至还会告诉你，『IPSec可能被NSA（美国国家安全局）破解』，但是同为IPSec的IKEv2又安全了，就很？？？

牢骚完了，现在来讲定义。首先你要明白，IPSec不是『一个』协议，而是『一套』协议。此处小标题提到的IPSec，包括你在网上看到的，还分主模式和野蛮模式的IPSec，指的都是使用原版IKE（俗称IKEv1）进行密钥交换的IPSec，可以写作IKEv1/IPsec。v2下面还会提到，现在你只要知道，本节讨论的，以及网上所说的不安全的IPSec，不安全的L2TP/IPSec，指的都是使用IKEv1/IPsec。同样道理，如果没有特别说明，尤其是光秃秃一个IPSec的情况下，默认指的都是使用IKEv1模式的，原版的，IPSec。

IPSec内部分为几个部分，还分为几个模式，还分为....这里不作展开，只介绍基本内容。建立连接的时候，IPSec首先使用IKE在UDP 500（v1和v2都一样）进行链路协商和密钥交换，协商好之后就切换到AH模式（IP 51）或者ESP模式（IP 50）进行实际的数据传输。如果在链路协商过程中发现设备途中有NAT设备，比如你在家宽访问IPSec，那么就不能使用裸IP协议了，而是要切换到UDP 4500进行数据传输（学名叫做NAT-T，同样是v1和v2都一样，严格来说跟IKE没啥关系）。所以如果想要搭建VPN，而且传输过程中涉及到了IPSec，那么需要开放的端口就是500，4500，IP协议号51和50。

现在来讨论为什么笔者不推荐你使用IPSec。首先先说一个很反直觉的事情：IPSec不支持用户名密码鉴权。

是的，你没看错，我再说一遍，IPSec不支持用户名密码鉴权。真正意义上属于IKEv1/IPSec的鉴权方式，通常来说只有三种，PSK（预共享密钥）和RSA证书，和信封认证（别跟我说EAP，那是IKEv2的事情了，IKEv1不支持EAP）。PSK很好理解，就像WiFi密码一样，通过安全方式（比如扔纸条）让各端都知道PSK的值，然后就可以通过PSK来进行认证。如果是RSA，那么就可以通过RSA证书进行认证。信封认证也是差不多，只是具体实现有所差别，因为和本文无关，不再介绍。

但是不论是哪个模式都好，鉴权通过之后就直接连上去了，安全通道就建立起来了，没有任何地方给你输入用户名和密码。换句话说，一旦PSK泄露，或者证书泄露，在移动场景下自然不可能给你做来源IP限制，那么你的VPN能人人都连上来了，系统并不知道哪个是合法用户。

行了行了，我听见你在问了，说什么旧版安卓上的IPSec可以输入用户名密码。但是请你看清楚，安卓上面的不是IPSec，而是IPSec XAuth。多出来一个小尾巴就不同了，XAuth是思科弄出来的一个小玩意，算是给传统IPSec打的一个小补丁，在IKE第一阶段SA协商（这里还是要依赖PSK/RSA的）完成之后加入XAuth认证，从而提高安全性。换句话说，PSK泄露也不会造成太大问题（当然并非完全没有问题，所以为啥要泄露呢？）。这玩意听上去很美好，但是Windows不原生支持，而且新版安卓也抛弃了支持，所以可以直接pass掉。

所以最后可以认为，IKEv1/IPSec没啥毛病（可能安全性会有点问题），但是他就是不适合我们在引言中提到的这个场景。事实上你看现在很多企业搞公网VPN，包括你买什么SD-WAN，都有部分商家可以提供IPSec接入方式，道理是一样的，他作为固定接入确实还行，但是移动接入就不是他的强项了。所以后来还搞了个IKEv2就是类似原因。

L2TP/IPsec

结论：L2TP/IPsec只推荐用于下位替代

终于提到大家熟悉的玩意了。L2TP，也是当年扶墙的好帮手（刚刚那张截图你也能看到L2TP的存在，甚至笔者在2021年仍然尝试过使用L2TP/IPsec去拨位于美国的服务器，拨上了....速度25Mbps....）

首先澄清一下，我们平时说L2TP，主要指的是L2TP/IPsec，而并非没有加密的纯L2TP。下文遵循这一个习惯，特殊之处会有说明。

L2TP，全称L2TP over IKEv1/IPsec，说人话就是，先使用IKEv1/IPsec建立安全通道，且工作在『传输』模式（这也就是为什么你看到的很多L2TP连接信息都会附带PSK，或者有证书，但比较少，这就是给IPsec用的），安全通道跑起来之后，使用L2TP进行鉴权认证，通过之后就建立了二层通道，可以进行进一步操作。这里多说一句，如果你搭建L2TP，千万不要对外暴露UDP 1701，虽然资料说的是L2TP使用1701，但是他说的是『纯L2TP』，无加密那种，才会使用UDP 1701。如果用的是有加密的L2TP/IPsec，只需要开放UDP 500和UDP 4500就行了。

可以用户名密码认证，这就方便员工接入，而且L2TP可以传输二层数据包，但是也就止步于此了：

1. L2TP也开始逐渐被各大客户端放弃
2. 因为是协议套娃，速度有所降低
3. 各端客户端的实现有点区别，可能会影响安全性
4. 服务端配置比较麻烦
5. 和裸IPSec一样，Windows上配置L2TP可能需要修改注册表，打开NAT穿越功能

所以，L2TP/IPSec也只推荐作为下位替代使用了。但如果你问我PPTP和L2TP/IPSec推荐哪个，那当然是后者。

IKEv2/IPSec

结论：推荐度比L2TP高一些，但是也不见得多高

IPSec太灵活了，终于，到了IKEv2/IPSec的年代，各个客户端才达成一致说，哦，我们要支持一个相对比较安全的协议，于是比如说安卓客户端就转而支持使用IKEv2了。然后就没有然后了，各个客户端的实现继续出现差别（尤其是涉及到IPv6的时候）

IKEv2自然就是IKEv1的升级版，端口不变，还是UDP 500和UDP 4500，协商速度更快，支持了EAP（扩展身份验证），还支持了MOBIKE，更加方便客户端连接的场景，而且因为这个升级还不错，所以很多地方干脆直接用IKEv2来指代IKEv2/IPsec，就像用L2TP来指代L2TP/IKEv1/IPsec一样。

IKEv2的好处是，搭配MSCHAPv2之类的协议使用的时候，可以实现用户名密码认证，所以最终配置理论上还行。不过剩下的地方就是短板了

1.各个原生客户端对于IKEv2的实现并不一致，尤其是涉及到加密套件和双栈路由选择的时候，会有bug
2.服务端搭建比较麻烦，就证书一项，可以难倒很多人
3.客户端的分流实现并不同意（你不想员工去用命令行配置路由表的对吧）

如果你有搭建的经验，当然可以用，不过我的建议是不要作为唯一方案使用，可以考虑作为iOS系统的备用连接方式并针对此进行优化（因为，你知道的，iOS很难侧载应用程序，而国区Apple Store在大清洗过后很难找到合适的VPN客户端）

SSL-VPN

终于可以讨论稍微现代化一点点的东西了。

首先需要明白的一点是，SSL-VPN这个名词在很多文档中一直都处于定义混乱的状态。综合各路分析，可以发现以下三种类型：

WebVPN

可以说是原教旨版本的SSL-VPN，学名叫做Clientless VPN，或者更熟悉的名字，WebVPN。因为这玩意很难自行搭建，仅作了解即可

WebVPN本质上还是一种加密网页代理，利用浏览器js配合远端程序劫持并改写所有请求强制走加密网关。优点就是无需特别的客户端，只要有浏览器就行。不过，如果你稍微有一点网页前端开发经验就知道，不过这种WebVPN仅仅适用于比较简单的网页或者特定的应用程序了，因为如果目标网页不合适（例如直接在js里面拼接后端服务器地址），就需要手动对网站进行修补（有说法是你在深信服那边购买了WebVPN之后，他们会派人来跟你对接，免费改几个内部网站，多了，又要收费）。还有很多别的原因，总之一句话就是，一般只适合作为轻量化的访问使用。

如果你想体验下这种感觉，有一些开源项目可以实现类似于WebVPN的效果，比如HideIPNetwork-WEB，你可以尝试一下效果，但是不推荐用于生产环境——人家拿出来卖的WebVPN功能会更丰富，怎么实现的？不告诉你。想用吗？请给钱。

瘦客户端VPN

除了上面提到原教旨版本之外，部分陈年老文档可能还会提到『使用WebVPN需要安装ActiveX控件/安装JAVA Applet』，这里说的其实是SSL-VPN的另一种类型：ThinClient VPN。因为这个ActiveX控件/JAVA Applet名字太长，下面就统一称呼为：控件

额外安装的这个控件，其作用有很多，比如有可能会提供双向证书验证（mTLS），比如可能是作用最大的：提供TCP端口转发服务。我们都知道浏览器无法处理裸TCP业务，而控件作为近乎于在本地原生运行的二进制程序，拥有的权力大很多，其中就包括了在客户端上监听TCP端口，这样就可以让一些依赖裸TCP的C/S业务，比如RDP，SSH，通过浏览器加上SSL层之后发送到远端网关。

不过你有了解过：目前这种类型的VPN已经不多见了，要么就是纯粹的WebVPN，光靠js和远端的程序就能实现改写业务地址；要么就是完整的客户端，在你本地起tun/tap设备，完整地做二三层代理（一般都是三层，毕竟二层吃力不讨好，一般员工也用不上这个东西）。出现这种情况的原因有很多，主要归结起来还是有两个：

• 随着IE浏览器的逐渐没落，ActiveX控件变得不受待见了，况且这玩意可以近乎于用『粗放』二字来形容，安全风险其实不容小觑，所以很多企业都组件放弃
• HTML5让浏览器有了更强的表现能力，js在浏览器的执行速度已经足够快，WebSocket等协议给客户端提供了类似TCP连接的能力，这几样结合起来，就可以光靠浏览器就实现很多功能，比如WebRDP，WebSSH，WebSMB.....反正都是和远端网关连接，转码工作就交给远端网关好了

综上所述，这不是我们今天的选择。

客户端SSL-VPN

欢迎来到现代VPN的世界。

SSTP

结论：不太推荐，但也不是不能用

微软家的SSTP，基于SSL的一种VPN。

用户名密码认证没啥问题，安全性没啥问题，如果你能配置成功的话其实也还无所谓。但是笔者依然不推荐让你去用，原因在于：

1. 只能用TCP模式，某些情况下问题不小（会引起TCP Meltdown的问题）
2. Linux上可用的服务器软件不多，毕竟这是微软主导的东西
3. 无法推送路由，意味着想做分流，还是得让用命令行配置路由表，这就不好
4. 移动端支持不太行

SoftEther

结论：不太推荐，但也不是不能用

SoftEther VPN，简称SE-VPN，日本筑波大学的一个项目（注意和VPNGate项目区分开，严格来说二者并无关系，只是后者利用了SE的协议），同样是基于SSL的VPN协议。这个协议宣称是速度比较快，而且他也支持TCP和UDP模式的切换。

不过笔者还是不作推荐，理由如下：

1. 移动端支持跟没有一样，2025年了，依然没有官方移动端连接程序，第三方程序又难用（信不信由你，他给出的移动端连接方式是OpenVPN或者L2TP）
2. 配置略显麻烦
3. 官网下载版本『好心地』帮位于大陆地区的你禁用了分流功能且无法开启，除非你自己修改源码并编译

OpenVPN

结论：可以，看着用，但最好作为后备方案

OpenVPN应该不用我过多介绍了，著名的开源VPN协议，很长一段时间内为科学上网做出了很大的贡献——当然现在不行了，DPI就可以很轻松地阻断掉——现在很多国内云厂商出售的『VPN网关』里面的SSL-VPN，指的就是OpenVPN

OpenVPN其实也还不错，支持用户名密码认证，还可以在远端推送路由，还可以把自签名的CA证书塞进去配置文件里，不必额外配置（也缩小了作用范围，安全些）。应该说如果你愿意用，其实还是挺好的（好像也有不少企业在用OpenVPN），但是依然存在几个缺点：

1. 慢。普遍反映速度不算是很高，千兆链路跑到180Mbps左右而已
2. 需要下载配置文件，稍微复杂一些
3. iOS客户端可能稍微难搞到客户端一点
4. 配置文件的跨版本兼容性问题。这个真的要吐槽一下，2.4/2.5/2.6三个版本有互不兼容的一些设置项，如果你确定要用OpenVPN，一定要注意这个问题。

具体的搭建教程网上有很多，这里不赘述了。

OpenConnect

结论：用，都可以用，这个是真的好

OpenConnect（下面简称OC）你可能听得少，但是AnyConnect（下面简称AC）你应该会知道是怎么一回事。

AC是思科开发出来的专有的VPN协议，也是基于SSL的，功能很不错，比如远程配置推送，比如TLS 1.3，比如对接其他鉴权源（例如Radius），比如轻配置（和PPTP差不多，只需要地址+用户名密码就可以连接上）。可以说什么都好，唯一缺点就是你得花钱买授权，还得安装硬件网关，毕竟这是思科专有的协议，得用他的机器，买他的授权，才能用。

于是就有一群大神，逆向了AC的协议，开发出来了OC这个软件，可以连接到AC服务器上。后来又基于AC协议做出来了OC协议（主要是扩充了一些认证功能），以及配套的服务器OCServ。笔者猜测，OC连接到OCServ之后，可能通过某些神奇的方式协商并升级到OC协议，实现扩展功能。

OC基本上很符合笔者对于一个面向员工的VPN的需求（甚至可以说深信服EasyConnect，或者说叫EC，就是类似的使用体验），用户只需要输入VPN服务器的地址，再通过用户名密码，或者证书，或者其他的什么Key进行认证，就可以很方便地接入内网，不必操心其他配置，对于小白用户来说是再合适不过了。唯一需要额外安装的可能是自签名的根证书，不过如果你用被信任的证书（例如acme.sh签发的Let's Encrypt或者ZeroSSL证书）则无此问题，非常丝滑。

客户端支持方面也相对较好，OC支持比较多的平台，即使不支持，可能也会有对应的AC客户端（就是需要注意一下可能会有违反思科ToS的风险）

OC唯一的缺点可能还是来自于速度，但是也不太影响：在千兆链路上无特别优化的话，笔者测得大概也就是300Mbps（服务器CPU是i5-6260U）左右，还能接受。

WireGuard

结论：可以，看着用，但最好作为后备方案

笔者一向是WireGuard的支持者，但是在这个话题上，反而不是很想把WireGuard作为首要推荐方案。

诚然，WireGuard代码短小精悍，有Linux内核支持，加解密速度快，安全性高，客户端支持也还不错（甚至众多梯子客户端都提供了对WireGuard的支持，方便无缝集成），但是却有一个很大的问题：鉴权不便。WireGuard同样没有办法做用户名密码认证。

很多人会把WireGuard对标OpenVPN，但是在笔者看来，对标的应该说是IPSec比较合适，本质上他的鉴权方式类似于IPSec中的RSA认证，只不过不是用完整的证书，而是用x25519密钥对，短一些而已。这就引入了同样的问题：需要分发证书，或者说，就针对WireGuard而言，是分发配置文件。并且和OpenVPN不同的是，他没办法做到大家共用配置文件（用用户名密码区分彼此），必须是一个设备（或者说，一个会话）使用一套配置，各分配一个静态IP，如何管理这些配置文件就成了一个问题，如何让员工正确使用这些配置文件也是另一个问题。

至于为什么会出现这样的情况，笔者这边有句话叫做『下层交给上层实现，上层选择不实现』。我不确定当时作者开发时候是怎么确定功能的，目前的情况是，他把公钥分发的工作交给了上层。但问题是上层做到这一点的并不多，而且各家都有自己的私有实现（例如Tailscale就是基于WireGuard的，自己实现了密钥分发和打洞），互操作性几乎为零，不得不认为算是其中的一个缺点。

当然了，结合实际来看，七八十个会话的WireGuard问题还不算很大，生成配置文件的话也可以使用脚本来操作，或者可以选择wg-easy之类的面板来操作。所以如果你需要使用WireGuard，其实也并不是那么难上手。

27楼的WiFi

既然要搭建这样的VPN，而且里面跑的是IP协议，怎么选择属于VPN的内网IP地址段自然是个学问。

长话短说：可以直接看最后一小节，有推荐的地址段

这一节的标题是27楼的WiFi，为啥？下面就告诉你。

RFC1918

稍微有一点网络知识的朋友都知道，我们可以选择RFC1918私有地址段，也就是我们熟悉的10，172.16，192.168网段（具体的掩码位这里就不赘述了）。这个选择不论是理论上还是实际上都是可行的，但是笔者在这里并不推荐。道理很简单，这三个地址段已经在现实生活中被广泛应用了（例如笔者的校园网是10.50.0.0/16，校内实训楼机房用的是172段），如果你在这三个段里面挑地址，很容易碰上地址冲突的问题，导致你在接入这类网络之后无法再访问VPN。

现在可以解释什么是27楼的WiFi了：曾经有位老哥给自己的OpenVPN分配了192.168.27.0/24的网段，结果某次外出的时候，他碰到了酒店27楼的WiFi，正好也就是这个网段。

另外，此时千万不要当大聪明。有些半吊子网络工程师不知道是故意的还是无意的，给内网分配的地址段是类似于192.167.0.0/16，172.0.0.0/8，192.0.0.0/8之类的『伪』内网段，但是如果你查询IP归属地可以发现，位于这些段内的IP很多都是公网IP，已经名花有主，例如192.167.11.22归属于意大利，172.98.11.22归属于美国德州的某个ISP，等等。如果是物理隔绝的内网，那也无可厚非，但是如果你在正常和公网连接的网络上使用这类地址段，那就会出现地址冲突的情况——你当然可以说自己一辈子也不会访问到这些IP地址所对应的网站，但是如果我说，像这样的配置不当有可能会导致内网流量被不小心发往公网，而公网上的那个IP地址有正在监听的项目呢？

RFC6598

下一个候选人是RFC6598，也就是100.64.0.0/10，已知Tailscale在使用这个段。笔者的态度是推荐，但注意冲突。

此网段被用于实现CG-NAT，也就是俗称的宽带大内网。如果你是普通宽带用户，那么上级路由器也有可能会被分配到这个网段；如果你的节点搭建在云上，那么已知部分云服务商也正在使用这个段（比如阿里云OSS内网域名的解析结果就是此段），同样有冲突的可能性。如果你确定要使用的话，不妨在中段偏后的位置进行选择，以降低冲突概率。比如100.98.43.0/24。

DoD网段

接触过某些云服务商的朋友可能知道，国内云服务商，如果你做浮动IP，或者专线接入，一般都会提醒你，不能使用某些IP段，最经典的当属11.0.0.0/8，云服务商给出来的理由是『我们内部也在使用这个IP段，会导致冲突』

很好，那么这个段到底是谁的呢？查询互联网资料不难发现，这个段隶属于美国国防部（DOD）情报信息系统，但是因为一直以来（上世纪九十年代到2021年）这个段都没有在互联网上做路由宣告，几乎就相当于这个地址不存在。与此同时，因为和10.0.0.0/8紧挨着，所以很多地方拿来公网私用。类似这样的/8掩码的段还有：

长期以来的公网不可达，让部分内网地址紧缺的部门开始使用这些网段。不过在2021年左右，美国国防部以AS8003的名义向互联网宣告了这些地址段的路由。这么做既合情又合理，因为这些地址段本来就是他们的，他们拿来干什么都可以。不过这就引起了一个问题：那些本来使用这些地址段作为内网的企业，如果出口端没有做好屏蔽工作，在配置错误的情况下，很可能会发生内部数据外泄的情况。

所以，除非迫不得已，否则不建议使用这些地址段。

240.0.0.0/4

不确定你还记不记得，在那个IPv4还是有类网络的时候，经常会背的是，『A类大型网络，B类中型网络，C类小型网络，D类用于组播，E类保留供将来使用』

有类网络消失之后，『将来使用』的E类网络变成了240.0.0.0/4，不小的一块地址空间了，那么我们能不能拿来作为内网段呢？

很抱歉，不能。虽然E类地址空间非常宽广，而且近些年来的各类操作系统都在有意恢复E类地址的使用（甚至据说亚马逊内网广泛使用E类地址），但是占比最大的电脑系统，Windows，无法给网卡配置E类地址，也无法向E类地址空间发包，这就大大限制了E类地址的未来。

文档/测试段

如果你认真研究过IPv4地址空间，你应该会知道，在正常的单播地址空间内，是有一定的空隙存在的。比如我们查看RFC5737，可以找到以下几个神奇的IP段：

192.0.2.0/24
198.51.100.0/24
203.0.113.0/24

这几个段被指定为文档专用，所以不会在全球网络上进行广播，也不会有别人用，同时因为还在标准单播范围内，各类操作系统和路由器都会接受这样的地址，所以是非常完美的选择。

如果你觉得这几个地址空间不够大，还可以选择RFC2544中提到的测试网段198.18.0.0/15，足足两个B类网段的空间，应该足够使用了。

最后再提一个末位考虑的段：RFC6890中分配的192.0.0.0/24。此段作用不是一句话能说清楚的事情，但是查询分配表来看，似乎里面分配到用途很少有广泛使用的。所以如果你确定自己的网内没有这样的服务，也可以作为考虑之一。

写在最后

内容有点水，不过希望能帮上点忙。

写完这篇文又得回去继续写写小说了，现在两边有点顾不过来。再加上日常上课内容，也许我该给自己放会儿假了。

（完）