[Bug] 2-networking-a-fedramp: the NVA return routes still omit the proxy-only subnets, so traffic from a regional managed load balancer's proxies cannot get replies from the internet

未关闭 适合新手
  • 哪里不对？
#396 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

还没有人认领这个 Issue。

评估

难度
2/5
预计耗时
1-3 小时
新手友好度
70/100
Issue 类型
缺陷
描述清晰度
描述清楚
活跃度
活跃
技术栈
gcp, terraform
领域
infrastructure, networking

调研方向

从 fast/stages-aw/2-networking-a-fedramp/nva.tf 中 local.routing_config 的 landing 条目开始，该条目仅根据 var.subnets 构建路由，然后将其与 branch-net-envs.tf 中的 subnets_proxy_only 以及 variables.tf 中的 var.proxy_subnets 进行比较。当每个环境的 proxy-only CIDR 都包含在 landing 路由中，并且 modules/cloud-config-container/simple-nva/cloud-config.yaml 中的 NVA 虚拟机 cloud-config 接收到该 CIDR 时，即视为完成。

由索引模型根据 Issue 内容生成。

描述

Bug Framework - FedRAMP High Framework - FedRAMP Moderate Gemini - Enterprise Level of Effort - Low Priority - High Scope - Blueprint Scope - Fast Scope - Module

Bug Description

PR #269 (closing #146) builds the NVAs' trusted-side return routes from every tenant subnet of every environment. The proxy-only subnet that branch-net-envs.tf creates in each environment spoke (subnets_proxy_only, CIDR from var.proxy_subnets[<env>], name proxy-<regions.primary>) is still not among them: the landing entry of local.routing_config in nva.tf reads var.subnets only (if s.tenant != null), and nva.tf never references var.proxy_subnets.

The spokes have their default routes deleted (delete_default_routes_on_create = true) and reach the internet through the default-route-nva route (0.0.0.0/0 → the NVA internal load balancer) and Cloud NAT on the DMZ VPC. A regional managed load balancer in a spoke — for example a regional internal Application Load Balancer whose backend is a regional internet NEG, which is how blueprints/gemini-enterprise reaches the Google-hosted Gemini Enterprise endpoint (gemini-stage-0/network.tf: an INTERNET_FQDN_PORT NEG for vertexaisearch.cloud.google.com) — originates its backend connections from the Envoy proxies in that spoke's proxy-only subnet. Those packets leave through the NVA and are masqueraded on the DMZ interface. The reply comes back to the NVA, is un-NATed to the proxy-only address, and — because the guest has no route for that range on the landing interface (simple-nva's cloud-config adds ip route add <cidr> via <eth1 gateway> only for the listed routes) — follows the VM's default route back out the untrusted interface. The connection hangs and times out; nothing errors at apply time, and DNS keeps resolving, so it reads as a firewall or DNS problem.

Environment and Deployment Context

  • Stellar Engine Version/Commit: v5.2.0 (82153050); unchanged on main @ e2396049 (2026-11-01). fast/stages-aw/2-networking-a-fedramp/nva.tf lines 28-37 (the landing routes), branch-net-envs.tf lines 114-119 (subnets_proxy_only; delete_default_routes_on_create at line 107), variables.tf lines 257-268 (proxy_subnets, one entry required per envs_folders key), modules/cloud-config-container/simple-nva/cloud-config.yaml lines 57-59 (guest routes only for the listed CIDRs).
  • Deployment Type:
    • US Region Restricted (e.g., Access Policy constraint)
    • FedRAMP Moderate
    • FedRAMP High
    • DoD IL4
    • DoD IL5
    • Stand-alone / Custom
  • FAST Stage (if applicable): 2-networking-a-fedramp

Steps to Reproduce

  1. Deploy Stages 0-2 with 2-networking-a-fedramp at v5.2.0, with proxy_subnets set for each environment (required by the variable's validation).
  2. In a spoke, deploy a regional managed load balancer whose backend is a regional internet NEG (for example gemini-stage-0 and gemini-stage-1 with the internal deployment type).
  3. Send a request to the load balancer from a client in the spoke.
  4. On an NVA: ip route get <an address in the proxy-only CIDR> shows the route via eth0 (the DMZ side), not eth1.

Expected Behavior

Every subnet whose egress is routed through the NVAs — tenant subnets and proxy-only subnets — gets a trusted-side return route, so replies to the load balancer's proxies are delivered.

Actual Behavior

Replies to the proxy-only range leave the NVA on the untrusted side; the load balancer's backend connections time out.

Relevant Logs and Errors

None at deploy time: the plan and apply succeed. The symptom is the request hanging at the load balancer.

Additional Context

  • Suggested fix — add each environment's proxy-only CIDR to the landing routes: 
    routes = flatten([
  for k, v in var.envs_folders : concat(
    [for s in try(var.subnets[lower(k)], []) :
      module.env-spoke-vpc[k].subnets["${s.region}/${s.name}"].ip_cidr_range
      if s.tenant != null],
    [var.proxy_subnets[k]]
  )
])
    (var.proxy_subnets is keyed by the envs_folders key itself, not its lower-cased form, and its validation already guarantees an entry for every environment.)
  • #146 reported the tenant-subnet half; it did not mention the proxy-only subnets, which is why #269 did not cover them.
主要语言
HCL
星标
61
派生
28
平均合并
1 天 17 小时
30 天内合并 PR
74

环境准备

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

google/stellar-engine 的其他 Issue

查看 google/stellar-engine 的全部 Issue

相似的 Issue

更多 DevOps Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。