让 Linux VPN 客户端匹配老设备的协议

四类协议几乎覆盖了仍留在机架上的所有设备，而每一类在 Linux 上的失败方式都不同。决定你该装哪个包的是远端公开的端口和已配置的提议，而不是你碰巧在跑的那个发行版。照着论坛帖子装上，再改到某样东西能连上为止，一个下午就是这么没的。先读设备，再装第二，最后验证第三。

记录远端公开了什么

在打开包管理器之前，写清设备期望的协议、端口和认证方式。四类协议覆盖了大多数老设备，下面这张表就是一屏之内的全部决定。

设备手册和它自己的防火墙规则，比登录页上写的协议名更可信。宣称支持 IPsec 的设备也许只会说 IKEv1，而没人刷过的固件版本才可能是最终加上 IKEv2 的那个。数据和配置端口都要确认，老设备与现代网络的差异恰在这里。这一步弄错，就等于拿客户端去调试对端从未具备的功能。

PPTP：改 pppd 之前先证明 GRE

Linux 上的 PPTP 不是你去启动的守护进程，而是一次 pppd 调用，连接参数放在一个具名的 peer 文件里，pppd 被调用时读它。发行版仍在打包它，但协议已知的弱点让它不适合任何敏感用途，所以只把它严格留给别无他法的设备。客户端协商时注意观察 GRE，用一次短抓包而不是靠猜。最耗时间的失败不是认证，而是缺失的数据通路。

pppd call branch-office
tcpdump -ni any proto gre -c 5

如果配置完成而链路从不承载流量，那就在动凭据之前先怀疑 GRE 通路。云安全组需要为协议 47 显式放行，有些网络则在不报错的情况下把它整条挡掉。要在你真正会用的网络里测，而不是在一台什么都放行的实验机里测。

L2TP/IPsec：一个对得上的提议胜过十次尝试

读守护进程日志，而不是桌面对话框，因为对话框会把几种不同的失败并成一条消息。NO_PROPOSAL_CHOSEN 错误属于第一阶段：客户端提出的加密、哈希或 Diffie-Hellman 组服务器不接受。列出设备支持什么，写一条对得上的提议，因为随机组合往往只是把同一个错误出得更慢。桌面上实用的客户端是 NetworkManager 的 L2TP 插件，底层用 strongSwan 或 Libreswan。

一条提议字符串对桌面插件是一种含义，对真正接手工作的守护进程可能是另一种含义，所以要按你正在编辑的层次保持语法。如果设备还要求隧道密钥，那是与 IPsec 密钥分开的一段。往界面里输入任何东西之前，先确认它问的是哪一个。

带 XAuth 的主动模式 IKEv1，以及门户的情形

FortiGate 风格的端点通常要的是带 XAuth 的主动模式加配置模式地址，而图形插件可能根本不提供。原生守护进程能处理，下面这段是那种配置的形态，不是完整文件。提议取值请查厂商当前文档。

conn branch
    keyexchange=ikev1
    aggressive=yes
    leftauth=psk
    leftauth2=xauth
    leftsourceip=%config
    right=203.0.113.10

较老的 strongSwan 版本在版本 5 用 leftauth2=xauth 的地方用 xauth=client，所以照抄的片段可能仅因语法就失败。对 TLS 门户来说，说 AnyConnect 协议的 openconnect 能应付 Cisco 和大多数换牌产品，它需要一块 TUN 设备以及配置它的权限。门户地址要照浏览器显示的原文传进去，包括设备期望的任何路径，然后在测试其后的任何东西之前先核对分配到的地址。提前建好接口能少一类配置时的意外。

sudo ip tuntap add dev tun0 mode tun
sudo openconnect --protocol=anyconnect vpn.example.com

连上，然后按固定顺序验证

一次只跑一个 VPN 管理器，因为 NetworkManager 配置和手动启动的守护进程会争夺路由和 DNS。测手动连接前先把配置停掉，确认没有残留的旧隧道接口。然后按这个顺序验证：隧道地址、到唯一那台内网主机的路由、域名解析，最后是一次真实请求。绿灯只证明认证，别的什么也证明不了。

ip -4 addr show tun0
ip route get 10.20.30.10
getent hosts app.internal

任何一步失败就停在那里，而不是去测下一步，因为路由断了之后的 DNS 失败什么也教不了你。实验之前先把能用的配置存一份，因为删掉的连接文件很容易丢，重建却很麻烦。把提议取值和设备型号、固件版本记在同一条笔记里，因为换机时这条笔记就是迁移与考古的区别。