Freepbx和Kamailio部署在同一台服务器的不关防火墙注册不了解决方案

事情是这样的，我们把Freepbx和kamailio放在同一个服务器上，它们之间是可以正常工作的，但是必须加白名单才可以注册，也就是说，我每个分机都要加白，或者是关闭防火墙才可以注册得上，这样就变得麻烦了，我们是需要kamailio和freepbx可以在一个服务器上运行；

思路及解决方案

这里的重点就是在不加白的情况下，我们需要把同机的127.0.0.1先加白，然后开放9999端口给到kamailio，也就是说让流量可以到过kamailio，这个通道才算是通的；不然此时外部流量，都还没有到达kamailio根本无法注册，过虑规则，及其它规则更是没法生效。

我将 FreePBX 和 Kamailio 部署在同一台服务器上，Kamailio 作为公网 SIP 入口，负责接收外部终端的注册请求，再转发给后端的 FreePBX 处理。这样的架构本来很清晰，但一直有个让人头疼的问题：

我试过开启 FreePBX 的“响应式防火墙”（Responsive Firewall），在终端直连 FreePBX 时它工作得很好，能自动放行注册成功的 IP。但一旦在前面加上 Kamailio，整个机制就失效了——防火墙仍然会拦截请求，直到我把那个动态 IP 手动添加进信任列表。

排查过程：到底是谁在拦截？

为了找出根源，我在服务器上抓包，观察开启防火墙但未加白 IP 时的注册信令：

终端公网IP:随机端口  ->  服务器内网IP:9999  REGISTER (多次重传，无任何应答)

抓包显示，服务器网卡确实收到了终端发来的 REGISTER 消息，但 Kamailio 没有任何回应，连 401 Unauthorized 都没有。这说明数据包已经到达了网络接口，但在进入 Kamailio 进程之前被丢弃了——这正是 iptables 防火墙默认 DROP 策略的典型表现。

结论非常明确：FreePBX 防火墙将 Kamailio 监听的 9999/UDP 端口也一并保护了起来，没有对公网开放，导致 Kamailio 根本收不到外部请求。

解决方案：放行 Kamailio 端口，保持防火墙全开

定位到问题后，解决起来就非常直接了：在 FreePBX 的防火墙策略中，放行 Kamailio 对外提供服务的端口（9999/UDP），而不是关闭防火墙。

具体操作是在 中添加一条自定义服务规则：

• 服务名：Kamailio
• 协 议：UDP
• 端 口：9999
• 允许区域：Internet

然后应用防火墙配置即可。如果你习惯命令行，也可以用 iptables 临时测试：

iptables -I INPUT 1 -p udp --dport 9999 -j ACCEPT

做完这一步后，客户端立刻就能正常收发 REGISTER 和 401 鉴权挑战了，注册流程完全恢复，无论终端 IP 怎么变都不再需要加白。

安全架构：两道防火墙协同工作

很多人会担心，这样做是不是削弱了安全？事实恰恰相反：防火墙依然在全功率运行，安全边界被前移到了更合适的位置。

现在的防护模型是这样的：

防护层	作用
FreePBX 防火墙	保护 FreePBX 自身以及服务器上的其他所有服务（Web 管理、SSH、数据库等）。它只对本地 Kamailio 的通信放行，依然拒绝任何来自公网对这些服务的直接访问。
Kamailio 应用层安全	作为公网唯一的 SIP 入口，负责处理所有外部请求。它必须强制执行注册认证、请求频率限制、恶意扫描封禁等策略，实际上充当了一道“应用防火墙”。

换句话说，我并没有关闭防火墙，也没有把整个服务器暴露出去，只是精准地在防火墙上为 Kamailio 开了一扇必要的门。FreePBX 防火墙仍然在保护它该保护的东西，而 Kamailio 则负责守护这扇门背后的逻辑。

这就像大楼的门禁系统：原来只有一道门，所有人进门都得登记（加白 IP）。现在改成了一道对外接待的前台（Kamailio），前台自己会验明身份，而大楼其他所有办公室的门（FreePBX 等服务）依然锁着，只对前台放行。

后续加固建议

这套架构稳定之后，安全重心就转移到了 Kamailio 身上，建议至少做好以下加固：

1. 强制强密码认证：所有分机密码长度应不少于 12 位，复杂无规律。
2. 请求频率限制：使用 Kamailio 的 pike 模块，限制单 IP 的注册和 INVITE 请求速率，防止暴力破解。
3. 集成 Fail2ban：监控 Kamailio 日志中失败的认证记录，自动将攻击 IP 加入系统防火墙黑名单。
4. NAT 穿越处理：确保 Kamailio 正确配置了 nathelper 模块，避免客户端因 NAT 导致信令或媒体异常。

这些解决问题的核心，是通过抓包分析实现的，证明抓包在此的作用很大

这次问题的本质，是防火墙策略没有随着架构变化而调整。当我们在 FreePBX 前面增加了 Kamailio 代理之后，就需要让防火墙明白：原来由 FreePBX 直接面对的不可信公网流量，现在变成了只需面对可信的 Kamailio，而 Kamailio 自身则需要向公网开放必要端口。

最终，通过一条简单的防火墙规则，既保留了 FreePBX 内置防火墙的所有保护，又让 Kamailio 能够正常工作，彻底告别了动态 IP 加白的烦恼。