我在服务器和客户端配置中都设置了：
cipher none
auth none
下列的这个建议我也在使用 UDP 端口 1195。
当我启动服务器和客户端时收到以下警告：
Tue Dec 4 12:58:25 2018 ******* WARNING *******: '--cipher none' was specified. This means NO encryption will be performed and tunnelled data WILL be transmitted in clear text over the network! PLEASE DO RECONSIDER THIS SETTING!
Tue Dec 4 12:58:25 2018 ******* WARNING *******: '--auth none' was specified. This means no authentication will be performed on received packets, meaning you CANNOT trust that the data received by the remote side have NOT been manipulated. PLEASE DO RECONSIDER THIS SETTING!
...这很好，但 openvpn 仍在使用加密。我知道这一点，因为：
1）当客户端连接时，我在服务器端收到以下消息：
Tue Dec 4 12:59:59 2018 client_abc/10.20.73.2:36752 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Tue Dec 4 12:59:59 2018 client_abc/10.20.73.2:36752 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
2）我的两边 CPU 负载都很大
3）我在 Wireshark 中看到数据已加密
禁用加密还需要什么？
答案1
您似乎已启用可协商加密参数 (NCP)。您应该指定
ncp-disable
禁用“可协商加密参数”。这将完全禁用密码协商。
当两个 OpenVPN 实例启用 NCP（最新版本的默认设置）时，它们将协商使用由 ncp-ciphers 定义的一组密码中的哪个密码。默认设置是“AES-256-GCM:AES-128-GCM”，这解释了为什么您在连接上看到 AES-256-GCM。
答案2
假设你正在运行 openvpn 2.4 我相信你还需要设置
ncp-禁用
https://openvpn.net/community-resources/reference-manual-for-openvpn-2-4/
背景信息：
Openvpn 过去要求您在两端手动将加密算法配置为相同的值。然而，这带来了一个问题，它使得在现有的多用户 VPN 上升级加密变得非常困难。2016 年，一种名为“sweet32”的攻击被发明出来，在某些情况下允许恢复明文。在实践中，这并不是一种容易实现的攻击，而且有一种方法可以在不改变密码的情况下缓解它，但这仍然是一个令人担忧的发展。
Openvpn 2.4 引入了一项新功能，默认情况下启用该功能以协商加密参数。我不确定这是对 sweet32 的反应，还是对被有效锁定在单个密码套件中的影响的普遍担忧的结果。
因此，当启用加密参数协商时，如果连接的另一侧不支持协商，“密码”设置实际上可以作为后备使用。