[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 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
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 がそれを受け取れば完了です。

索引モデルが issue の本文から書いたものです。

説明

Bug Framework - FedRAMP High Framework - FedRAMP Moderate Gemini - Enterprise Level of Effort - Low Priority - Medium 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時間
マージ済み PR（30日）
75

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

google/stellar-engine のほかの issue

google/stellar-engine の issue をすべて見る

似ている issue

DevOps の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。