VPN隧道和IPsec

1）为什么IPsec以及何时合适

• Site-to-Site: on-prem ↔ cloud, cloud ↔ cloud, DC ↔ DC.
• Client VPN： admin access, jump-host, break-glass。
• Backhaul/Transit: хабы и spoke-VPC/VNet (hub-and-spoke).
• 当需要标准，互操作性堆栈，硬件加速（AES-NI/DPDK/ASIC），严格的密码政策和网络硬件兼容性时，IPsec是合适的。

2）基本概念（快速摘要）

IKEv2（第一阶段）-参数匹配/身份验证（RSA/ECDSA/PSK），创建IKE SA。
IPsec ESP（第二阶段）是流量加密，即儿童SA（针对特定前缀/接口的SA）。
PFS是每个SA儿童的ephemerality（Diffie-Hellman组）。
如果路径上有NAT，则NAT-T（UDP/4500）是ESP封装。
DPD-Dead Peer Detection，是损坏的SA的替代品。
Rekey/Reauth-将密钥更新到期（终身/字节）。

• IKE："AES-256-GCM"或"AES-256-CBC+SHA-256"，DH "gr 14/19/20 oup"（2048位MODP或ECP）。
• ESP："AES-GCM-256"（AEAD），PFS由相同的组组成。
• Lifetimes： IKE 8-24小时,儿童30-60分钟或流量量（如1-4GB）。

3）拓扑和隧道类型

3.1路线（优先）

两侧的虚拟接口（VTI）；路由/动态协议（BGP/OSPF）带有前缀。更容易缩放和细分，更适合于覆盖CIDR（使用NAT策略）。

3.2基于策略的（流量选择器）

SA中的"istochnik↔naznacheniye"列表。适用于没有动态路由的简单S2S；多个前缀更难。

3.3 GRE-over-IPsec / VXLAN-over-IPsec

封装L3/L2加密通道顶部：多协议书，方便使用BGP（携带keepalive）以及在underlay 需要多种等级/ESMR的情况。

4）分段、路由和容错能力

VTI/GRE之上的BGP：前缀交换，优先级为MED/LocalPref/communities，最大优先级保护。
ECMP/Active-Active：一对并行隧道（不同的提供商/ROR）。
Active-Passive：具有更高AD/LocalPref的备用隧道,DPD加快了切换速度。
分裂隧道：仅通过VPN提供企业前缀；Internet-本地（减少延迟/成本）。
相交的CIDR：边缘或代理子网上的NAT策略，如果可能的话，是地址重新设计。

5） MTU、MSS和性能

IPsec/NAT-T超头：每个数据包− ~ 60-80字节。将MTU 1436-1460放置VTI/隧道。
MSS-clamp：对于TCP,显示"MSS=1350-1380"（依赖于underlay）以排除碎片。
启用PMTUD并编写"Fragmentation Needed" ICMP。
硬件离载/快速路径（DPDK，AES-NI，ASIC）大大减轻了CPU的负载。

6）密钥的可靠性和安全性

PFS是强制性的；Rekey在70-80%终身到期之前。
身份验证：如果可能的话，ECDSA认证来自企业CA（或Cloud-CA），PSK仅是暂时的，并且具有高熵。
CRL/OCSP或证书期限短。
重复失败的IKE中的身份验证日志和Alerta。

7）云和提供商的功能

AWS: AWS Managed VPN (policy-based/route-based), TGW (Transit Gateway), VGW/CGW.对于Perfomance/Scale-Direct Connect+IPsec作为备份。

GCP: Cloud VPN (Classic/HA), Cloud Router (BGP);для throughput — Interconnect.

Azure：VPN网关（基于政策/路线），VNet-to-VNet，ExpressRoute用于L2/L3私有化。
Private Endpoints/Privatelink：通往PaaS的流量最好通过私有接口而不是NAT egress。

8） Kubernetes和服务-mesh

Nods K8s私人网络中；Pod CIDR不应"爬行"到远程站点-路由Node CIDR并通过ingress/egress网关滚动服务。
在IPsec之上的Istio/Linkerd mTLS是独立的信任域。
Egress控制：禁止直接从pod到Internet（NetworkPolicy），权限为VTI/VPN。

9）监控和日志

Tunnel-SLA：latency，jitter，packet loss，up/down SA状态。
BGP：邻里、前缀、翻转计数器。
IKE/ESP Logs：真实，rekey，DPD事件。
出口到Prometheus（通过snmp_exporter/telegraf)，在churn SA上变异和RTT/PLR降解。
应用程序跟踪器/logs标记"site=onprem 'cloud"，"vpn=tunnel-X"以进行关联。

10） Trablshuting（支票单）

1.火球：允许在路径上UDP/500，UDP/4500，协议50（ESP）（或在NAT-T下仅允许4,500）。
2.时钟/NTP是同步的-否则,由于计时/证书,IKE会下降。
3.IKE/ESP参数相同：密码，DH，lifetimes，选择器。
4.如果有NAT，则启用NAT-T。
5.DPD和rekey：不太激进,也不懒惰（DPD 10-15s, rekey ~ 70%终身）。
6.MTU/MSS：夹住MSS,检查ICMP "need fragmentation"。
7.BGP：过滤器/communities/AS-path，是否没有"blackhole"，因为下一跳的错误。

8.Logi： IKE SA established?Child SA created?SPI会改变吗？是否存在替换错误?

11）Configi（裁判员缩短了）

11.1 strongSwan (route-based VTI + IKEv2)

ini
/etc/ipsec. conf conn s2s keyexchange=ikev2 auto=start left=%defaultroute leftid=@onprem. example leftsubnet=0. 0. 0. 0/0 leftauth=pubkey leftcert=onprem. crt right=203. 0. 113. 10 rightid=@cloud. example rightsubnet=0. 0. 0. 0/0 rightauth=pubkey ike=aes256gcm16-prfsha256-ecp256!
esp=aes256gcm16-ecp256!
dpdaction=restart dpddelay=15s ikelifetime=12h lifetime=45m installpolicy=no      # route-based через VTI

VTI (Linux):

bash ip tunnel add vti0 local 198. 51. 100. 10 remote 203. 0. 113. 10 mode vti ip link set vti0 up mtu 1436 ip addr add 169. 254. 10. 1/30 dev vti0 ip route add 10. 20. 0. 0/16 dev vti0

11.2 VyOS （VTI之上的BGP, MSS clamp）

bash set interfaces vti vti0 address '169. 254. 10. 1/30'
set interfaces vti vti0 mtu '1436'
set protocols bgp 65010 neighbor 169. 254. 10. 2 remote-as '65020'
set protocols bgp 65010 neighbor 169. 254. 10. 2 timers holdtime '9'
set firewall options mss-clamp interface-type 'all'
set firewall options mss-clamp mss '1360'

11.3 Cisco IOS (IKEv2/IPsec profile)

cisco crypto ikev2 proposal P1 encryption aes-gcm-256 integrity null group 19
!
crypto ikev2 policy P1 proposal P1
!
crypto ikev2 keyring KR peer CLOUD address 203. 0. 113. 10 pre-shared-key very-long-psk
!
crypto ikev2 profile IKEV2-PROF match address local 198. 51. 100. 10 authentication local pre-share authentication remote pre-share keyring local KR
!
crypto ipsec transform-set ESP-GCM esp-gcm 256 mode transport
!
crypto ipsec profile IPSEC-PROF set transform-set ESP-GCM set ikev2-profile IKEV2-PROF
!
interface Tunnel10 ip address 169. 254. 10. 1 255. 255. 255. 252 tunnel source 198. 51. 100. 10 tunnel destination 203. 0. 113. 10 tunnel protection ipsec profile IPSEC-PROF ip tcp adjust-mss 1360

12）政策与合规性

密码加密和允许的密码列表是集中的（安全基础）。
带提醒和自动化的钥匙/耳环旋转。
不变存储（WORM/Object Lock）中的IKE/IPsec审核日志。
分割：用于prod/stage/dev和卡路径（PCI DSS）的VRF/VR域。

13） iGaming/财务细节

数据驻留：带有PII/支付事件的流量仅在允许的司法管辖区（通过VRF/标签路由）内通过IPsec。
PSP/KYC：如果访问给出了私有连接-使用；否则-具有mTLS/HMAC，allowlist FQDN的egress代理。
事务日志：通过IPsec/Privatelink并行记录（在前端和云中）；不变的逻辑。
SLO"金钱之路"：具有优先级和增强监控的单独隧道/路线。

14）反模式

永远的PSK，一个"共享"秘密短语。
基于策略且具有多个前缀的是"地狱管理员"（优于VTI+BGP）。
忽视MTU/MSS →碎片化，隐藏的时间表，3xx/5xx"无缘无故"。
一条没有储备的隧道；一个供应商。
缺少NTP/时钟同步 → IKE自发下降。
"默认"密码（过时组/MD5/SHA1）。
flap SA/BGP和RTT/PLR的增长没有差异。

15）准备就绪支票清单

［IKEv2］+AES-GCM+PFS（14/19/20组），一致的生活时间，rekey ~ 70％。

• VTI/GRE，带过滤器/社区的BGP，ECMP或热站。
• NAT-T启用（如有必要）,打开UDP/500/4500, ESP沿途。
• MTU 1436-1460, MSS clamp 1350-1380, PMTUD处于活动状态。
• DPD 10-15 s，Dead Peer反应和SA快速重新安装。
• SA/BGP/RTT/PLR监测；集中收集的IKE/ESP逻辑。
• 自动Serts/Key轮换，TTL短，OCSP/CRL，Alertes。
• 分段（VRF）,分裂隧道,egress "deny-by-by-default"策略。
• 云门户（AWS/GCP/Azure）在实际负载下进行了测试。
• 记录的运行手册"以及运河的捕获和扩展。

16) TL;DR

使用IKEv2+AES-GCM+PFS、动态BGP路由、两个独立链接上的冗余和正确的MTU/MSS构建基于路由的IPsec （VTI/GRE）。启用NAT-T、DPD和常规验证,监视SA/BGP/RTT/PLR,存储验证日志。在云中,使用托管网关和PrivateLink；在Kubernetes-不通过VPN"挂起"Pod CIDR。对于iGaming来说，通过收紧的SLO和审计，保持管辖权和支付回路的隔离。