openasn/openasn

# 🛰️ OpenASN — 开源 IP 来源情报 **将任何 IP 分类为住宅、移动、托管、VPN、Tor、中继、商业或未知 —— 离线、可解释、无需 API 调用。** OpenASN 是一个开放数据项目：一个合法、干净的离线数据库，用于回答*“这个 IP 到底来自哪种网络？”*。它将宽松许可的 ASN 元数据、IP→ASN 骨干网络、VPN/数据中心覆盖层以及人工校对的修正，整合成小巧的二进制产物（整个 IPv4 仅约 6MB），应用程序可以在几微秒内在本地进行查询 —— 零 API 调用、零单次查询成本，且绝不将用户 IP 发送给任何第三方。 本仓库是**数据集**：精心维护的覆盖层、锁定的上游许可证、公开规范（产物格式、抽查面板、Tier B 获取清单）以及每日夜间发布的版本。它是 OpenASN 项目的核心： | 仓库 | 内容 | |---|---| | [`openasn/openasn`](https://github.com/openasn/openasn) | **本仓库** — 开放数据：校对、规范、来源凭证、发布 | | [`openasn/openasn-pipeline`](https://github.com/openasn/openasn-pipeline) | 编译器：获取 → 合法性/质量门控 → 打包 → 验证 → 发布（通过[本仓库的工作流](.github/workflows/nightly-build.yml)每夜运行） | | [`openasn/openasn-ruby`](https://github.com/openasn/openasn-ruby) | 第一个客户端：`openasn` Ruby gem（未来：`openasn-js`、`openasn-python`……） | 产物格式是公开且与语言无关的（[FORMAT.md](FORMAT.md)） —— 欢迎任何语言的客户端接入。 ## 您将获得什么（每夜发布，通过 [`latest` release](https://github.com/openasn/openasn/releases/latest)） | 文件 | 内容说明 | |---|---| | `openasn-ipv4.bin` / `openasn-ipv6.bin` | 打包好的分类产物：包含类别/角色/标志位的 IP→ASN 骨干网络 + VPN/数据中心范围覆盖层。字节规范：[FORMAT.md](FORMAT.md) | | `asn-categories.csv` | 人类可读的表格：每个 ASN → 组织、国家/地区、类别、网络角色、OpenASN 标志位 (CC0) | | `manifest.json` | 构建 ID、各文件的 SHA-256 值以及完整的来源凭证（上游 URL、许可证、许可证文件哈希值、获取时间） | | `fetch-manifest.json` | Tier B 方案（见“法律设计”），由客户端自行执行 | | `ATTRIBUTION.md` / `SHA256SUMS` | 鸣谢与校验和 | 请始终通过 `releases/latest/download/` 下载 —— 资产每夜更新替换。每周会截取一个带日期的版本用于固定使用。 ## 判定分类法 客户端使用严格的优先级阶梯进行分类（覆盖层优先于 ASN 分类；特殊标识优先于一切）： `residential_isp` · `mobile` · `business` · `hosting` · `vpn` · `tor_exit` · `relay` · `enterprise_gateway` · `education` · `government` · `cgnat` · `private` · `unknown` 确保判定结果可靠的设计说明： - **`relay` 和 `enterprise_gateway` 是一等公民，绝不并入 `vpn`/`hosting`。** iCloud Private Relay 的出口位于 Cloudflare/Akamai 的网络空间内，且 Apple 明确表示应将其视为运营商级 NAT；Zscaler/iboss 的出口代表着整个企业和学区。错误归类这二者都会拦截真实的正常用户。 - **VPN 和数据中心信号是独立的标志位，而非层级关系** —— 实测结果：已知的 VPN 空间中只有约 70% 位于数据中心列表内。这两个覆盖层被分别独立记录。 - **纯粹的 Tier-1 骨干网络空间会被有意分类为 `unknown`**（如 Cogent、Lumen、Arelion 等）：“我们无法判断”胜过一个自信的错误答案。另外四家同时运营着 Tier-1 骨干网络的消费者巨头（AT&T、Verizon、Deutsche Telekom、Liberty Global）则通过人工校对进行了终端确认。完整推理过程见：[DECISIONS.md](DECISIONS.md)。 - **`unknown` 是一项功能。** 混合用途的 ASN（例如也销售 VPS 的 ISP）将保持为 `unknown`，并公开原始的类别/角色，以便由*您*来决定策略。 - **该枚举是一个跨语言的契约，并且是只增不减的**：判定结果永远不会被删除、重命名或重新定义；新结果的添加是通过客户端版本发布完成的（绝不通过数据刷新 —— 产物中只携带范围和标志位，由客户端编译判定映射）。每个 OpenASN 客户端都必须记录相同的保证（[详情](DECISIONS.md)）。 ## 架构：三个层级 ``` Tier A (this repo, in the artifact) Tier B (your server fetches directly) ───────────────────────────────── ───────────────────────────────────── sapics origin-asn (PDDL) backbone Apple Private Relay egress → :relay ipverse as-metadata (CC0) categories Tor Project exits → :tor_exit ipverse as-ip-blocks(CC0) prefixes AWS/GCP/Azure/OCI/DO/… → :hosting+provider X4BNet lists_vpn (MIT) vpn/dc Proton/Mullvad/IVPN/PIA… → :vpn+provider bad-asn-list (MIT) hosting Cloudflare ranges → context flag data/overrides/ (CC0) our layer Zscaler egress → :enterprise_gateway Nord/VPN Gate → opt-in :vpn+provider ``` **Tier A** 来源具有明确的重分发权利，并被编译到发布的产物中。**Tier B** 来源要么在许可证上限制了再发布，要么变动过于频繁而无法打包成每夜更新的文件（Tor 出口节点每小时变化） —— 因此我们发布了*方案*（`fetch-manifest.json`：URL、解析器 ID、更新频率、失败策略），客户端会在运行时直接从原始权威机构拉取。**Tier C**（自带 MaxMind/IP2Location，计划中）完全不经过此流水线。被拒绝的来源目录及其原因（PeeringDB 的 AUP、GPL 列表、ShareAlike 数据库、聚合器重打包等……）记录在项目历史中 —— 简短版本见下一节。 ## 正确解读 OpenASN 标签 面向客户端的 `verdict` 是产品契约。原始 ASN 标签则是上下文参考。 | 字段 | 含义 | 示例 | |---|---|---| | `verdict` | 客户端发出的应用程序层面的判定结果（`residential_isp`、`hosting`、`vpn` 等） | DIGI Spain 家庭宽带 → `residential_isp` | | `category` | 编译进产物的上游 ASN 类别（`isp`、`hosting`、`business` 等） | DIGI Spain → `isp`；Amazon → `hosting` | | `network_role` | 上游路由角色（`access_provider`、`midsize_transit`、`tier1_transit` 等） | Telefónica 零售 → `access_provider`；Cogent 骨干网 → `tier1_transit` | | `openasn_flags` | 额外的 OpenASN 标志位，如 `bad_asn`、`vpn_provider`、`mobile_carrier`、`enterprise_gw`、`cdn`、`hosting_extra` | Microsoft/Amazon 的 ASN 通常带有 `bad_asn` 作为托管网络的佐证 | | `sources` | 运行时的客户端解释，说明哪条规则在判定中生效 | `x4b_dc`、`asn_category`、`aws`、`asn_bad_asn` | 很遗憾，`bad_asn` 在上游命名得有些不尽如人意，但它很有用：它表示该 ASN 属于 `brianhama/bad-asn-list`，这是一个基于 MIT 许可证、经过人工校对的托管/云/托管中心 ASN 列表。在 OpenASN 中，它仅仅是一个基础设施信号。它并不意味着该 ASN 具有恶意、不安全或理应被封禁。 `category=isp` 和 `verdict=residential_isp` 故意使用了不同的词汇。类别描述的是 ASN；而判定结果是在应用优先级规则后，更安全的面向应用标签。如果是纯 Tier-1 骨干网络空间，真实的 ISP 也可能被标记为 `unknown`；而如果 VPN 覆盖层的匹配更加具体，一个托管 ASN 也可能变成 `vpn`。 ## 服务商扩充路线图 OpenASN 的 MVP 优先回答最重要的问题：类似人类的接入网络还是基础设施。下一层是服务商归属判定：“这个托管 IP 属于 AWS”或“这个 VPN IP 属于 Mullvad”。公开的来源账本见 [PROVIDER_SOURCES.md](PROVIDER_SOURCES.md)，较慢更新的服务商/运营商调查档案见 [VPN_PROVIDER_DOSSIERS.md](VPN_PROVIDER_DOSSIERS.md)。添加该层时的规则比“我们能不能爬取下来”更严格： - **精确 IP 命中可以设定 `provider`。** 包含观察到的出口 IP 的第一方或许可证清晰的列表，可以产生 `provider: "mullvad"` 或 `provider: "ivpn"`。 - **相邻前缀推断仅供参考。** 在已知 Mullvad 中继所在的同一个 `/24` 网段内看到一个 IP，对分析师来说是有用的上下文，但它绝对不能悄无声息地变成一个服务商判定结果。 - **Tier A 仍然需要重分发权利。** 大多数服务商列表应归入 Tier B 方案，由客户端从原始权威机构获取。 - **每个来源都需要解析器测试、实时冒烟测试用例、更新频率、保留陈旧数据的行为说明以及法律备注。** 此次扩充阶段为 Mullvad（也包括 Mozilla/Firefox VPN 基础设施）、IVPN、Private Internet Access、AirVPN、Windscribe、PrivadoVPN、RiseupVPN、NordVPN（重度选择性加入）和 VPN Gate（选择性加入的公共中继）添加了精确 IP 的 Tier B 方案。它还为 Surfshark、IPVanish、PrivateVPN、PureVPN、TorGuard、FastestVPN、VPNSecure、TunnelBear 和 VPNBook 等服务商发布的域名添加了选择性加入的、基于 DNS 扩展的方案。Apple Private Relay 仍然保持为 `relay`，Cloudflare 网段仅作为上下文参考。公开的来源/档案账

标签：ASN元数据, Homebrew安装, IP地理定位, 安全研发, 离线数据库, 网络分类, 网络情报