阿里雲帳號購買 阿里雲國際站雲服務器內網互通怎麼配置

第一章：先把問題想清楚，互通不等於“隨便開端口”

很多人在做“內網互通”時只關注一件事：把 目标端口开开就行了。可是在雲上，連通性其實由多層條件共同決定：网络是否在同一個邊界里、VPC 內的路由是否通、子網的交換路径是否存在、实例網卡是否在正確的 VPC/交换域、以及安全策略是否允許流量穿過。任意一層沒配置好，就會表現成“連線超時”“ping 不通”“只通部分子網”等難以定位的問題。

因此，配置前你應先回答四個問題：第一，你要互通的是同一個 VPC 還是不同 VPC？第二，這些服務器的內網 IP 所在的網段是否重疊？第三，是否需要跨可用區或跨子網？第四，你預期的互通流量類型是：同端口、特定端口、還是全量內網通信（例如資料庫、RPC、心跳等）。當你把這些想清楚，配置才會有方向，排錯才會有效率。

第二章：基本概念與你需要的“地圖”

1. VPC、子網與交換域

阿里雲國際站的雲服務器通常部署在 VPC（Virtual Private Cloud）內。VPC 是你自己的虛擬網路邊界，子網是 VPC 內的地址劃分單位。只要兩台主機位於同一 VPC，且路由與安全策略允許，它們就能在內網通訊。若位於不同 VPC，則需要借助 VPC 互連（例如 VPC 路由互通、專線或類似能力）。

實務上，你要整理一張清單：A 服務器的 VPC ID、子網 ID、內網 IP；B 服務器同樣資訊；以及它們之間是否需要跨 VPC。

2. 路由表是“道路”，安全組/ACL是“路障”

雲網路裡，路由表決定封包要走哪條路。若目標網段路由缺失，就算安全策略允許，封包也走不出去。安全組（Security Group）與網絡 ACL（Network ACL）則相當於路障：前者常見於实例级，後者偏網段级、規則級更嚴格。

你可以把連通性理解為：封包要先找到路（路由），再通過門禁（安全策略）。因此排錯順序也應是先看路由，再看安全策略。

3. 國際站環境常見差異

不同區域/產品線的界面可能略有差別，但核心邏輯一致：VPC/子網/路由/安全策略。你要做的是在你所使用的區域找到對應的控制台頁面，配置同類項目即可。若你看到“路由表”“安全組”“網絡 ACL”“VPC 互連”等選項，基本就是在解決同一類問題。

第三章：同一 VPC 內的內網互通配置（最常見、最好先做）

如果你的目標兩台（或多台）雲服務器都在同一個 VPC，這通常是最簡單的情況。這節我們以“同一 VPC、不同子網、需要互通”为例講清楚原理與步驟。

步驟 1：確認兩台實例屬於同一 VPC

阿里雲帳號購買 進入控制台，查看每台雲服務器的網絡資訊，確認：

• VPC ID 相同
• 子網 ID 可能不同（可接受）
• 阿里雲帳號購買 內網 IP 所在網段（例如 10.0.1.0/24、10.0.2.0/24）不重疊

若 VPC 不同，你需要跳到後面的跨 VPC 互連章節。

步驟 2：檢查是否使用了路由表（路由缺失是最常見原因之一）

在同一 VPC 下，很多情況默认路由已經足夠，但仍建議你檢查。路由表通常附着在子網或网卡上（依實際產品）。你需要確保：

• 源子網的路由表對“目標內網 IP 所在网段”有路由。
• 目标子网的路由表对“源内网 IP 所在网段”有路由。

举例：A 在 10.0.1.10（网段 10.0.1.0/24），B 在 10.0.2.20（网段 10.0.2.0/24）。则至少需要路由表中存在类似：目的网段 10.0.2.0/24 下一跳指向 VPC 内网的路由目标（具体下一跳类型以控制台为准）。

如果你看到路由表里缺少对对应网段的条目，典型表现是：ping 不通，或某些端口连接超时。

步驟 3：安全组配置（允许入站、必要时也确认出站）

内网互通并不是“默认全通”。通常安全组默认策略偏保守，你需要在源实例与目标实例的安全组中至少完成允许入站的配置。

建议你采用最小权限原则：

• 在 B 的安全组增加入站规则：来源允许 A 的内网 IP 或 A 所在网段，端口允许目标服务端口（例如 3306、5432、8080、22 等）。
• 若你的网络策略还检查出站规则，则在 A 的安全组也确保允许到 B 的对应端口的出站。

如果你要验证“是否真的是连通性问题”，可以先临时放开所有协议（在隔离环境中）来定位，再逐步收紧规则。

步驟 4：确保操作系统内的防火墙放行

雲安全組不等于实例自身防火墙。有些镜像会默认开启防火墙服务（例如 iptables/nftables、firewalld、ufw）。因此你还需要在主机上确认：

• 监听端口的服务已启动（例如数据库服务运行中）。
• 系统防火墙对入站端口放行。
• SELinux（若启用）没有阻止服务访问（较少见于基础互通，但排错时要记得）。

如果你只是想验证二层/三层连通性，可以先用 ping、curl 或 nc 做最小验证，避免把应用问题混在一起。

步驟 5：連通性驗證的“最短路徑”

验证建议按顺序来，节省时间：

• 在 A 上 ping B 的内网 IP。
• 若 ping 被禁用，就用 telnet/nc/curl 检查目标端口是否可达。
• 确认 A 到 B 的路由：在 A 上执行查看路由表（操作系统层面）是否有对应目标网段的路由。

如果 A 能 ping 通 B，但端口连不上，多半是安全组/系统防火墙/服务监听问题；如果连 ping 都不通，多半是路由或安全策略。

第四章：跨子网、跨可用区的细节（常见“看起来同 VPC 仍不通”）

同一 VPC 里跨子网和跨可用区通常不构成障碍，但当你启用了特殊网络能力或更改过默认路由时，就可能出现问题。

1. 子网路由策略被自定义过

当你创建 VPC 后自定义了路由表，把某些目的网段指向了不正确的下一跳，或者干脆删除了默认可达路径，就可能导致跨子网互通中断。你要对照“期望的目的网段”逐条检查路由条目是否存在。

2. 使用了更严格的网络 ACL

如果你的环境使用了网络 ACL（例如 NACL），它可能比安全组更严格。NACL 通常按规则编号处理，允许与拒绝都有可能存在“优先级”。排查时你要查看：

• 入站与出站是否有允许对应源/目的 IP 与端口范围的规则
• 是否存在更优先级的拒绝规则

在复杂环境里，NACL 比安全组更难直观理解，所以建议你尽量先确认是否启用、启用在哪个维度。

第五章：跨 VPC 的内网互通配置（真正的关键章）

当两台服务器不在同一 VPC，你不能期待“只靠安全组就能通”。你需要建立 VPC 互连，让两个 VPC 之间有路由可达。

步驟 1：核对网段是否重叠

这是跨 VPC 互通的底线条件。若 VPC A 的网段是 10.0.0.0/16，而 VPC B 也包含 10.0.0.0/16（或有重叠），路由将无法正确区分目标，互通很容易失败。

你需要确认每个 VPC 的子网网段列表，并保证没有重叠。若重叠不可避免，通常需要重新规划地址（例如扩容网段切分或迁移），否则后续互连会变成反复调参但永远不稳定。

步驟 2：建立 VPC 互连通道

在控制台中找到 VPC 互连（名称可能略有不同），你需要选择互连类型（例如通过路由方式）并配置：

• 互连两端的 VPC 信息
• 互连使用的路由模式（路由表方式、策略方式等，以实际产品为准）
• 互连双方需要共享的路由条目（哪些网段要可达）

如果控制台要求你添加对端网段，务必添加完整的目标子网网段（例如 10.0.2.0/24），避免只添加 VPC 的摘要而导致某些子网不通。

步驟 3：调整两边 VPC 的路由表

互连建立后，关键是让路由表指向互连的下一跳。你需要在 VPC A 的路由表中增加到“VPC B 对应网段”的路由，并在 VPC B 中也增加到“VPC A 对应网段”的路由。

仍以网段为例：

• VPC A：10.0.1.0/24
• VPC B：172.16.2.0/24

那么 A 的路由表需能把目的 172.16.2.0/24 指向互连；B 的路由表需把目的 10.0.1.0/24 指向互连。

若你只配了一边，可能出现“从 A 到 B 通、B 到 A 不通”或“部分端口可达”的假象。

步驟 4：安全组策略要同时满足源与目的

阿里雲帳號購買 跨 VPC 后，安全组仍然需要配置。但“来源 IP”可能不是你以为的某个地址。例如，如果你用的是网关转发或通过互连转发，日志里看到的来源可能仍是原客户端 IP，不过实践中仍建议按安全组允许对方的内网网段（而不是只允许单点 IP，除非你很确定）。

• 在目标实例（B）安全组允许入站：源为 A 的内网网段或 A 实例 IP，端口为服务端口。
• 在源实例（A）安全组确保出站策略不阻断（若你的安全组开启了出站限制）。

如果你使用了多实例或多子网，最稳妥的做法是按“网段级别”授权，而不是每增加一台就手工加规则。

步驟 5：验证与观测：从三层到四层

建议你先做三层验证，再做四层验证：

• 三层：ping（如果目标系统允许 ICMP）或用 traceroute 看路径是否存在。
• 四层：用 nc/telnet/curl 指定端口验证。

阿里雲帳號購買 如果三层不通，优先怀疑路由表或互连是否生效；如果三层通但端口不通，优先查安全组与实例防火墙；如果端口通但服务不正常，再看应用层。

第六章：把配置做成“可持续维护”的样子

真正上线后，内网互通不是一次性完成的事情。你后续可能新增服务器、调整网段、替换实例、做灾备迁移。若你只靠“临时放开安全组”，将来会越来越难维护。

1. 统一命名与记录：网段清单、端口清单

建议你维护两份清单：

• 网络清单：VPC/子网/实例/内网 IP/网段
• 服务清单：需要互通的端口、协议、服务归属（例如数据库只允许从应用子网来）

这样你新增机器时能快速判断要加哪条规则，而不是在控制台里“试错”。

2. 尽量用网段授权而不是单点授权

阿里雲帳號購買 单点授权能更精确，但运维成本高。若你的系统结构稳定，可以按“应用子网网段”授权，既保留安全边界，又降低规则数量。

3. 分阶段放行，先打通再收口

排障时你可能会先放开以缩小问题范围。建议在验证通过后回到最小权限，避免长期存在过宽规则。

第七章：常见故障排查清单（照着查通常能定位）

当你遇到“内网互通失败”，不要从应用层开始猜。下面给你一套实战式排查顺序：每一步都用“可观测证据”来判断。

1. ping 不通

• 检查是否跨 VPC：若跨 VPC，先确认互连是否建立且路由是否指向对端网段。
• 检查路由表：源子网到目的网段是否有路由，目的子网回程是否也有路由。
• 检查安全组：是否禁止 ICMP（若你用安全组规则严格限制协议）。
• 检查实例系统防火墙：有些镜像会屏蔽 ICMP。

阿里雲帳號購買 2. ping 通但端口不通

• 检查安全组：目标实例的入站规则是否允许源 IP/网段 + 端口。
• 检查出站策略：如果出站也被限制，源实例是否允许到目的 IP + 端口。
• 检查操作系统防火墙：端口是否被 ufw/iptables 放行。
• 检查服务是否监听：服务绑定在 0.0.0.0 还是只绑定了 localhost，导致外部访问失败。

3. 只通一台或只通部分子网

• 可能路由只添加了部分网段。
• 可能安全组按实例 IP 精确授权，新增实例未添加。
• 可能存在 NACL 拒绝某些源网段或端口范围。

4. traceroute 显示路径异常

• 通常是路由表指向错误下一跳，或互连尚未生效。
• 也可能是目的网段重叠导致回程不清晰。

5. 重叠网段导致“永远不稳”

若你发现偶尔能通、偶尔不通，尤其是跨 VPC 场景，重叠网段是高概率原因。路由在不同设备上可能选择不同匹配，从而造成不一致。

第八章：给你一套可照做的“模板思路”（不依赖界面细节）

为了让你在阿里雲國際站上更快落地，这里用模板化方式整理：

模板 A：同一 VPC 内互通

• 确认 VPC 相同、网段不重叠
• 检查源/目的子网路由表对彼此网段是否可达
• 目标实例安全组放行：来源为对方内网 IP/网段，端口为服务端口
• 源实例安全组出站不阻断（若有出站限制）
• 实例操作系统防火墙放行并确保服务监听
• 用 ping 与端口探测验证

阿里雲帳號購買 模板 B：跨 VPC 互通

• 阿里雲帳號購買 确认两 VPC 网段不重叠
• 建立 VPC 互连
• 两边路由表都添加到对端网段的路由（回程也要有）
• 目标实例安全组放行：来源为对方内网网段，端口为服务端口
• 源实例出站策略允许（若有限制）
• 操作系统防火墙与服务监听正常
• 先三层后四层验证

結語：真正的互通，是“路由 + 策略 + 端口”三者同时正确

阿里雲國際站的雲服務器內網互通，本质上不是单一按钮设置，而是网络连通性的整体设计。你要做的不是“猜哪里没开”，而是理解每一层在干什么：路由表决定包能不能走到对端，安全组/ACL 决定包能不能穿过门禁，最后实例系统与服务本身决定端口有没有真正响应。按本文给出的逻辑与排查顺序走，通常就能把问题从“不确定”变成“可验证”，进而稳定地完成配置与上线。