GCP VPC, firewallregels en Cloud NAT op STACKIT

Eén firewallregel, herschreven als security group

Een klein netwerk dat voor deze pagina is geschreven en op 4 november 2026 door StackToIT is beoordeeld: twee subnetworks, vier firewallregels, een Cloud Router met Cloud NAT en een gereserveerd adres. Links: de HTTPS-regel uit de invoer. Rechts: de resourceblokken van de STACKIT-Terraform die de run schreef; de reviewcommentaren boven elk blok in het bestand zijn hier weggelaten.

resource "google_compute_firewall" "web_https" {
  name      = "allow-https-web"
  network   = google_compute_network.core.name
  direction = "INGRESS"
  priority  = 1000

  allow {
    protocol = "tcp"
    ports    = ["443"]
  }

  source_ranges = ["0.0.0.0/0"]
  target_tags   = ["web"]
}

resource "stackit_security_group" "web_https" {
  project_id = var.project_id
  name       = "allow-https-web"
}

resource "stackit_security_group_rule" "web_https_allow_https_web" {
  project_id        = var.project_id
  security_group_id = stackit_security_group.web_https.security_group_id
  direction         = "ingress"
  ether_type        = "IPv4"
  ip_range          = "0.0.0.0/0"
  port_range = {
    max = 443
    min = 443
  }
  protocol = {
    name = "tcp"
  }
}

• Richting, bereik en poort worden overgenomen

  De ingress-regel voor TCP 443 vanaf 0.0.0.0/0 wordt één regel van een security group met hetzelfde bereik en dezelfde poort.

• De doeltag wordt niet overgenomen

  De bron past de regel toe op instances met de tag web. STACKIT kent geen tagselector, dus de run laat de beslissing open: welke netwerkinterfaces deze groep vermelden.

• Prioriteit vervalt

  Regels van een STACKIT-security group hebben geen prioriteit, en de run legt vast dat de volgorde waarop de bron steunde niet wordt overgenomen.

Cloud NAT en de uitgaande weigerregel

Het deel van het netwerk waar de modellen het meest verschillen. Links: het einde van het invoerbestand, van de regel die uitgaande SMTP weigert via de Cloud Router en het gereserveerde adres tot de NAT-gateway. Rechts: het ene blok dat de run daarvoor schreef.

resource "google_compute_firewall" "deny_egress_smtp" {
  name      = "deny-egress-smtp"
  network   = google_compute_network.core.name
  direction = "EGRESS"
  priority  = 900

  deny {
    protocol = "tcp"
    ports    = ["25"]
  }

  destination_ranges = ["0.0.0.0/0"]
}

resource "google_compute_router" "core" {
  name    = "core-router"
  region  = "europe-west3"
  network = google_compute_network.core.id
}

resource "google_compute_address" "nat" {
  name   = "core-nat-ip"
  region = "europe-west3"
}

resource "google_compute_router_nat" "core" {
  name                               = "core-nat"
  router                             = google_compute_router.core.name
  region                             = "europe-west3"
  nat_ip_allocate_option             = "MANUAL_ONLY"
  nat_ips                            = [google_compute_address.nat.self_link]
  source_subnetwork_ip_ranges_to_nat = "ALL_SUBNETWORKS_ALL_IP_RANGES"
}

resource "stackit_public_ip" "nat" {
  project_id = var.project_id
}

• Het gereserveerde adres wordt een publiek IP

  De run deelt het in als DIRECT en merkt op dat het adres zelf verandert, dus DNS-records en allowlists van partners moeten worden bijgewerkt.

• De NAT-gateway heeft geen blok

  Uitgaande toegang voor servers zonder publiek IP maakt deel uit van het STACKIT-netwerk. De run meldt dat een vast uitgaand adres dat partners op hun allowlist hebben, niet zo blijft bestaan.

• De weigerregel is een redesign

  Een security group staat alleen toe. De run deelt de regel in als REDESIGN en legt uit hoe u het doel opnieuw opbouwt met expliciete egress-regels.

Hoe de netwerkomgeving wordt gekoppeld

Elke rij is een eenheid van de run op de voorbeeldomgeving: tien resources onderzocht, negen migratie-eenheden. De Cloud Router heeft geen eigen eenheid; daar staat de NAT-configuratie.

Klassen zoals de run ze bepaalde. Het voorbeeld stelt geen lockbestand in voor de Google-provider, dus elke eenheid blijft hooguit op zekerheidsniveau MEDIUM; de uitgaande weigerregel krijgt LOW.

Waar de twee modellen in de praktijk verschillen

De kolom Google Cloud volgt de documentatie over VPC-firewalls en Cloud NAT; de kolom STACKIT volgt de documentatie over security groups, publieke IP-adressen en netwerken, en de runuitvoer waar dat wordt vermeld.

De volgorde die werkt

Algemene praktijk, gekoppeld aan de bestanden die de run schrijft.

1. 01

   Som de regels op naar wat ze selecteren

   Lees elke firewallregel op doel (alle instances, tags of service accounts), richting en prioriteit. De run behoudt één security group per regel en de bevindingen geven aan welke regels op tag selecteren.

2. 02

   Bepaal de vorm van het netwerk

   Subnetworks worden netwerken. Moeten ze elkaar privé bereiken over projecten heen, dan sluiten ze aan op een Network Area; de bereiken komen dan uit het gebied.

3. 03

   Koppel groepen aan interfaces

   De handmatige stappen van de run, in execution/manual/actions.md, vermelden welke netwerkinterfaces elke groep noemen. Los elke tag op in een groep of in bereiken.

4. 04

   Bouw de weigerregels opnieuw op

   Verwijder voor een egress-weigering na de apply de standaard egress-regels en maak een egress-regel voor elke bestemming die de bron nog toestaat.

5. 05

   Leg het uitgaande adres vast

   Als een partner uw NAT-adressen op een allowlist zet, geef dan de servers die de partner aanroepen een publiek IP en stuur het nieuwe adres vóór de cutover.

6. 06

   Controleer na een minuut

   Test de bereikbaarheid met de regels op hun plek en wacht tot ze zijn doorgevoerd voordat u een regel beoordeelt.

Vragen die netwerkteams stellen

Bronnen

• Google Cloud: VPC-firewallregels
• Google Cloud: overzicht van Cloud NAT
• STACKIT-documentatie: concepten van security groups
• STACKIT-documentatie: concepten van publieke IP-adressen
• STACKIT-documentatie: concepten van Network Area
• Google Cloud: IAP gebruiken voor TCP-forwarding
• STACKIT Terraform-provider v0.121.0: stackit_security_group_rule