L2TP 是什么
L2TP 在两端之间建立二层隧道，本身提供封装但不提供加密，控制与数据报文都用 UDP 1701。因此生产中的 L2TP 全部与 IPsec 组合使用：IKE 协商走 UDP 500，NAT 穿越走 UDP 4500，数据封装由 ESP 承载。Windows 与多数防火墙的“L2TP/IPsec”预设会同时涉及这几个端口，只放行其中一部分就会卡在隧道建立阶段。
基本信息
| 服务 | L2TP（Layer 2 Tunneling Protocol） |
|---|---|
| 协议 | UDP 1701 |
| 配套端口 | UDP 500（IKE）、UDP 4500（NAT-T）、IP 协议号 50（ESP） |
| 适用平台 | Windows、Linux（xl2tpd + strongSwan/libreswan）、主流防火墙 |
| 安全等级 | 必须由 IPsec 保护，不可裸用 |
典型使用场景
- 远程接入：客户端拨号进入内网，获得内网地址后访问业务系统
- 站点互联：分支与总部之间建立常连隧道
- 过渡方案：老设备只支持 L2TP/IPsec 时沿用，同时规划迁移
- 排障：客户端卡在验证阶段时，从 1701/500/4500 的抓包定位断点
- 合规检查：确认隧道已启用加密，未出现裸 L2TP 或降级协商
抓包确认交互
抓包确认交互
sudo tcpdump -ni eth0 '(udp port 1701 or udp port 500 or udp port 4500)' -c 50
sudo ipsec statusall # strongSwan/libreswan 看隧道状态
sudo tail -f /var/log/syslog | grep -i l2tp
ss -lunp | grep 1701 # 服务端是否监听服务端放行与验证清单
服务端放行与验证清单
1) 确认 UDP 500、UDP 4500 与 ESP（IP 协议号 50）均已放行
2) NAT 场景启用 NAT-T，核对穿越状态
3) 两端 PSK 或证书链一致，IKE 版本与加密套件匹配
4) 用 tcpdump 同步观察 1701/500/4500 的交互顺序客户端排障入口
| 现象 | 常见原因 | 处置方向 |
|---|---|---|
| 卡在验证用户名密码 | UDP 4500 未放行或 NAT-T 未生效 | 放行 4500，核对 NAT 穿越 |
| 报 789/809 类错误 | PSK 不一致或证书链问题 | 核对两端预共享密钥与证书 |
| 能连上但访问不了内网 | 地址池或路由未下发 | 检查服务端地址池与推送路由 |
| 连接频繁掉线 | 链路切换或空闲超时 | 调整 DPD 与空闲超时，评估 IKEv2 |
原生 L2TP 不加密，必须与 IPsec 组合；NAT 环境需启用 NAT-T（UDP 4500），只放行 1701 会导致隧道建立失败。
与 IKEv2 的取舍：L2TP/IPsec 在移动网络切换（Wi-Fi 与蜂窝互切）时常掉线重连，IKEv2 的 MOBIKE 支持会话迁移；漫游场景多时可评估迁移到 IKEv2 或其它现代方案。
端口分工再明确一次：1701 承载 L2TP 的隧道报文，加密由 IPsec 负责；排障时把 1701 与 500、4500 分开看，能快速判断问题出在隧道本身还是加密协商阶段。
巡检与加固要点
- 隧道两端的加密套件与 IKE 版本保持一致，避免协商降级
- 账号与地址池按业务分组，接入后限制可访问的内网网段
- 定期核对预共享密钥是否需要轮换，优先改用证书认证
- 保留连接与断开日志，便于识别异常频繁拨号