远程办公已经从可选项变成了许多团队的日常，员工在家里、酒店或者客户现场访问公司内网资源时，一条加密的VPN隧道是基本前提。在众多自建方案里，L2TP over IPsec因为客户端支持广泛、配置相对简单，一直是企业远程接入的主流选择之一。这里的R指的是Red Hat系Linux发行版，包括RHEL、CentOS Stream、Rocky Linux以及AlmaLinux等，它们共享同一套软件仓库体系和系统管理方式。本文将在一台R系服务器上，用strongSwan负责IPsec加密、xl2tpd负责二层隧道，完整搭建一条可供远程办公使用的L2TP VPN，并覆盖内核参数、防火墙、用户认证以及客户端排查等关键环节。
一、为什么L2TP必须搭配IPsec：先弄清协议分工
不少初学者容易把L2TP误解成一种自带加密的VPN协议，实际上它只做一件事：把二层帧封装进UDP报文，在公网上打出一条隧道。L2TP本身没有任何加密和完整性保护，数据明文穿越互联网，等于把内网流量裸奔给沿途所有设备看。所以在工程实践里，L2TP从来不会单独部署，而是运行在IPsec之上，由IPsec的ESP协议提供加密、认证和防重放能力，这套组合就是常说的L2TP over IPsec。
两者的分工可以这样理解：IPsec工作在传输模式，先在客户端与服务器之间建立一条加密通道，L2TP的控制报文和数据报文全部被塞进这条通道里传输。L2TP使用UDP 1701端口，IKE协商使用UDP 500，NAT场景下还会用到UDP 4500。这种分层设计的好处是职责清晰——隧道封装与加密解耦，任何一层出问题都可以独立定位，比如以后想把L2TP换成别的隧道协议，IPsec这一层基本不用动。
和同类方案对比一下更直观。PPTP因为MPPE加密强度太低、握手过程可被离线破解，早已被各大厂商默认禁用；OpenVPN和WireGuard功能强大，但客户端需要额外安装软件；L2TP over IPsec的最大优势是Windows、macOS、iOS、Android全部原生支持，员工不需要装任何客户端，填上服务器地址和密钥就能连，这对非技术背景的远程办公人员非常友好。它的缺点是双层封装带来一定性能开销，且默认的IKEv1协商在穿透严格NAT时偶发兼容性问题，这些在后面的配置中都会给出应对办法。
二、服务端环境准备与内核参数调整
假设服务器有一块公网网卡，系统为RHEL及其衍生版本。整个方案需要两个软件包：strongSwan提供IPsec实现，xl2tpd提供L2TP隧道和PPP会话管理。这两个包都在EPEL仓库里，先启用仓库再安装：
# 安装EPEL仓库 dnf install -y epel-release # 安装strongSwan与xl2tpd dnf install -y strongswan xl2tpd # 设为开机自启并立即启动 systemctl enable --now strongswan-starter xl2tpd # 部分旧版本的服务名为ipsec，可用systemctl list-unit-files确认
接着调整内核参数。VPN网关的核心职责是转发数据包，必须打开IP转发；同时为了配合NAT并避免多路径干扰，需要关闭重定向接受、放宽反向路径过滤。编辑/etc/sysctl.d/99-vpn.conf：
net.ipv4.ip_forward = 1 net.ipv4.conf.all.accept_redirects = 0 net.ipv4.conf.all.send_redirects = 0 net.ipv4.conf.all.rp_filter = 0 net.ipv4.conf.default.rp_filter = 0
写入后执行sysctl --system让参数生效。这里要特别提醒rp_filter这一项：不少教程会把它设成严格模式，结果客户端能完成握手却打不开网页，原因就是严格反向路径校验把从隧道进来的、源地址属于虚拟网段的回程包全部丢弃了。遇到类似症状时，优先检查这个参数。
防火墙方面，需要放行相关UDP端口并开启地址伪装。以firewalld为例：
firewall-cmd --permanent --add-service=ipsec firewall-cmd --permanent --add-port=1701/udp firewall-cmd --permanent --add-masquerade firewall-cmd --reload
add-service=ipsec一次性放行了500和4500两个IKE端口，1701是L2TP本身的监听端口，masquerade则让分配给客户端的虚拟地址能够借助服务器公网地址访问外部网络。如果服务器前面还有硬件防火墙或云平台安全组，记得同样放行这三个UDP端口，任何一处没开，客户端都会卡在协商阶段。
三、配置strongSwan：IPsec层的密钥与连接定义
strongSwan的主配置文件是/etc/ipsec.conf。L2TP over IPsec场景下推荐用IKEv1加预共享密钥的组合，兼容性最好，各类原生客户端都能识别。核心配置如下：
config setup
uniqueids=no
conn L2TP-PSK
keyexchange=ikev1
authby=secret
left=%defaultroute
leftprotoport=17/1701
right=%any
rightprotoport=17/%any
auto=add
ike=aes256-sha1-modp1024,aes128-sha1-modp1024,3des-sha1-modp1024
esp=aes256-sha1,aes128-sha1,3des-sha1
forceencaps=yes
逐项解释几个关键参数。left代表服务器一侧，%defaultroute表示自动使用默认路由对应的网卡和地址；right=%any表示接受任意来源的客户端。leftprotoport=17/1701限定这条连接只保护L2TP流量，其中17是UDP的协议号。ike和esp两行定义了协商算法列表，客户端会从中挑选一个双方都支持的组合，把兼容性较好的几种都列上可以明显减少协商失败的情况。forceencaps=yes强制使用UDP 4500封装，也就是NAT-T，无论中间有没有NAT设备都走这个端口，能规避大量NAT兼容性问题。
预共享密钥写在/etc/ipsec.secrets里，格式如下：
%any %any : PSK "这里替换成你自己的强随机密钥"
密钥务必用长随机字符串，可以用openssl rand -base64 24生成，切忌使用公司名、域名这类可猜测的弱密钥，因为攻击者完全可以拿着字典对IKEv1握手数据做离线暴力尝试。配置完成后重启服务并观察日志：
systemctl restart strongswan-starter strongswan status # 实时查看协商日志，排查问题时非常有用 journalctl -u strongswan-starter -f
四、配置xl2tpd：地址池、PPP参数与用户认证
IPsec通道建好之后，轮到xl2tpd在通道里跑隧道和PPP会话。编辑/etc/xl2tpd/xl2tpd.conf：
[global] listen-addr = 服务器公网IP port = 1701 [lns default] ip range = 10.10.10.10-10.10.10.100 local ip = 10.10.10.1 require authentication = yes pppoptfile = /etc/ppp/options.xl2tpd length bit = yes
ip range是分配给客户端的虚拟地址池，local ip是服务器在隧道内的地址，这个网段不要与服务器所在局域网重叠，否则会出现路由冲突。pppoptfile指向PPP链路的参数文件，接下来创建/etc/ppp/options.xl2tpd：
name l2tpd require-mschap-v2 refuse-pap refuse-chap refuse-mschap noccp noauth idle 1800 mtu 1410 mru 1410 defaultroute ms-dns 223.5.5.5 ms-dns 119.29.29.29
认证方式只保留MS-CHAPv2并明确拒绝PAP、CHAP等弱协议，这是Windows等原生客户端与xl2tpd之间兼容性最好的组合。name l2tpd这一行定义了PPP侧的服务器名，与后面账号文件里的服务列要对应起来。mtu和mru设为1410是为了给双层封装留出头部空间，沿用默认的1500会造成大包分片甚至网页加载异常。ms-dns是下发给客户端的DNS服务器，远程办公场景里如果内网有自己的域名解析服务，把内网DNS填在这里，员工连上后就能直接用域名访问内部系统。
最后在/etc/ppp/chap-secrets里添加账号，格式是用户名、服务名、密码、允许的来源地址：
# client server secret IP addresses zhangsan l2tpd 一个足够复杂的密码 *
server列填l2tpd，与options.xl2tpd里的name保持一致；末尾的星号表示允许任意地址登录。重启xl2tpd后服务端就全部就绪了。密码同样要避免弱口令，因为MS-CHAPv2的历史实现存在已知弱点，强口令是最后一道有效防线。
五、客户端连接与故障排查
以Windows为例，在网络设置里新建VPN连接，类型选择使用预共享密钥的L2TP/IPsec，填入服务器地址、密钥和chap-secrets里的账号密码即可。如果客户端本身也在NAT后面（家庭宽带几乎都是），连接报错809，需要调整注册表开启NAT穿越支持：定位到HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PolicyAgent，新建名为AssumeUDPEncapsulationContextOnSendRule的DWORD值并设为2，重启电脑后生效。macOS和手机端一般无需额外处理，填好信息就能连。
连不上的时候按链路顺序排查效率最高。先用tcpdump在服务器上抓UDP 500和4500的包，判断IKE协商报文有没有到达服务器：完全没包说明是网络或防火墙问题；有包但协商失败再看strongswan日志，最常见的原因是密钥不一致和算法不匹配。协商成功却上不了网，则重点检查前面提到的rp_filter、ip_forward和masquerade三项。整理成一张速查表：
| 故障现象 | 最可能的原因 | 处理方向 |
|---|---|---|
| 提示无法连接服务器 | UDP 500或4500被拦截 | 检查云安全组与firewalld规则 |
| 错误代码809 | 客户端侧NAT穿越受限 | 修改注册表或确认forceencaps配置 |
| 卡在协商阶段 | 预共享密钥或算法不匹配 | 核对ipsec.secrets与ike算法列表 |
| 提示验证失败 | 账号密码或服务名填错 | 核对chap-secrets与name字段 |
| 能连接但无法上网 | 转发或NAT配置缺失 | 检查ip_forward、rp_filter、masquerade |
如果想让这套服务长期稳定运行，还有几件事值得做：把预共享密钥升级成数字证书认证，从根本上抵御字典攻击；在防火墙层面限制500端口的来源IP段，减少无意义的扫描噪音；定期归档strongswan与xl2tpd日志，关注异常时段的失败尝试。整套配置的工作量并不大，但每一项都直接决定这条远程办公通道的安全性和可用性，建议在正式上线前逐条确认。