Param-Cloudtelecom/fortinet-voip-firewall

# fortinet-voip-firewall    用于前端部署 SIP trunk/SBC 的 FortiGate 防火墙配置 — 涵盖 SIP ALG 问题、RTP 防火墙策略以及语音流量优先级划分。 ## 此方案解决的问题 FortiGate 的 SIP ALG (Application Layer Gateway) 会在传输过程中检查并重写 SIP 信令和 SDP，以此来“协助” NAT 穿透。如果在部署中，SBC ([`kamailio-sbc-router`](https://github.com/Param-Cloudtelecom/kamailio-sbc-router)) 已经通过 `rtpengine` 处理了 NAT 穿透，那么 ALG 的重写操作 就会与 SBC 的重写操作发生严重冲突——典型的症状就是 **单向或无音频，但如果你完全绕过防火墙它就会“自动修复”**， 如果你没有提前意识到要首先怀疑 ALG，这正是那种会白白浪费你一整天时间去处理的工单。 [`fortigate-sip-config.conf`](fortigate-sip-config.conf) 详细介绍了： 1. **在保持足够的** 会话跟踪以使 RTP 打孔生效的同时，中和 SIP ALG 的 SDP 重写**——这是介于 “完全开启 ALG”（会破坏由 SBC 处理的 NAT 穿透）和“完全关闭 ALG” （会完全丧失打孔跟踪能力，通常导致需要大范围开放静态 RTP 端口）之间的折中方案。 2. 用于 SIP 信令（TLS，与 SBC 的 TLS 监听器相匹配）和 RTP 媒体端口范围（与 [`freeswitch-cloud-pbx`](https://github.com/Param-Cloudtelecom/freeswitch-cloud-pbx) 中 `switch.conf.xml` 配置的范围相匹配）的**防火墙策略**。 3. **流量整形**，确保语音获得保证的带宽和优先 排队——如果没有这个，在同一条链路上的大文件传输或备份任务 会在任何人想到检查带宽竞争之前，就表现为断断续续的音频。 ## 如何真正诊断“是不是 ALG 的问题？” ``` # 在 FortiGate 上，检查相关 policy 的当前 ALG 状态 diagnose sys session filter dport 5060 diagnose sys session list # 从 SBC/SIP 侧，对比发送和接收的 SDP - 如果 # c= 或 m= 行与 Kamailio/FreeSWITCH 实际发送的不同， # 两者之间的某些东西对其进行了重写 sngrep -d any port 5060 or port 5061 ``` 如果 SDP 在穿过防火墙时发生了形态改变，而且你这一侧没有任何东西 应该对其进行过处理，那就是 ALG 在作祟。 ## 为什么这不仅仅关乎 FortiGate 每一台带有 VoIP “helper” 检测功能的有状态防火墙（Cisco 的 `inspect sip`，Palo Alto/Check Point 上的类似功能）在 SBC 已经 正确处理了 NAT 穿透时，都会面临相同的基础冲突。 这种修复模式——缩小 ALG 的作用范围而不是完全禁用它， 只精确开放 SBC/核心实际使用的端口，并明确地对语音 流量进行优先级排序——即便 CLI 语法不尽相同，这种模式也适用于所有厂商。

标签：FortiGate, RTP, SIP, VoIP, 流量整形, 红队技术, 网络配置, 防火墙策略