BI 连不上数据库,先问一个问题:源 IP 是谁的
数据团队最常给运维报的工单之一是「报表工具连不上数据库」。数据库托管方、云厂商安全组和网络访问控制策略都支持仅允许指定来源地址连接,这很合理,但往往带来一个让人迷惑的问题:白名单里该写谁的地址?答案取决于 BI 工具怎样部署。这篇文章面向 IT 与运维负责人,把常见的 Metabase、Tableau 接入拆成三种形态,说明每种形态的源 IP 归属于谁,独享 IP 在哪种形态里真正有用,哪种形态里没有用。具体地址列表以各厂商官方文档为准,下文不列任何具体地址。
三种接入形态对照
| 形态 | 谁发起到数据库的连接 | 白名单应登记 | 独享 IP 是否相关 |
|---|---|---|---|
| 云版 BI(厂商托管) | 厂商的服务器 | 厂商公布的出口地址 | 不直接相关 |
| 自托管 BI(自己的服务器) | 你们的 BI 服务器 | 该服务器对外的出口地址 | 可用于固定出口 |
| 分析师桌面端 | 分析师的电脑 | 分析师所在网络的出口地址 | 最直接的适用场景 |
形态一:云版 BI,登记的是厂商的地址
这种形态下源 IP 不属于你们
使用厂商托管的 BI 服务时,数据库连接是从厂商的基础设施发出的。以 Metabase Cloud 为例,官方排障指引提示,若数据源部署在内网、只允许受限来源访问,需要把 Metabase Cloud 的地址加入白名单。Tableau Cloud 则由 Salesforce 公布地址范围,并说明新地址会提前公布、站点管理员会收到通知,建议用官方提供的地址列表维护白名单,而不是手工抄写。
这里独享 IP 没有用武之地,因为连接不经过你们的网络。要把管理后台、登录来源限制在企业出口,才是独享 IP 在云版 BI 里的用法。如果数据库不希望对公网开放,可以考虑厂商提供的私有连接或安全代理类方案,例如 Tableau 提供的 Bridge,从你们网络内部发起出站连接。
形态二:自托管 BI,出口地址必须稳定
自托管服务器的出口可能会变
自托管的 Metabase 实例连接数据库时,登记的就是该实例所在服务器的对外出口。若实例跑在容器或弹性云主机上,重启后出口地址可能改变,白名单就会失效。稳定的做法是让 BI 服务器的出站流量统一经过一个固定出口(云厂商的 NAT 网关或独享 IP),再把这个地址登记进数据库白名单。这也和 CI/CD 流水线遇到的问题类似,可以参考GitHub Actions 总因动态 IP 被拒的固定出口配置。若系统分布在多个云,还要统一规划出口,参见多云环境统一出口 IP 规划。
形态三:分析师桌面端,独享 IP 最有用的地方
分析师在家、在差旅时怎么办
桌面端 BI 工具或 SQL 客户端直接从分析师电脑连接数据库。分析师在办公室、家里、咖啡厅各自对应不同的公网地址,数据库白名单不可能逐个登记。让分析师的数据库流量统一经过企业独享 IP 出去,白名单里就只需要一个地址,管理员也可以在人员离职时只关闭他的接入权限,而不用改数据库的网络策略。这里的关键是只把数据库端口的流量路由到独享出口,而不是让全部上网流量都绕一圈,这样既节约带宽,也减少对独享出口的无谓压力。
登记后的连通性验证与最小权限
- 在会走独享出口的机器上,执行
curl -4 https://ipv4.icanhazip.com确认出口地址与登记的一致; - 用
nc -vz 数据库主机 端口测试端口是否可达,区分网络层拒绝和账号密码错误; - 用客户端或 BI 工具的「测试连接」功能核对结果;
- 关闭独享出口重新测试一次,确认白名单确实在起作用;
- 把结果记入变更记录。
白名单解决的是「谁能到达」,不解决「谁能看到什么」。数据库账号应采用只读、按库表授权、启用 TLS,并和来源限制形成多层防护,这类思路可以和API 密钥绑定 IP 白名单的纵深防御互相参照。NasaVPN 的独享 IP 与独享节点适合承担分析师桌面端和自托管 BI 的固定出口角色,登记前请先按上述三种形态确认源 IP 归属于谁。