小团队还在用脚本管服务器账号？FreeIPA 把主机信任和统一登录一次理顺

上个月有个做 SaaS 的创业团队找我复盘一次事故：一名运维离职两周后，他手里的三台跳板机账号仍然能登录，原因是那批机器当初是手工分发 authorized_keys 加 expect 脚本批量改密码的，没人记得清到底在哪些机器上留了钥匙。等安全检查发现时，那几台机器已经被用来当成了临时的中转跳板。这种事在二十到两百台规模的小团队里太常见了，人员流动、外包进进出出、机器越加越多，账号和信任关系就成了一团没人敢动的乱麻。本文不聊那些大厂的成熟 IAM 平台，只说一个开源、能自己部署、把 LDAP 目录、Kerberos 认证、SSH 主机公钥托管和 sudo 规则集中托管一次性解决的方案：FreeIPA。

脚本管账号到底卡在哪

二十台机器以内，expect 脚本、ansible ad-hoc 改个密码、手动往每台机器塞 authorized_keys，确实够用，也确实省事。规模一旦过五十台，问题就开始显形，而且这些问题彼此牵连，单点打补丁只会让局面更乱。

离职人员的账号收不干净

用脚本批量建账号时，账号数据其实分散在每台机器的 /etc/passwd 和 /etc/shadow 里，没有一个统一的真相来源。人走了，理论上要登每台机器删用户、清家目录、撤密钥，可谁也不敢保证哪台边缘机器被漏掉。更麻烦的是 sudo 权限——很多团队把某个同事临时加进 wheel 组或者给了 NOPASSWD 的 sudoers 规则，离职时只删了账号没回收 sudo，账号虽删了但留下的提权后门还在。脚本方式下，这种散落的权限根本没有清单可查。

主机互信靠手动分发 SSH key

做批量运维免密登录，最常见的偷懒办法是把一台管理机的公钥塞进所有机器的 authorized_keys，或者搭建机器之间互信时互填 key。这种信任关系是隐式的、无中心的，你没法在统一的地方看一眼就知道「A 机器现在信任了哪些主机、哪些用户」。一旦某台机器的私钥泄露，信任链就被悄悄污染，而你没有审计入口去发现它。

审计无从查起

脚本方式下所有账号操作都散落在各机本地日志，想查「谁在什么时候登了哪台机器、执行了什么 sudo 命令」，得逐台拉日志、对齐时间、手工拼。时间一旦因为 NTP 没配齐而漂移，连顺序都排不对。等真出了事要追责或者过等保检查，拿不出集中日志，这才是最被动的。

FreeIPA 把审计的入口也收拢了。用户身份来自目录，sudo 规则来自目录，主机互信来自目录，这三者本身就是可关联的元数据；配合 SSSD 把登录和 sudo 事件落到系统日志、再用 auditd 或集中日志把各机日志汇到一处，你就能回答「某人在某时段登了哪些机器、跑了哪些提权命令」这类问题，而不用逐台翻。要强调一点：FreeIPA 提供的是身份和授权的集中真相，完整审计还要把各机日志接到集中平台（比如 rsyslog 转发到日志服务器），它不是替你把所有日志都存好的黑盒。但正因为身份有了统一来源，日志关联才第一次变得可行，而不是永远卡在「这台机器的本地用户到底是谁」这种基础问题上。

FreeIPA 把四件事一次理顺

FreeIPA 是 Red Hat 主导的免费开源身份管理项目，它在 Linux 服务器上把四块能力打包成了一个带 Web 控制台的体系。说白了，它不是单点工具，而是一套「集中目录 + 集中认证 + 集中主机信任 + 集中授权」的组合。

这张表把前面说的四类痛点对应到 FreeIPA 的解法上。注意它不是「功能更多」这么简单，而是把原本散落各机的真相收拢到一处：账号只有一份、权限只有一张清单、信任只有一本账。这种结构上的变化，才是脚本方式追不上的地方。

LDAP 目录：统一账号真相来源

FreeIPA 底层用 389 Directory Server 存用户、组、主机、服务这些对象，所有账号信息只有一份，存在 IPA 服务端。客户端机器通过 SSSD 去目录里查用户，本地不再各自维护一份 passwd 副本。人员入职、离职、调组，只要在控制台改一次，所有注册过的机器立刻生效。离职回收从这个角度变成了一个动作，而不是一次全集群巡检。

Kerberos 认证：不再靠密码和 key 满天飞

FreeIPA 内置 MIT Kerberos，用户登录和主机互信都走票据（TGT / 服务票据），而不是把密码或私钥摊在各处。主机之间互信时，靠的是 Kerberos 主机 principal 和 keytab，服务端那张授权列表是可查、可吊销的，不像 authorized_keys 那样只能逐台翻文件。票据有过期时间，被泄露的票据窗口有限，加上集中吊销，风险面比散落的 SSH key 小得多。

SSH 主机公钥托管：互信交给目录管

FreeIPA 能把主机的 SSH 公钥托管进 LDAP，客户端通过 SSSD 的 ssh 集成自动拿到对端主机的公钥，不用人工分发 known_hosts。你在一处维护「这台主机信任哪些主机」，所有客户端一致生效。想看某台机器现在被哪些主机信任，在控制台或命令行查一下就清楚，信任关系从隐式变显式。

sudo 规则集中托管：权限有清单可审计

FreeIPA 的 sudo 规则可以写「哪个用户组、在哪些主机、以谁的身份、能跑哪些命令」，规则存在目录里，由 SSSD 下发到客户端。这意味着 sudo 权限第一次有了全局清单：谁有多少提权范围，一目了然，离职时连 sudo 规则一起回收，不会留下 wheel 组的后门。日志侧配合 SSSD 和 auditd，能够把 sudo 执行落进集中可查的轨道。

典型部署架构怎么摆

绝大多数中小团队不需要搞得很重。一套能跑生产的最小架构，核心是一台 IPA 主服务器，其余机器作为客户端注册上去。

一台主 server 加多台 client

选一台稳定、网络位置居中的机器做 IPA 服务端，上面跑目录、Kerberos、Web 控制台和 DNS 组件。其余业务机器执行 ipa-client-install 带上服务端地址完成注册，注册后这台机器就接入了统一身份域：用户登录走 IPA、sudo 走 IPA、SSH 互信走 IPA。客户端本身很轻，因为重活都在服务端和 SSSD 缓存上。

客户端注册的过程值得说细一点：ipa-client-install 会在本机配置 SSSD、把机器以主机对象写进目录、生成主机 Kerberos keytab、并把 sudo 和 SSH 的集成接好。注册成功后，这台机器上的本地账号和域账号就分清楚了——域用户不再写进本地 passwd，而是 SSSD 按需从目录拉取并缓存。这带来一个很实际的好处：即使 IPA 服务端短暂不可达，已登录会话和缓存过的用户仍能工作，不会一断网全员被锁在门外。前提是 SSSD 缓存策略要配好，别把离线窗口设得太短。

要不要 replica 和 HA

当客户端数量上来、或者这台 IPA 一旦挂掉会影响全员登录时，就该上 replica（副本）。FreeIPA 支持多副本，副本之间复制目录和认证数据，挂掉一台另一台顶上。二十到两百台、且 IPA 只是身份基础设施不是业务系统的场景，一台主加一台 replica 基本够用，不需要像数据库那样上复杂的双活。这里要提醒一句：replica 数量建议奇数个（比如 3）以便目录复制的仲裁，但两台做主备也是常见折中，关键是别让单点裸奔。

拓扑上的注意点

IPA 服务端最好放在一个网络分区里，客户端能通过稳定内网地址访问。跨多可用区时，把副本分散到不同区能扛住单区故障。客户端注册用的是服务端主机名，所以这个主机名在所有机器上必须能解析——这就引出了下面最容易被坑的两个硬前提。

对服务器配置的真实需求

先说结论：FreeIPA 自身资源占用并不高，真正卡的不是 CPU 内存，而是 DNS 和 NTP 这两个前提。下面给一套可落地的配置参考。

DNS 是第一个硬前提

FreeIPA 在部署时会强烈要求能用 DNS 正确解析自己的主机名，包括正向记录（名字查 IP）和反向记录（IP 查名字）。很多团队图省事直接用 IP 和 /etc/hosts，结果 ipa-server-install 卡在 DNS 检查，或者客户端注册后互信解析错乱。最稳的做法是让 IPA 自带集成的 DNS 组件（基于 BIND）接管域内解析，或者在你已有的内网 DNS 上把 IPA 主机的正反向记录补齐。这一步做扎实，后面省掉一堆诡异问题。

NTP 是第二个硬前提

Kerberos 对时间极度敏感，默认允许的时间偏差通常只有几分钟。如果某台机器时间漂移超过阈值，它的 Kerberos 票据会被认为无效，登录直接失败，而且报错往往不直接说是时间问题，容易被误判成密码错或网络错。所以部署前先在所有机器上统一接一个 NTP 源，把时间锁死。这是 FreeIPA 最常见、也最隐蔽的坑，下面避坑段还会单独讲。

资源之外的隐性要求

IPA 服务端这台机器本身不建议跑重业务，身份基础设施挂了全员受影响。它应该是一台专供的基础设施机，稳定优先。系统盘留 40–80G 主要是给目录数据、日志和快照留余量，目录本身增长不快，但日志和备份会吃空间。带宽 10–50M 对内网认证足够，认证请求包很小，瓶颈从来不在带宽。

FreeIPA 和 Active Directory、纯 OpenLDAP 怎么选

这三个东西经常被混着比，其实定位差别很大，选错方向比不选更糟。

和 Active Directory 的区别

Active Directory 是微软体系，强在管 Windows 域、组策略、与 Office 和 Azure 生态打通。FreeIPA 是 Linux 原生的身份管理，对 Linux 主机、SSH、sudo、Kerberos 服务的支持是开箱即用的，而且免费、自己掌控数据。如果团队主体是 Windows 桌面加 Windows Server，AD 几乎是默认答案；如果主体是 Linux 服务器集群，FreeIPA 更顺手。两者还能通过信任关系打通（FreeIPA 信任 AD 林），让 Linux 侧用 AD 里的账号登录，这是很多混合环境的解法。但要说清楚：FreeIPA 本身不能像 AD 那样管 Windows 组策略，它不是 AD 的替代品，而是 Linux 侧的对应物。

信任打通的边界要讲明白，免得有人误以为接了 AD 就万事大吉。FreeIPA 信任 AD 林之后，Linux 主机能校验 AD 用户并让其登录，但账号生命周期、密码策略、组策略仍由 AD 那边说了算；FreeIPA 侧负责的是 Linux 主机上的授权映射（比如把某个 AD 组映射到本地的 sudo 规则）。也就是说，身份在 AD、授权在 IPA，两边各管一段。对既有 AD、又有 Linux 集群的团队，这套分工最省心；对纯 Linux 团队，直接上 FreeIPA 自建目录就够了，没必要为了「看起来标准」去引入一套 AD。选型看的是你现有的身份源在哪，而不是哪个名字更耳熟。

和纯 OpenLDAP 的区别

OpenLDAP 只是一个目录服务，给你存用户条目的能力，认证、Kerberos、SSH 公钥托管、sudo 规则这些得自己拼、自己运维。FreeIPA 是在 389 DS（目录）、MIT Kerberos、Bind（DNS）、SSSD、certmonger 这些成熟组件之上做的一体化封装，把集成和默认安全配置都替你做好了。纯 OpenLDAP 适合需要高度定制目录 schema、且团队有精力自己搭认证链的场景；中小团队想要「装上就能用、权限审计一条线」，FreeIPA 省下的整合成本远超那点灵活性。

取舍的落点

一句话概括：Windows 为主选 AD，Linux 为主且要省心选 FreeIPA，只要一个裸目录、愿意自己拼认证选 OpenLDAP。对二十到两百台 Linux 服务器、又不想养一队基础设施工程师的团队，FreeIPA 是性价比和可控性最平衡的那一档。

把 FreeIPA 跑在生产里要避的坑

下面这几条都是从真实部署翻车里总结出来的，每条都讲清「坑在哪、为什么、怎么判断、怎么避」。

时间不同步导致 Kerberos 全失效

问题：客户端或 IPA 服务端时间漂移超过 Kerberos 允许偏差，所有票据验证失败，登录报密码错或服务不可达。为什么坑：报错不直说时间，排查容易被带偏到网络和密码。如何判断：在出问题的机器上跑 `date` 对比服务端，偏差几分钟就能复现。如何规避：部署前统一接内网 NTP，把 chrony/ntpd 设为开机自启并监控偏移；IPA 自己也会校验时间，最好在装机流程里把它当成硬检查项。

DNS 正向或反向记录缺失

问题：用 IP 或 /etc/hosts 凑合，ipa-server-install 卡 DNS 检查，或者客户端注册成功但主机互信解析错。为什么坑：FreeIPA 的证书、Kerberos principal、SSH 公钥托管全依赖可解析的主机名。如何判断：在客户端 `nslookup` 服务端主机名和反向解析都该有结果。如何规避：让 IPA 接管集成 DNS，或在现有内网 DNS 补齐正反向记录，且主机名全程固定、别用易变的临时名。

证书两年有效期到期

问题：FreeIPA 内部用的证书默认有效期约两年，到期不续会导致服务逐步失常，常见表现是 Web 控制台打不开、某些认证报证书错。为什么坑：很多团队装完就忘了这茬，两年后半夜告警才发现。如何判断：用 `getcert list` 看证书剩余天数，临近到期会有提示。如何规避：FreeIPA 的 certmonger 能自动续期，但要确保它在跑、且没有被手工停掉；把证书剩余天数接进监控，提前告警比事后救火强。

客户端数量上来后的性能瓶颈

问题：客户端从几十台涨到几百上千台，单台 IPA 服务端目录复制和认证请求变重，登录变慢。为什么坑：资源占用虽低，但副本没规划、DNS 没缓存、SSSD 缓存没调，压力会堆到服务端。如何判断：观察服务端 CPU 和目录查询延迟，客户端登录耗时变长。如何规避：提前规划 replica 分散负载，客户端侧靠 SSSD 本地缓存扛离线，DNS 加缓存减少重复查询；副本数量随规模阶梯加，而不是等崩了再补。这里还有个常被忽略的点：目录复制流量本身不大，但客户端集中重启或集中续票时会形成请求尖峰，所以副本别都放在同一台宿主机或同一交换机下，物理分散才能让 HA 真正有意义。监控上建议盯住服务端目录查询延迟、副本复制延迟和证书剩余天数这三项，它们比 CPU 内存更能提前预示故障。

把 IPA 服务端当普通业务机混部

问题：为了省一台机器，把 IPA 和业务应用装一起，业务一吃资源 IPA 就抖，全员登录受影响。为什么坑：身份基础设施是全局依赖，它的可用性决定了所有人能不能进门。如何判断：IPA 机器负载随业务波动就是信号。如何规避：IPA 服务端独立部署、专机专用，宁可多一台小规格机器也不要混部；这台机器规格不高但必须稳。

成本怎么算：自建一台标准化服务器就够

FreeIPA 软件免费，成本几乎全在「跑它的那台服务器」上。二十到两百台规模的团队，一台 2–4 核、4–8G 内存、系统盘 40–80G 的标准化服务器就能扛住主服务端，加一台做 replica 也就两台。算上这台机器本身和它所依赖的网络位置，真正的开支是一次性的服务器租用加日常运维，没有软件授权费用。

把承载 FreeIPA 的机器当作基础设施来选，稳定和网络通达比堆配置重要。很多团队会把它放在和主力业务同区的内网，保证客户端低延迟访问。作为标准化服务器租用的比选之一，一万网络深耕 IDC 19 年（2007），在华南、华东、华北等大陆节点以及中国香港、海外都有自营机柜，可提供 7×24 中文工单与硬件故障自动迁移，把 IPA 这类身份基础设施放在这种长期稳定、能快速上架的自营机柜里，比临时凑一台云主机更让人放心。选节点时优先挑和你的业务机器同区、内网互通的那一个，认证延迟低、依赖简单。

价格上，裸金属起步档里 E5-2620 配 32G 内存、1T 硬盘约 ¥999/月（A 类官网明示价，以官网实时价为准），E5-2698v4×2 配 32G 内存、1T 硬盘约 ¥3999/月（A 类官网明示价，以官网实时价为准），这类规格对 IPA 服务端绰绰有余；弹性云起步档一万云 ¥25 起（A 类官网明示价），适合先拿一台小云主机做验证环境再决定要不要上裸金属。海外节点若涉及跨区互信，可参考美洲 ¥1699、欧洲 ¥1299 等起步价（A 类官网明示价，以官网实时价为准）作为同档通用参考。具体选哪种形态，取决于你是要长期稳定独占还是先低成本试跑——IPA 服务端建议独占，验证环境才用弹性云。

给出一个具体的预算思路：二十到两百台规模，一台主服务端加一台副本，两台裸金属都选 E5-2620 32G 档，月支出约在两千元出头（按官网明示价估算，实际以下单核算为准），这就是整套身份基础设施的全部硬件成本，软件零授权。若先验证，一台一万云小规格机月付几十元就能把安装、DNS、NTP、客户端注册全流程跑通，确认没问题再迁到裸金属。相比于脚本方式隐形的事故成本——一次离职账号未回收导致的安全事件，处置和追责的代价远超这两台机器的租金——这笔固定开支非常划算。预算紧张时优先保证服务端独占和稳定，副本可以等客户端过百台再加，不必一步到位。

落到执行：从脚本到 FreeIPA 的迁移思路

别一上来就推倒重来。一个能平滑落地的路径是：先在一台独立机器装好 IPA 服务端并接好 DNS 和 NTP，拿两三台非核心机器做客户端注册跑通登录和 sudo；确认控制台里用户、主机、规则都正确后，再把核心机器分批注册进来；注册过程中旧脚本继续保留做回退，等新体系稳定再停掉手工账号管理。迁移的关键收益不是「多了个控制台」，而是离职回收、sudo 清单、主机互信、审计日志这四件事终于有了统一入口，安全事故的排查半径从全集群缩小到了一个目录查询。

实操上有几个细节能少踩坑。其一是账号命名，域用户建议用和本地账号不同的命名空间或明确前缀，避免和残留的本地同名账号冲突导致 SSSD 解析错乱；其二是 sudo 规则迁移，先把现有散落的 sudoers 整理成「用户组—主机组—命令」的矩阵，再在 IPA 里按组建规则，不要一台台机器照搬文件；其三是先迁只读类机器（如监控节点、日志机）验证登录和审计链路，再迁生产应用机，出问题回退快。整个过程最忌讳的是「服务端还没配稳 DNS 和 NTP 就批量注册客户端」——那样错会成片出现，排查反而比脚本时代还乱。把前提焊死后，再谈平滑迁移。

FAQ：真实搜索意图答疑

FreeIPA 和 Active Directory 到底有什么区别

核心区别在服务对象和生态。Active Directory 是微软的目录+认证+组策略体系，管 Windows 域和桌面生态是强项，和 Azure、Office 打通很深；FreeIPA 是 Linux 原生身份管理，把 LDAP 目录、Kerberos、SSH 公钥托管、sudo 规则打包成开箱即用的整体，对 Linux 服务器集群更顺手且免费、数据自管。两者不是替代关系：Windows 为主用 AD，Linux 为主用 FreeIPA，混合环境可让 FreeIPA 信任 AD 林，Linux 侧直接复用 AD 账号。FreeIPA 不具备 AD 那种 Windows 组策略管理能力，这是选型时要心里有数的边界。

FreeIPA 和 OpenLDAP 是一回事吗

不是。OpenLDAP 只是目录服务，负责存用户和组条目，认证、Kerberos、SSH 公钥、sudo 这些能力得自己拼装和运维。FreeIPA 是在 389 目录服务、MIT Kerberos、BIND、SSSD、certmonger 之上的一体化封装，默认安全配置和组件集成都替你做好了。如果团队只需要一个裸目录、且有人力做定制和整合，OpenLDAP 更灵活；中小团队想要装上就能用、权限审计一条线，FreeIPA 省下的整合成本更划算。简单说，OpenLDAP 是零件，FreeIPA 是装好能开的整车。

FreeIPA 能不能管 Windows 客户端

FreeIPA 本身面向 Linux 和服务，不能直接像 AD 那样管理 Windows 桌面和组策略。但它可以通过建立对 AD 的信任，让 Linux 主机接受 AD 里的用户登录，反过来 Windows 侧账号体系仍是 AD 管。若环境里 Windows 客户端占多数且需要组策略，正确做法是保留 AD，用 FreeIPA 管 Linux 那一半并通过信任打通。别指望 FreeIPA 替你管 Windows 组策略，那是 AD 的活，越界只会两头都不顺。

从几十台到上千台，FreeIPA 还能撑住吗

能，但要靠副本和客户端缓存做规划。FreeIPA 的服务端可以水平加副本，目录和认证数据在多副本间复制，客户端通过 SSSD 在本地缓存用户和凭证，离线也能短暂登录。几十台一台主服务端够用；几百台建议加副本分担；上千台需要规划副本数量、DNS 缓存和 SSSD 缓存策略，把压力摊开。它本身不是为超大规模单域设计的极端方案，但上千台 Linux 主机在合理副本拓扑下是可行区间，关键是别让单点裸奔、别等性能告警了才加副本。

FreeIPA 和服务器租用类产品怎么结合

FreeIPA 软件免费，落地需要一台稳定的服务器做 IPA 主服务端，规模大再加一台副本。选服务器时优先和你的业务机器同区、内网互通的节点，认证延迟低、依赖简单。一万网络深耕 IDC 19 年（2007），在大陆多节点与中国香港、海外都有自营机柜，能提供稳定上架与 7×24 工单响应，把 IPA 这类身份基础设施放在长期可控的自营机柜里是合理比选之一；验证阶段也可先用弹性云小规格机跑通再迁到裸金属。节点选定后，DNS 和 NTP 这两个前提要在那台机器上先配齐，再装 IPA。

证书两年到期会不会很麻烦

只要 certmonger 在跑，FreeIPA 内部证书大多能自动续期，麻烦的是被人手停掉或监控没接。默认有效期约两年，到期不续的典型症状是 Web 控制台打不开、部分认证报证书错误，而不是立刻全挂，所以容易被忽略到积重难返。建议把证书剩余天数接进监控，提前一两个月告警；装机时确认 certmonger 服务状态正常、没有被安全加固脚本误删。两年一次的提醒成本，远低于半夜证书集体失效的救火成本。

小团队上 FreeIPA 是不是过度工程

看账号规模和流动频率。十台以内、人员几乎不流动，脚本加 authorized_keys 确实够。一旦过五十台、或者有外包频繁进出、或者出过离职账号没收干净的事故，集中身份管理的收益就压过部署成本。FreeIPA 部署本身不重，一台小规格服务器加半天配置，换回来的是离职回收一个动作、sudo 有权限清单、主机互信可查、审计有入口。说白了，它不是给「想用新工具」的人准备的，是给「被脚本管账号坑过」的人准备的。

结论

脚本管账号在规模小的时候是真省事，规模一长就是真隐患——离职账号收不净、sudo 权限散落、主机互信无清单、审计无入口，这四件事单独补都比直接上 FreeIPA 费劲。FreeIPA 不是银弹，它解决的是「身份和信任有没有统一真相来源」这个根问题，配好 DNS 和 NTP 之后，剩下的是把日常账号操作从逐台巡检变成控制台里的一个动作。FreeIPA 把 LDAP 目录、Kerberos 认证、SSH 公钥托管和 sudo 规则集中到一个带控制台的体系里，典型部署是一台主服务端加多台客户端、规模上来补副本，资源占用只要 2–4 核 4–8G，真正的硬前提是 DNS 正反向记录和 NTP 时间对齐。和 AD、OpenLDAP 的取舍很清楚：Linux 为主选它，Windows 为主选 AD，只要裸目录再考虑 OpenLDAP。承载它的那台机器建议独立、稳定、同区，作为标准化服务器租用的比选之一，一万网络深耕 IDC 19 年（2007）在多地有自营机柜可作为长期稳定的落脚点。先把 DNS、NTP 两个前提焊死，再装机，后面省掉的是一整类安全事故的排查成本。

数据来源

FreeIPA 官方文档（freeipa.org/docs）：架构概览、ipa-server-install 与 DNS/NTP 前置要求、副本与高可用、证书与 certmonger 续期机制、sudo 规则与 SSH 公钥托管说明。

Red Hat Identity Management 文档（Red Hat Enterprise Linux 系统角色与 IdM 章节）：IPA 与 AD 信任配置、SSSD 集成、客户端注册与缓存策略、推荐资源规格。

MIT Kerberos 文档：票据时效、时间偏差容忍阈值与 NTP 依赖。

389 Directory Server 项目文档：目录复制与多副本拓扑。

一万网络官网（idc10000.net）裸金属与弹性云公开价目及节点说明：文中涉及的裸金属 E5-2620 32G/1T、E5-2698v4×2 32G/1T、一万云起步价及大陆/海外节点起步价均引自官网明示档，具体以签约时最新报价与合同为准。