5.11 网络安全进阶——OpenVPN / IPSec + DDoS 防护

预计阅读时间：15 分钟

企业内网远程接入和服务器安全防护是运维必备能力。本篇覆盖三大主流 VPN 方案的实战配置，并深入讲解 DDoS 与 SYN Flood 的内核级防御策略。

学习目标

• 能搭建 OpenVPN 服务端，用 easy-rsa 完成 PKI 初始化与客户端证书签发
• 能配置 strongSwan IPSec/L2TP，处理 IKE 协商、NAT 穿越与防火墙放行问题
• 能对比 OpenVPN、IPSec、WireGuard 三种方案在性能、兼容性与适用场景上的差异
• 能通过 iptables 限流、云 WAF/CDN 与内核参数调优构建分层 DDoS 防御
• 理解 SYN Cookies 原理，能通过 sysctl 与 iptables 抵御 SYN Flood 攻击
• 能使用 tcpdump、conntrack 等工具排查 VPN 连通性与连接耗尽故障

前置知识

• 5.10：WireGuard VPN WireGuard VPN——掌握 VPN 隧道原理与中心辐射拓扑，作为方案对比基准
• 5.1：Linux 安全加固 Linux 安全加固——证书与密钥管理、最小权限原则的延伸
• 5.5：防火墙实战 防火墙实战——iptables 限流、NAT 与 conntrack 是 DDoS 防护的基础
• 4.5：网络故障排查 网络故障排查——tcpdump 抓包与端口排查是 VPN 排障的必备技能

1. OpenVPN 配置

服务端安装

# Debian/Ubuntu
sudo apt install openvpn easy-rsa

# 初始化 PKI
cd /usr/share/easy-rsa
./easyrsa init-pki
./easyrsa build-ca nopass
./easyrsa build-server-full server nopass
./easyrsa gen-dh
openvpn --genkey secret ta.key

server.conf 核心配置

# /etc/openvpn/server.conf
port 1194
proto udp
dev tun

ca   /etc/openvpn/pki/ca.crt
cert /etc/openvpn/pki/issued/server.crt
key  /etc/openvpn/pki/private/server.key
dh   /etc/openvpn/pki/dh.pem

# 分配隧道地址段
server 10.8.0.0 255.255.255.0
push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DNS 1.1.1.1"

# 加密与压缩（OpenVPN 2.6+ 已弃用压缩，VORACLE 漏洞后官方不再推荐）
cipher AES-256-GCM
auth SHA256

# 安全加固
tls-version-min 1.2
tls-cipher TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384
tls-auth /etc/openvpn/ta.key 0
keepalive 10 120
max-clients 100
user nobody
group nogroup
persist-key
persist-tun

# 日志
status /var/log/openvpn-status.log
log-append /var/log/openvpn.log
verb 3

证书签发与客户端配置分发

# 为客户端签发证书（生产环境不要用 nopass，私钥加密）
cd /usr/share/easy-rsa
./easyrsa gen-req zhangsan nopass
./easyrsa sign-req client zhangsan

# 吊销客户端（离职/设备丢失）
./easyrsa revoke zhangsan
./easyrsa gen-crl
cp pki/crl.pem /etc/openvpn/crl.pem   # 服务端配置 crl-verify 后生效

# 生成客户端打包文件（证书+私钥+CA 合一，方便分发）
mkdir -p /root/clients/zhangsan && cd /root/clients/zhangsan
cp /usr/share/easy-rsa/pki/ca.crt .
cp /usr/share/easy-rsa/pki/issued/zhangsan.crt .
cp /usr/share/easy-rsa/pki/private/zhangsan.key .
# 用脚本把 .ovpn 模板与三份文件合并，生成单个 zhangsan.ovpn 交付

# per-user 路由：按角色分配访问权限
# 服务端 /etc/openvpn/server.conf 中追加:
#   client-config-dir /etc/openvpn/ccd
#   crl-verify /etc/openvpn/crl.pem
#
# /etc/openvpn/ccd/zhangsan —— 只允许访问内网 10.0.1.0/24
iroute 10.0.1.0 255.255.255.0

客户端 .ovpn 文件

client
dev tun
proto udp
remote your-server.com 1194
resolv-retry infinite
nobind
persist-key
persist-tun

# 内嵌证书（方便分发）
<ca>
-----BEGIN CERTIFICATE-----
...CA 证书内容...
-----END CERTIFICATE-----
</ca>
<cert>
-----BEGIN CERTIFICATE-----
...客户端证书...
-----END CERTIFICATE-----
</cert>
<key>
-----BEGIN PRIVATE KEY-----
...客户端私钥...
-----END PRIVATE KEY-----
</key>

cipher AES-256-GCM
auth SHA256
key-direction 1
remote-cert-tls server
tls-version-min 1.2
verb 3

2. IPSec/L2TP 配置（strongSwan）

安装与基础配置

sudo apt install strongswan strongswan-pki libcharon-extra-plugins

# /etc/ipsec.conf
conn my-vpn
    keyexchange=ikev2
    left=%any
    leftid=@vpn-server
    leftcert=server-cert.pem
    leftsendcert=always
    leftsubnet=0.0.0.0/0
    right=%any
    rightid=%any
    rightauth=eap-mschapv2
    rightsourceip=10.10.10.0/24
    rightdns=1.1.1.1
    rightsendcert=never
    eap_identity=%identity
    auto=add
    dpdaction=clear
    dpddelay=300s
    ike=aes256-sha256-ecp384!
    esp=aes256-sha256!

IPSec secrets 与防火墙

# /etc/ipsec.secrets
: RSA server-private-key.pem
: EAP "vpn-password"

# 启用 IP 转发
echo "net.ipv4.ip_forward=1" >> /etc/sysctl.conf
sysctl -p

# iptables NAT
iptables -t nat -A POSTROUTING -s 10.10.10.0/24 -o eth0 -j MASQUERADE
iptables -A INPUT -p udp --dport 500 -j ACCEPT   # IKE
iptables -A INPUT -p udp --dport 4500 -j ACCEPT   # NAT-T
iptables -A INPUT -p esp -j ACCEPT

站点到站点（Site-to-Site）示例

分支机构与总部之间需要打通内网时，使用 IPSec 隧道而不是远程接入 VPN。两侧各部署一台 strongSwan，两端互为对端，使用预共享密钥或证书认证。以下为总部（10.0.0.0/24）与分支（10.20.0.0/24）互通配置：

# 总部节点 /etc/ipsec.conf
conn branch-tunnel
    type=tunnel
    keyexchange=ikev2
    left=203.0.113.10            # 总部公网 IP
    leftsubnet=10.0.0.0/24       # 总部内网
    leftid=@headquarters
    right=198.51.100.20          # 分支公网 IP
    rightsubnet=10.20.0.0/24     # 分支内网
    rightid=@branch
    authby=secret                # 也可用证书：authby=pubkey
    auto=start
    ikelifetime=24h
    keyingtries=%forever
    dpdaction=restart

# 分支节点 /etc/ipsec.conf（左右互换即可）
conn headquarter-tunnel
    type=tunnel
    keyexchange=ikev2
    left=198.51.100.20
    leftsubnet=10.20.0.0/24
    leftid=@branch
    right=203.0.113.10
    rightsubnet=10.0.0.0/24
    rightid=@headquarters
    authby=secret
    auto=start

# 两侧 /etc/ipsec.secrets 填入同一组 PSK
203.0.113.10 198.51.100.20 : PSK "generate-with-openssl-rand-32"

# 启用并验证隧道
systemctl enable --now strongswan-starter
ipsec statusall            # 看到 ESTABLISHED 且两个 subnet 匹配即成功
ipsec trafficstatus        # 查看隧道内流量字节数

# 分支内网机器 ping 总部内网机器（双向都应通）
ping 10.0.0.5

# 排障：确认 UDP 500/4500 与 ESP 放行、两端策略一致
tcpdump -i eth0 udp port 500 -n

3. WireGuard vs OpenVPN vs IPSec 对比

选型决策流程

按以下顺序逐步缩小范围，避免凭偏好选型：

1. 看客户端生态：是否需要 Windows XP/老设备、Android 原生客户端？WireGuard 与 OpenVPN 均有全平台客户端，IPSec 需要系统自带或第三方客户端
2. 看性能预算：单核软路由或低端 VPS 上需要跑满千兆？WireGuard（内核态）通常比 OpenVPN（用户态）快 2-4 倍，IPSec 居中
3. 看合规要求：金融/政企项目审计要求标准协议时选 IPSec（RFC 标准）；要求可审计的细粒度访问控制时 OpenVPN 的 per-user 路由与 RBAC 更成熟
4. 看运维能力：团队规模小、追求零维护选 WireGuard；需要 Web 管理面板、多因素认证、日志审计选 OpenVPN Access Server 或自建

VPN 性能基准测试

# 使用 iperf3 测试 VPN 吞吐量
# 服务端
iperf3 -s

# 客户端（通过 VPN 隧道）
iperf3 -c vpn-server-ip -P 4 -t 30

# 测试延迟
ping -c 100 vpn-server-ip | tail -3

4. DDoS 防护策略

DDoS 攻击按网络层次可分为三类，防护必须分层部署——越靠上游吸收流量越有效，越靠主机越精准：

防御设计顺序：先用云清洗/CDN 吸收大流量（把攻击挡在数据中心外），再在主机层用 iptables 做细粒度限流，最后靠内核参数提升主机在高压下的存活能力。三层联动，任何单层都扛不住大流量攻击。

iptables 连接限流

# 限制单 IP 并发连接数（SYN 包限流）
iptables -A INPUT -p tcp --syn -m connlimit --connlimit-above 50 -j DROP

# 限制每秒新连接数（防止连接洪泛）
iptables -A INPUT -p tcp --dport 80 -m hashlimit \
    --hashlimit-above 100/sec --hashlimit-burst 200 \
    --hashlimit-mode srcip --hashlimit-name http_limit \
    -j DROP

# ICMP 限速（防 ping flood）
iptables -A INPUT -p icmp --icmp-type echo-request \
    -m limit --limit 10/s --limit-burst 20 -j ACCEPT
iptables -A INPUT -p icmp --icmp-type echo-request -j DROP

# 丢弃无效包
iptables -A INPUT -m state --state INVALID -j DROP

云 WAF + CDN 缓解

# Cloudflare / 阿里云盾 / AWS Shield 基本原理：
# 1. DNS 解析指向 WAF/CDN 的 Anycast IP
# 2. 流量经清洗中心过滤后回源
#
# 关键配置要点：
# - 开启 Under Attack Mode（5 秒盾）
# - 启用 Bot Fight Mode 拦截自动化请求
# - 设置 Rate Limiting 规则（如 /api/* 限 100 req/min）
# - 配置 GeoIP 白名单，仅允许业务区域访问管理后台

内核参数调优

# /etc/sysctl.conf — DDoS 防护相关
net.ipv4.tcp_syncookies=1
net.ipv4.tcp_max_syn_backlog=8192
net.ipv4.tcp_synack_retries=2
net.ipv4.tcp_syn_retries=3
net.core.somaxconn=65535
net.core.netdev_max_backlog=65535

# 减小 FIN/WAIT 超时
net.ipv4.tcp_fin_timeout=10
net.ipv4.tcp_keepalive_time=300

# conntrack 表调优（防全连接耗尽）
net.netfilter.nf_conntrack_max=1048576
net.netfilter.nf_conntrack_tcp_timeout_established=3600
net.netfilter.nf_conntrack_tcp_timeout_time_wait=30

# SYN Flood 防御
net.ipv4.tcp_max_tw_buckets=180000
net.ipv4.tcp_tw_reuse=1

sysctl -p

5. SYN Flood 防御

SYN Cookies 原理

SYN Cookies 在收到 SYN 包时不分配连接内存，而是将连接信息编码到 SYN+ACK 的序列号中。攻击者无法完成三次握手，合法客户端回 ACK 时服务器验证序列号恢复连接，零内存开销抵御 SYN Flood。

# 确认 SYN Cookies 已开启
cat /proc/sys/net/ipv4/tcp_syncookies
# 输出 1 表示启用

# 开启 SYN Cookies
echo 1 > /proc/sys/net/ipv4/tcp_syncookies

conntrack 调优与替代方案

# 查看当前 conntrack 使用情况
conntrack -C
cat /proc/sys/net/netfilter/nf_conntrack_count

# 高并发场景建议关闭 conntrack，改用 raw 表 NOTRACK 跳过连接跟踪
iptables -t raw -A PREROUTING -p tcp --dport 443 -j NOTRACK
iptables -t raw -A OUTPUT -p tcp --sport 443 -j NOTRACK
# 注意：只有 raw 表的 NOTRACK 能跳过 conntrack（ACCEPT 不行），可降低约 30% 的 CPU 开销

# 若必须使用 conntrack，调大 hashsize
echo 65536 > /sys/module/nf_conntrack/parameters/hashsize

iptables 快速 SYN 限流模板

# 新建限流链
iptables -N SYN_FLOOD

# 限制 SYN 包速率：每秒 25 个新连接，突发 50
iptables -A INPUT -p tcp --syn -j SYN_FLOOD
iptables -A SYN_FLOOD -m limit --limit 25/s --limit-burst 50 -j RETURN

# 记录被丢弃的 SYN（便于分析攻击源，必须放在 DROP 之前）
iptables -A SYN_FLOOD -j LOG --log-prefix "SYN-FLOOD: " --log-level 4
iptables -A SYN_FLOOD -j DROP

ufw 版本配置（Ubuntu/Debian）

# ufw 底层仍是 iptables，可通过 before.rules 插入限流链
# /etc/ufw/before.rules —— 在 *filter 段追加
:SYN_FLOOD - [0:0]
-A INPUT -p tcp --syn -j SYN_FLOOD
-A SYN_FLOOD -m limit --limit 25/s --limit-burst 50 -j RETURN
-A SYN_FLOOD -j DROP

# 连接数限制：同一 IP 对 80/443 并发 SYN 超过 30 直接丢弃
-A INPUT -p tcp --syn -m multiport --dports 80,443 \
    -m connlimit --connlimit-above 30 -j DROP

# 重新加载 ufw
ufw reload
ufw status verbose

常见错误

• OpenVPN 客户端连接后无法上网——检查 push "redirect-gateway def1" 是否生效，客户端是否加载了完整 .ovpn 文件；确认服务端 net.ipv4.ip_forward=1 已开启且 iptables NAT 规则正确。
• IPSec 握手超时（IKE 阶段失败）——通常是防火墙未放行 UDP 500/4500 或 ESP 协议，使用 tcpdump -i eth0 udp port 500 抓包确认；IKEv1 与 IKEv2 参数不匹配也会导致协商失败。
• SYN Flood 防护误杀正常流量——connlimit 或 hashlimit 阈值设置过低会导致合法用户被丢弃，应先用 conntrack -L 观察正常连接数基线，再适当放宽阈值并配合白名单。
• conntrack 表满导致新连接被丢弃——出现大量 nf_conntrack: table full, dropping packet 日志时，调大 nf_conntrack_max 并缩短 tcp_timeout_established，高并发场景建议用 raw 表绕过 conntrack。
• WireGuard 对端不通但 OpenVPN 正常——检查 UDP 51820 端口是否放行、wg show 确认握手状态（latest handshake 不为空说明已通）、MTU 是否过高导致分片丢失。

最佳实践

• 证书与密钥管理——OpenVPN 的 PKI 根密钥和 IPSec 的私钥应存放在加密存储或 Vault 中，定期轮换；使用 tls-auth 或 tls-crypt 增加控制通道 HMAC 保护。
• 分层防御 DDoS——边界用云 WAF/CDN 吸收流量，主机层用 iptables 限流，内核层调优 SYN Cookies 和 conntrack 参数，三层协同才能有效应对大规模攻击。
• 最小权限原则——VPN 用户按角色分配子网访问权限，用 client-config-dir 实现 per-user 路由推送；iptables 规则只放行必要端口，默认策略设为 DROP。
• 日志与监控——开启 OpenVPN 的 verb 3 和 IPSec 的 charon { filelog { ... } }，配合 ELK 或 Loki 收集日志；用 Prometheus + Grafana 监控连接数、丢包率和 SYN Flood 告警。
• 测试与回滚——任何防火墙或 VPN 配置变更前备份当前规则（iptables-save > /tmp/rules.bak），在测试环境验证后再上线，确保有快速回滚方案。

故障排查案例：OpenVPN 连接后 DNS 泄漏

现象：用户连接 OpenVPN 后，curl ifconfig.me 显示 VPN 出口 IP，但 nslookup example.com 使用的是本地 ISP 的 DNS 服务器，存在 DNS 泄漏。

排查：检查客户端 .ovpn 文件中的 push "dhcp-option DNS ..." 配置，确认服务端推送了正确的 DNS；检查客户端网络适配器属性，发现 IPv6 DNS 未被覆盖。

根因：OpenVPN 默认只覆盖 IPv4 DNS，IPv6 仍使用本地 ISP 的 DNS 服务器。DNS 查询通过 IPv6 直接发送到 ISP，绕过了 VPN 隧道。

修复：① 服务端 server.conf 中添加 push "dhcp-option DNS6 2001:4860:4860::8888"（Google DNS IPv6）；② 客户端 .ovpn 中添加 redirect-gateway def1 ipv6 强制 IPv6 流量也走 VPN；③ 或在客户端禁用 IPv6：sysctl -w net.ipv6.conf.all.disable_ipv6=1。

# 验证 DNS 是否泄漏（应显示 VPN 出口的 DNS 服务器）
dig example.com @8.8.8.8 +short
dig example.com AAAA +short

# 使用 dnsleaktest.com 或 ipleak.net 在线验证
# 客户端 .ovpn 中强制所有 DNS 走 VPN
push "dhcp-option DNS 10.8.0.1"
push "dhcp-option DNS 1.1.1.1"
push "block-outside-dns"           # 阻止绕过 VPN 的 DNS 查询

DDoS 防护分层架构

第一层：云清洗（吸收大流量）
  ├── Cloudflare / 阿里云盾 / AWS Shield
  ├── Anycast 分布式清洗中心
  └── 吸收 90% 的攻击流量

第二层：主机层限流（精细控制）
  ├── iptables / nftables 限流
  ├── SYN Cookies + conntrack 调优
  └── 吸收剩余 10% 的攻击流量

第三层：应用层防护（业务级）
  ├── WAF（ModSecurity / 云 WAF）
  ├── Rate Limiting（应用层）
  └── CAPTCHA / JS Challenge

VPN 客户端常见问题速查

练习题

1. 在测试服务器上搭建 OpenVPN 服务端，生成客户端证书，配置 redirect-gateway 实现全流量转发，并用 curl ifconfig.me 验证出口 IP 已变更。
2. 编写 iptables 脚本，实现 SYN Flood 防护：开启 SYN Cookies、配置 SYN 限流链（每秒 25 包）、conntrack 参数调优，并用 hping3 --flood 模拟攻击验证效果。
3. 对比 WireGuard 与 OpenVPN 在相同硬件上的吞吐量（用 iperf3 测试），记录两者在 CPU 占用和延迟上的差异，形成简单对比报告。

学习检查点

学完本章后，请检验自己是否掌握以下内容：

本章总结

VPN 选型没有银弹：OpenVPN 兼容性最好、IPSec 是行业标准、WireGuard 性能最优，应按接入规模与安全要求取舍。DDoS 防护同样需要分层协作——云 WAF/CDN 吸收大流量、iptables 主机限流、内核 SYN Cookies 与 conntrack 调优兜底，任何单层方案都无法独立应对大规模攻击。所有配置变更都应可观测、可回滚。

延伸阅读