AWS上FortiGate HA高可用配置实战：FGCP与SDN Connector实现秒级切换

干过AWS网络架构的人应该都有同感物理机房里的防火墙双机热备靠的是VRRP和VIP漂移但把FortiGate搬上AWS之后这套老思路基本行不通。AWS不给你二层组播也不让你随便飘一个虚拟IP单跑一台FortiGate实例只要底层AZ抖动一下、实例被Stop整个出口就断了。所以在AWS上给FortiGate配置HA是云网络改造里绕不开的刚需场景。这篇文章我会把FortiGate在AWS环境里做HA的完整流程讲清楚包括为什么必须换思路、AWS侧要提前准备哪些资源和权限、FGCP集群怎么搭、SDN Connector怎么让路由自动切换以及我在真实项目里踩过的坑。适合正在做AWS云上网络架构、准备把下一代防火墙高可用真正落地的同行参考。1. 为什么FortiGate上了AWSHA不能照搬物理机房的思路1.1 物理机房的双机热备在云上为什么失灵在物理机房做防火墙HA通常是两台设备堆叠或者主备部署靠VRRP之类的协议共享一个VIP。主设备挂掉备设备通过心跳感知到之后立刻把VIP抢过来同时发出免费ARP让交换机把流量引到新主设备。整个过程依赖二层组播、共享MAC、免费ARP这几个老伙计。到了AWS就麻烦了。AWS VPC是一个被SDN虚拟化过的网络环境默认不支持组播你没法用VRRP的心跳组播形式发现对端。就算你把两台FortiGate放在同一个子网里也没法让一个VIP在两台设备的ENI之间“飘”因为AWS的ENI和IP绑定太死不响应免费ARP那套逻辑。更现实的问题是业务流量怎么从外部走到防火墙、防火墙怎么把流量转发到内网这中间靠的全是VPC路由表、弹性公网IP、安全组这些云原生的东西根本不认识你的VIP。所以FortiGate在AWS上做HA核心不是“让VIP飘起来”而是要让云网络的路由和公网地址自动跟随主备状态切换。想明白这一点后面配置就不容易走偏。1.2 AWS上做HA的两种主流路线我接触到的AWS环境里FortiGate HA主要有两种落地方案各自的目标和使用场景不太一样。路线AFGCP SDN Connector 的原生HA方案FGCPFortiGate Cluster Protocol是FortiGate自带的集群协议支持Active-Passive和Active-Active模式。在AWS上FGCP可以通过单播方式运行主备之间通过心跳端口互相探测同时会同步会话表、配置、路由表等信息。SDN Connector是FortiGate和AWS API之间的桥梁当发生主备切换时FortiGate会通过SDN Connector调用AWS API自动修改VPC路由表、重新绑定弹性公网IP。这种方案最大的好处是切换速度快业务影响小。因为会话表是同步的主设备挂了备设备上已经有全部活跃会话切过去之后大部分连接都不会断。企业里的生产业务如果对连续性要求高一般会选这个方案。路线B云原生脚本自动化方案用CloudWatch监控FortiGate实例的健康状态一旦发现主实例异常就通过Lambda函数调用AWS API把路由表目标从主实例ENI切换到备实例ENI再把EIP重新绑定过去。这种方案成本低不依赖FGCP的会话同步但切换速度慢一些而且已经建立的TCP连接大概率会断开需要客户端重新发起连接。适合对成本敏感、业务容忍短时中断的场景。两种路线的区别可以看这张表对比项FGCP SDN Connector云原生脚本自动化切换速度秒级会话保持分钟级可能丢连接会话保持支持session-pickup不支持复杂度中等需要配FGCP和SDN较低主要是IAM和Lambda成本需要两台带HA授权实例普通两台实例即可适合场景生产核心业务、金融交易开发测试、非关键业务1.3 我推荐用FGCP SDN Connector的原因如果条件允许我几乎都会选FGCP SDN Connector这个方案。原因很直接用户感觉不到切换运维才不会有压力。我之前在一个电商项目里一开始图省事用了脚本自动化方案结果赶上大促前一台实例被系统底层维护触发重启流量断了将近三分钟监控告警直接打爆业务那边电话都追过来了。后来切到FGCP方案同样做了一次主实例停止演练客户端的长连接基本没断只有几次重试业务侧几乎无感。从那次以后我对生产环境里的HA基本只有一个标准切了跟没切一样。当然FGCP方案对配置细节要求更高不是你点两下就能起来的。后面几节我会把AWS侧的准备工作和FortiGate上的配置一步一步讲透。2. 动手前先把AWS侧的网络骨架搭好2.1 VPC和子网规划给HA留出足够空间FortiGate在AWS上的HA理论上最少需要两个可用区主备各占一个。如果只部署在一个可用区那只能防实例故障防不了可用区整体故障不能算真正的高可用。我习惯的规划方式是这样的假设VPC网段是10.60.0.0/16子网网段可用区用途public-subnet-a10.60.1.0/24us-east-1a主FortiGate外部接口public-subnet-b10.60.2.0/24us-east-1b备FortiGate外部接口private-subnet-a10.60.10.0/24us-east-1a主FortiGate内部接口private-subnet-b10.60.20.0/24us-east-1b备FortiGate内部接口mgmt-subnet-a10.60.100.0/24us-east-1a主FortiGate管理接口mgmt-subnet-b10.60.200.0/24us-east-1b备FortiGate管理接口hb-subnet10.60.30.0/24可用区A/B均可主备心跳互通这里有几个关键点外部接口、内部接口、管理接口最好分开子网。这样安全组和路由策略能做得更干净也方便后续排障。尤其是管理面如果和业务面混在一起一不小心就把管理端口暴露到公网风险很大。心跳子网非常关键。FGCP的心跳流量非常敏感延迟太高会导致主备频繁震荡。如果你把两台实例放在不同可用区心跳子网建议选择两个可用区之间的专线子网或者用一个延迟尽可能低的子网段。如果条件允许把主备放在同一个可用区的机架内做第一层HA再通过其他手段做跨可用区容灾心跳会稳很多。每个业务子网的路由表要预留好。内部接口所在的私有子网默认路由要指向FortiGate的ENI当主备切换时这条默认路由会在SDN Connector的帮助下自动改指向。2.2 IAM角色把“改路由、绑EIP”的权限交给FortiGate这是整个方案里最容易忽略的一步。很多人在FortiGate上配好了FGCP却发现故障切换之后路由表纹丝不动查了半天最后发现是IAM角色权限不够。FortiGate要通过SDN Connector操作AWS资源需要一个IAM角色并且在启动EC2实例时把这个角色绑定到实例上。角色的信任关系要允许EC2服务代入权限策略至少要包含以下Actionec2:DescribeInstancesec2:DescribeInstanceStatusec2:DescribeRouteTablesec2:CreateRouteec2:DeleteRouteec2:ReplaceRouteec2:DescribeAddressesec2:AssociateAddressec2:DisassociateAddressec2:DescribeNetworkInterfacesec2:DescribeSubnetsec2:DescribeTags我常用的是一个最小权限策略写出来给大家参考{ Version: 2012-10-17, Statement: [ { Effect: Allow, Action: [ ec2:DescribeInstances, ec2:DescribeInstanceStatus, ec2:DescribeRouteTables, ec2:DescribeAddresses, ec2:DescribeNetworkInterfaces, ec2:DescribeSubnets, ec2:DescribeTags, ec2:CreateRoute, ec2:DeleteRoute, ec2:ReplaceRoute, ec2:AssociateAddress, ec2:DisassociateAddress ], Resource: * } ] }注意这里Resource用了通配符如果你们公司安全审计比较严格可以把Resource限定到具体的VPC、路由表和ENI上效果一样但更安全。我还建议给这个角色起一个一眼能看懂的名字比如FortiGate-HA-Role。后面启动实例的时候在“高级设置”里把IAM角色选上FortiGate实例启动后就能通过实例元数据服务拿到临时凭证不需要在设备里硬编码Access Key和Secret Key。这样不仅安全还省去了定期换密钥的麻烦。2.3 安全组放通清单别让心跳和业务流量被拦安全组是AWS上最容易被忽视的“隐形墙”。你FortiGate配置得再对安全组没放通心跳包发不过去主备永远组不成集群。我建议给FortiGate的外部接口、内部接口、心跳接口分别创建不同的安全组不要一个安全组通吃这样方便控制也方便审计。安全组方向源/目的协议端口用途SG-FGT-Ext入站0.0.0.0/0业务端口如TCP 443、TCP 80公网访问业务SG-FGT-Ext入站管理网段TCP 22、TCP 443管理SSH和Web界面SG-FGT-Int入站VPC内私有网段业务所需端口内网流量转发SG-FGT-HB入站主备心跳接口IPTCP 703FGCP心跳SG-FGT-HB入站主备心跳接口IPTCP 5199会话同步某些版本心跳端口这里特别说明一下。FGCP在AWS上使用单播模式时心跳流量走的是TCP 703端口。如果你发现两台设备的心跳状态一直起不来先别怀疑配置用nc或者telnet从一台设备试连另一台的703端口大概率是安全组把端口挡了。另外部分FortiGate版本在做会话同步时还会用到TCP 5199端口保险起见两个端口都放通。提示安全组的源IP建议精确到心跳接口的私有IP不要用0.0.0.0/0。因为心跳接口属于管理面暴露给整个VPC风险太大。3. FortiGate HA核心配置实操3.1 启动两台FortiGate实例关键参数别选错AWS Marketplace里有FortiGate的官方镜像分PAYG按量付费和BYOL自带许可两种。做HA的话我建议两台实例选同一个机型、同一个镜像版本避免因固件版本不一致导致的主备同步异常。启动实例时有几个参数需要特别留意IAM角色在高级设置里选择前面创建的FortiGate-HA-Role。实例类型建议根据业务吞吐量选生产环境至少c5.large起步别用t2/t3突发型跑生产流量丢包会教你做人。网络选择把实例放进提前规划好的子网主设备放AZ-A的public-subnet-a备设备放AZ-B的public-subnet-b。网卡数量FortiGate在AWS上一般会用多网卡分别对应外部、内部、心跳。建议启动时就把ENI规划好比如port1绑定外部子网port2绑定心跳子网port3绑定内部子网。关闭“实例终止保护”这个不是必须但某些环境下如果开启了终止保护自动化脚本在故障切换时可能无法正常停止旧实例导致EIP无法解绑。两台实例启动后通过管理接口登录FortiGate先把接口IP配上。这里我给一个常见的主备规划示例角色可用区port1外部port2心跳port3内部主us-east-1a10.60.1.10/2410.60.30.10/2410.60.10.10/24备us-east-1b10.60.2.10/2410.60.30.20/2410.60.20.10/24接口配置用CLI或者Web界面都行配完记得ping通对端心跳IP确保网络层是通的。3.2 用FGCP把两台设备拉成主备集群网络通了之后就可以在FortiGate上配置FGCP了。这里我用CLI演示逻辑比Web界面更清晰。在主设备上执行config system ha set mode a-p set group-id 1 set group-name fortigate-aws-ha set hbdev port2 50 set session-pickup enable set session-pickup-connectionless enable set unicast enable set unicast-peer 10.60.30.20 set override disable set priority 200 end在备设备上执行config system ha set mode a-p set group-id 1 set group-name fortigate-aws-ha set hbdev port2 50 set session-pickup enable set session-pickup-connectionless enable set unicast enable set unicast-peer 10.60.30.10 set override disable set priority 100 end几个参数解释一下mode a-pActive-Passive模式主设备干活备设备随时准备接管。hbdev port2 50指定心跳接口为port250是心跳间隔权重值越小优先级越高可以理解为探测频率的权重配置。unicast enableAWS不支持组播必须开启单播模式。unicast-peer指定对端心跳接口IP主备互指。session-pickup enable开启会话同步这是业务无感切换的关键。priority优先级高的会成为主设备。我把主设备设为200备设备设为100。配置完之后在主设备上执行get system ha status能看到类似下面的输出说明集群已经建立HA Health Status: OK Model: FortiGate-VM64 Mode: HA A-P Group Name: fortigate-aws-ha Group ID: 1 Priority: 200 HA State: primary如果HA State显示的是standalone说明备设备没有成功加入集群需要回头检查心跳端口和安全组。3.3 用SDN Connector打通路由自动切换FGCP集群起来之后主备之间的会话同步已经工作了但还有一个关键问题没解决AWS路由表不会自己动。主设备挂了备设备就算抢到了主角色VPC路由表还是指向旧主设备的ENI流量照样进不去。这时候就要配置SDN Connector让FortiGate在发生主备切换时自动调用AWS API改路由。在FortiGate上配置SDN Connectorconfig system sdn-connector edit aws-connector set type aws set region us-east-1 set external-account-id 123456789012 set ha-status enable set update-interface port1 port3 next end这里的external-account-id是你的AWS账号IDha-status enable是告诉FortiGate这个SDN Connector要和HA状态联动发生切换时执行资源更新动作。update-interface指定哪几个接口参与资源更新一般把外部接口和内部接口都加进去。如果你的FortiGate实例没有绑定IAM角色也可以用Access Key和Secret Key认证但我前面说过强烈建议用IAM角色。接下来还需要在FortiGate上配置路由策略让SDN Connector知道哪些路由表需要管理。这一步在Web界面里是在“系统管理 网络 SDN”里配置关联好VPC和子网之后FortiGate会自动发现对应的路由表。配置完成后可以在FortiGate上执行diagnose sdn-connector status确认SDN Connector和AWS API的连通性、权限是否正常。注意SDN Connector需要能发现你在AWS上创建的路由表。如果你把外部接口和内部接口放在不同的路由域要确保fortigate的SDN Connector配置里把“所有相关路由表”都纳入管理否则切换时可能会漏掉某一段路由。3.4 验证高可用从check到真实故障演练集群配置完了SDN Connector也通了接下来最重要的事情是验证。先做静态检查。在主设备上执行diagnose ha status应该能看到类似下面的信息Primary: 10.60.30.10, priority 200 Secondary: 10.60.30.20, priority 100再检查会话同步是否正常diagnose sys session stat确认主设备上的活跃会话能够被备设备学习到。如果会话同步没开启你会发现备设备的session表几乎是空的这种状态切过去所有连接全部断。静态检查通过后一定要做一次真实故障演练。我是这么操作的找一台内网测试机持续ping FortiGate的内部接口IP。在AWS控制台里手动停止主FortiGate实例。注意选择“停止”而不是“终止”终止会影响后续恢复。观察ping的丢包情况以及备设备是否在几秒钟内接管主角色get system ha status检查VPC私有子网的路由表确认默认路由的目标已经从旧主设备的ENI切到了新主设备的ENI。如果有EIP绑在外部接口检查EIP是否已经重新关联到新的主ENI。如果你前面配置全部正确整个过程应该非常顺滑。内网测试机的ping只会丢几个包甚至完全不丢。如果发现了长时间中断优先检查SDN Connector的状态、IAM权限、路由表更新是否成功。4. 常见问题与排查实战4.1 我在AWS上配FortiGate HA踩过的坑我把这几年在AWS上配FortiGate HA遇到过的问题整理成一个速查表每一行都是真实踩过的坑不是网上抄来的现象可能原因排查与解决备机心跳起不来HA状态一直是standalone安全组没放通TCP 703检查SG-FGT-HB安全组telnet对端703端口测试主备切换后路由表没更新SDN Connector权限不足检查IAM角色是否包含ec2:ReplaceRoute、DeleteRoute切换后内网能通但公网访问不通EIP没有跟随切到新主节点在SDN Connector配置里检查external-ip关联或手动重新绑定EIP主备配置不一致经常被覆盖固件版本不一致统一两台实例的FortiOS版本和补丁级别切换时有大量会话断开session-pickup没开或会话同步异常确认session-pickup enable检查TCP 5199端口备设备上看到设备角色是primary但云上路由没动SDN Connector没启用ha-status检查set ha-status enable配置心跳频繁震荡主备角色反复切换心跳延迟过高或心跳接口流量过大把心跳放到独立子网避免和业务流量混跑这里面最坑的是第三个EIP没有跟随切换。很多人配置的时候SDN Connector只关注了路由表忽略了EIP的重新绑定。业务方反馈公网访问不了你再去看EIP还挂在已经停止的旧实例上。所以我在生产环境里通常会把外部接口直接分配一个静态EIP并且确认SDN Connector配置里对EIP关联的资源类型做了适配。4.2 排查命令和日志定位技巧如果你是在配HA过程中出了问题下面几个命令能帮你快速定位比在Web界面里四处点快得多# 查看HA整体状态 get system ha status # 查看HA详细诊断信息 diagnose ha status # 查看心跳接口收发包情况 diagnose netlink interface list port2 # 抓取心跳接口的FGCP报文 diagnose sniffer packet port2 tcp port 703 4 # 查看SDN Connector与AWS API通信状态 diagnose sdn-connector status # 查看HA相关的实时日志 diagnose debug application ha -1 diagnose debug enable如果心跳接口一直有收包但HA状态不对我会先看sniffer抓包结果里是不是有FGCP的Hello报文。如果只有单方向的报文说明另一端的发送有问题要么安全组挡住了要么unicast-peer配错了。如果SDN Connector状态显示为down优先查IAM角色的权限是不是给全了。AWS的权限策略有时候会因为通配符写得太窄导致某个API没被允许FortiGate的日志里会明确告诉你哪个API调用被拒绝了照着加上就行。4.3 大家常问的端口映射到底在哪做聊完HA我顺便回复一下经常在后台被问到的问题FortiGate上的端口映射在哪里设置特别是以前用50B这类小盒子的时候总有人翻半天菜单找不到。端口映射在FortiGate里分两步走先做DNAT再做放行策略。第一步在“Policy Objects Virtual IPs”里新建一个Virtual IP。把外部接口IP和公网端口映射到内网服务器的私有IP和端口。比如你想让公网访问内网一台10.60.10.50的Web服务器外部端口8080映射到内网80就在Virtual IP里填字段值Nameweb-dnatInterfaceport1外部接口External IP公网EIP地址Mapped IP10.60.10.50Port Forward启用External Port8080Mapped Port80第二步在“Policy Objects Firewall Policy”里新建一条策略源地址填公网或任意目的地址选择刚才创建的web-dnat虚拟IP服务选择HTTP动作选ACCEPT然后启用NAT。这两步做完公网访问EIP:8080就能转发到内网10.60.10.50:80。这个逻辑在50B、FortiGate VM、AWS上的虚拟实例完全一样区别只是老设备登录IP一般是192.168.1.99新云端实例是你自己分配的管理IP。提示做完端口映射如果还是不通先别急着改配置回头看两件事一是安全组是否放行了外部端口二是FortiGate有没有启用对应策略的日志打开日志看drop计数最直接。结尾再分享一点个人经验在AWS上配FortiGate HA最重要的不是敲命令那一瞬间而是配完之后敢不敢做一次真正的破坏性测试。我见过太多团队配置完看到HA状态是OK就觉得万事大吉结果第一次真实故障才发现路由表压根没切、EIP没跟着走、会话全断。所以我给自己定了一个规矩任何HA方案交付前必须做一次实例停止演练而且要在业务低峰期用真实流量验证。另外云端HA比物理机房HA多了一个看不见的风险——你依赖的AWS API本身也有调用频率限制。SDN Connector切换时需要执行多个API调用如果IAM权限里的限流策略设置得过严或者API调用并发过高可能切换会变慢甚至失败。我的建议是给SDN Connector涉及的API调用留足余量别把这类自动化操作和业务接口的配额混在一起评估。最后一个小技巧把两台FortiGate的HA状态接到你的监控系统里不只是看主设备活着没还要盯备设备的健康状态。很多时候备机已经悄悄掉群了主设备还不知道直到真正需要它顶上时才暴露问题。我在实际运维中吃过这个亏后来加了两个监控项一个看HA集群成员数一个看备机的会话同步延迟从此再没出过“以为有HA、其实没有HA”的尴尬。