IAP TCP：SSH、权限与连接诊断

验证：未记录

适用版本: 未记录
验证范围: 尚未登记验证记录。

本机通过 IAP tunnel 登录 VM，无需给 VM 分配公网 IP。

常用操作#

替换为实际资源；本段不依赖 lab.env。

PROJECT_ID='REPLACE_PROJECT_ID'
ZONE='REPLACE_ZONE'
VM='REPLACE_VM'

gcloud compute ssh "$VM" --project="$PROJECT_ID" \
  --zone="$ZONE" --tunnel-through-iap
# 失败时退出远程 shell，在本机对同一目标加 --troubleshoot 诊断。

容易踩的坑#

IAP TCP tunnel 不是全 VPC VPN。 它只转发指定 TCP 连接；SSH 登录成功不代表本机已能直连私有 GKE endpoint，也不证明 VM 的 NAT 出站正常。

TCP forwarding 不转发 UDP，也不把 load-balanced target 当普通 VM。

配置说明与完整示例（按需展开）

前置：已有可用的 Compute Engine VM；需要创建实验 VM 时先做 Compute Engine。本页以 Compute Engine VM 的 SSH 登录为实验，不是 TCP forwarding 的完整目标清单；GKE 私网管理机也使用同一机制。命令在你的电脑上执行，未在本轮操作中连接或修改云端资源。

IAP 在这条链路中做什么#

IAP TCP forwarding是 Google 托管 IAP 服务的一项功能，按 Google 身份授权建立到 VM 指定 TCP 端口的加密隧道。SSH 是登录 Linux 操作系统的协议，通常使用端口 22。IAP 负责隧道，SSH/OS Login 负责机器登录。

你的电脑（gcloud + SSH 客户端）
  → Google IAP：核验隧道访问权限
  → VM 内部 IP:22：SSH 登录
  → VM 上的 shell

TCP forwarding 仅转发指定 TCP 连接，不支持 UDP 或 load-balanced targets；VM 有无公网 IP 均可使用。它不提供全 VPC 的 VPN 路由；GKE runner 是独立管理 VM，kubectl 登录后在其上运行。TCP forwarding

权限、网络和操作系统分别检查#

层次	要满足什么
隧道 IAM	登录者具备 `roles/iap.tunnelResourceAccessor`（IAP-secured Tunnel User）或等价权限；可限定目标 VM，并结合条件限定目标端口
OS Login	VM 启用 `enable-oslogin=TRUE`；用户具有 `roles/compute.osLogin`，需要 sudo 时使用 `roles/compute.osAdminLogin`
资源查询	gcloud 还需相应项目/VM 查询权限；使用 VM 级授权时核对 CLI 所需的 Project 级查询权限
VM Service Account	VM 挂载 Google SA 时，按 OS Login 的要求核对登录者在该 SA 上的 `roles/iam.serviceAccountUser`
VPC 防火墙	允许 IAP TCP forwarding 来源 `35.235.240.0/20` 到目标 VM 的 TCP 22
VM 本身	处于运行状态，sshd 正常监听，主机防火墙允许连接
本机网络	能访问 IAP 所需的 Google 服务，未被公司代理或出口策略阻断

OS Login 管理 Linux 登录与 sudo，须独立于 tunnel IAM 授权。IAP Policy Admin 用于管理策略，普通连接用户不需要；external users 另核对 OS Login 要求。

Console 中可在 Security → Identity-Aware Proxy → SSH and TCP resources 选择目标 VM 并管理 IAP 访问授权；OS Login 和适用的 Service Account User 权限仍单独配置。不要把 Web resource 的授权当作 TCP target 的权限。

网络标签如 iap-ssh 是本系列用来让防火墙规则匹配 VM 的标记，不是登录身份，也不能代替 IAP IAM 授权。

本系列实验如何复用#

实验	VM	Zone 变量	网络标签 / 防火墙规则
Compute Engine	`lab-vm`	`ZONE`	`iap-ssh` / VPC 实验中的 `lab-iap-ssh`
GKE Standard	`orders-gke-runner`	`RUNNER_ZONE`	`orders-gke-runner` / `orders-gke-iap`

两篇实验负责创建各自 VM 和网络规则，本页不重复创建。规则必须作用在目标 VM 所属网络，并匹配正确标签。只添加 IAP 放行规则，不会自动关闭同一 VM 上其他已有的 SSH 入口。

登录与验收#

在本机设置已经创建好的目标信息。下面示例连接 Compute Engine 实验的 lab-vm：

source lab.env
IAP_VM=lab-vm
IAP_ZONE="$ZONE"

gcloud compute ssh "$IAP_VM" \
  --project="$PROJECT_ID" \
  --zone="$IAP_ZONE" \
  --tunnel-through-iap

--tunnel-through-iap 显式选择 IAP 隧道。进入 shell 后，命令是在远程 VM 上执行；运行 hostname 确认所在机器，用 exit 返回本机。本机的环境变量不会自动复制到远程 shell。

如果只想执行一条验收命令后退出：

gcloud compute ssh "$IAP_VM" \
  --project="$PROJECT_ID" \
  --zone="$IAP_ZONE" \
  --tunnel-through-iap \
  --command='hostname'

GKE 场景改为 IAP_VM=orders-gke-runner 和实际 runner Zone，登录后的工具安装与 kubeconfig 配置继续看 GKE Standard。

SSH 成功不代表 VM 可以访问互联网。 VM 主动访问外部网站还需要适用的出站路由、NAT 等条件；Private Google Access 用于支持的 Google API，不能替代普通互联网出口。

只需要 TCP 隧道时#

gcloud compute ssh --tunnel-through-iap 已处理 SSH 所需隧道。若要观察独立 tunnel，可在本机开一个终端，将 localhost:2222 转发到上述 VM 的 SSH 端口：

gcloud compute start-iap-tunnel "$IAP_VM" 22 \
  --project="$PROJECT_ID" \
  --zone="$IAP_ZONE" \
  --local-host-port=localhost:2222

22 是目标 VM 端口，2222 是本机监听端口；保持该终端运行。客户端连接本机端口后，仍需目标 SSH 的有效认证。这个命令不会自动配置 OS Login 用户名和 SSH key，日常 Linux 登录优先使用前面的 gcloud compute ssh。

Windows RDP 同样使用 TCP tunnel，须选择实际 RDP 端口并满足 Windows 登录、firewall 与 IAP 条件。

连接失败怎么分层判断#

现象	优先检查
IAP 明确拒绝连接	当前 Google 身份、隧道权限、IAM 条件、目标项目/VM
隧道建立失败或连接端口超时	IAP 来源防火墙、VM 状态、目标端口、sshd、本机出口
SSH Permission denied	OS Login、系统账号/SSH 配置、VM SA 的使用权限
登录成功但 sudo 失败	是否确实需要并获得 OS Admin Login
SSH 成功，curl 外网失败	VM 出站 DNS、路由、NAT、防火墙；与入站隧道分开查
runner 上 kubectl 失败	控制面 endpoint、Authorized networks、认证插件、IAM/RBAC；不只检查 IAP

在确认目标后，可运行 gcloud 的连接诊断：

gcloud compute ssh "$IAP_VM" \
  --project="$PROJECT_ID" \
  --zone="$IAP_ZONE" \
  --tunnel-through-iap \
  --troubleshoot

收尾#

SSH 中 exit 结束远程会话，独立 TCP 隧道用 Ctrl+C 结束。关闭隧道不会删除 VM，也不会撤销 IAM。VM、磁盘、快照按 Compute Engine 或 GKE 原实验清理；仅撤销本次授予的权限，不删除其他用户共用的网络规则。