Blog
分支机构站点到站点 VPN：地址规划比隧道算法更重要
分支十来人，要访总部文件服务器和 AD。专线预算没有，站点到站点 VPN 上桌。设备可以是防火墙对防火墙，也可以是总部防火墙对分支小路由。算法套件选什么，往往不如「两边有没有用同一 192.168.1.0/24」致命。
动工前：地址与域名
- 画出总部、分支、VPN 互联（若用）三段互不重叠的网段
- 分支若已是 192.168.1.0/24 且总部同网段——先改分支，再开隧道，血的教训
- DNS：分支客户端后缀搜总部域；条件转发或站点 DNS
重叠网段的症状极具迷惑性：隧道 up，部分 IP 通部分不通，像幽灵 ACL。
隧道模式选择
| 模式 | 适合 |
|---|---|
| 策略域（感兴趣流）IPsec | 简单、设备老、流量矩阵小 |
| 路由型（VTI/route-based） | 多网段、要跑动态路由或要简洁 next-hop |
我优先路由型：内网加一段，只要加路由，不必改一长串 proxy-id。两边能力不对称时，再退回策略域。
最小可运行配置清单
- 预共享密钥或证书（密钥长度与轮换写进台账）
- 一期 Phase1/Phase2 提案一致（加密、哈希、DH、PFS）
- 存活检测 DPD
- 感兴趣流或路由：
总部局域网 ↔ 分支局域网 - NAT：旁路对端网段，避免把对端地址 NA 成自己公网
双出口总部的坑
总部有主备 WAN 时，隧道终点要钉在稳定的主公网或使用支持双 ISP 的方案。主挂备起后：
- 对端仍连旧 IP → 长期 down
- 动态域名 DDNS 更新延迟 → 半天「时好时坏」
分支侧写死总部 FQDN 并确认 TTL 与更新脚本，比「填了一个谁都忘了的 IP」强。
排障顺序（别先重装）
- 外网互通：分支能否打到总部 WAN IP
- IKE 是否建立：阶段 1/2 日志
- 选择子网是否匹配：proxy-id 反了最常见
- 内网路由是否指到隧道
- 防火墙是否放行 隧道封装之后 的内网业务端口
- 两端时间是否偏移过大（证书/部分实现敏感）
# 思路，不绑厂商
show vpn ike sa
show vpn ipsec sa
traceroute 对端内网网关
业务验证
- 分支电脑加域/登录（若走总部 DC）
\\files延迟与权限- 语音/视频是否误走 VPN（可分流：仅内网前缀进隧道）
全流量 VPN 在小分支会上演「刷短视频挤爆隧道」。分流策略写进设计，而不是上线后骂带宽。
运维
- 监控隧道 up/down 与流量
- 密钥轮换与人员离职
- 分支断电后来电自启与隧道自恢复
小结
站点 VPN 是网络工程师的常规项目： 地址规划、路由/策略一致性、NAT 旁路、切换与监控。简历上可写清规模（几点、多少用户、是否双机），比只写「配置过 IPsec」更有说服力。隧道 up 只是开始；业务在峰期仍顺，才算交付。