Cloud-Netzwerk-Migration zu STACKIT: Routing, VPN, DNS und Firewalls

Ein Site-to-Site-VPN, umgesetzt

Ein für diesen Leitfaden geschriebenes Demo-Netzwerk, von StackToIT am 4. November 2026 bewertet: eine VPC, zwei Subnetze, ein NAT-Gateway, ein VPN zu einem Büro und eine private DNS-Zone. Links die VPN-Ressourcen der Eingabe, rechts das STACKIT-Terraform, das der Lauf dafür geschrieben hat, ohne die Prüfkommentare der Datei.

resource "aws_vpn_gateway" "office" {
  vpc_id = aws_vpc.core.id
}

resource "aws_customer_gateway" "office" {
  bgp_asn    = 65000
  ip_address = "203.0.113.10"
  type       = "ipsec.1"
}

resource "aws_vpn_connection" "office" {
  vpn_gateway_id      = aws_vpn_gateway.office.id
  customer_gateway_id = aws_customer_gateway.office.id
  type                = "ipsec.1"
  static_routes_only  = true
}

resource "stackit_vpn_gateway" "office" {
  project_id   = var.project_id
  display_name = "office"
  plan_id      = var.vpn_plan_id
  routing_type = "ROUTE_BASED"
  availability_zones = {
    tunnel1 = var.availability_zones[0]
    tunnel2 = var.availability_zones[1]
  }
}

resource "stackit_vpn_connection" "office" {
  project_id   = var.project_id
  display_name = "office"
  gateway_id   = stackit_vpn_gateway.office.gateway_id
  tunnel1 = {
    remote_address            = var.office_peer_address
    pre_shared_key_wo         = var.office_pre_shared_keys[0]
    pre_shared_key_wo_version = 1
    phase1 = {
      encryption_algorithms = ["aes256"]
      integrity_algorithms  = ["sha2_256"]
    }
    phase2 = {
      encryption_algorithms = ["aes256"]
      integrity_algorithms  = ["sha2_256"]
    }
  }
  tunnel2 = {
    remote_address            = var.office_peer_address
    pre_shared_key_wo         = var.office_pre_shared_keys[1]
    pre_shared_key_wo_version = 1
    phase1 = {
      encryption_algorithms = ["aes256"]
      integrity_algorithms  = ["sha2_256"]
    }
    phase2 = {
      encryption_algorithms = ["aes256"]
      integrity_algorithms  = ["sha2_256"]
    }
  }
  static_routes = var.office_static_routes
}

• Aus drei Ressourcen werden zwei

  Das Virtual Private Gateway und die VPN-Verbindung werden zu einem STACKIT-VPN-Gateway mit Verbindung. Das Customer Gateway enthält nur Adresse und ASN des Bürogeräts; der Lauf führt es daher als Support-Ressource der Verbindung und schreibt keinen eigenen Block. Die Adresse des Büros kommt als Variable zurück.

• Geheimnisse bleiben aus der Datei

  Die beiden Pre-Shared-Keys sind Variablen ohne Standardwert und als sensibel markiert. Der Lauf verlangt neue Schlüssel, weil das Gerät vor Ort für den neuen Peer neu konfiguriert wird; die Schlüssel der alten Verbindung gelten nicht weiter.

• Statische Routen werden zur Eingabe

  Die über den Tunnel angekündigten Routen sind eine Eingabeliste (office_static_routes) und keine Vermutung. Die STACKIT-VPN-Dokumentation nennt richtlinienbasiertes Routing, statische Routen und dynamisches Routing über BGP; ob statisch oder BGP, entscheiden Sie mit dem Team, das das Bürogerät betreibt.

Wo der Lauf anhält und fragt: Routen und privates DNS

Aus demselben Lauf. Links die Routingtabelle mit NAT-Route und Route ins Büro sowie die private Hosted Zone. Rechts, wie assessment.json sie festhält (ID, Klasse, Konfidenz und Ziel; die Begründungen sind unten zusammengefasst).

resource "aws_route_table" "app" {
  vpc_id = aws_vpc.core.id

  route {
    cidr_block     = "0.0.0.0/0"
    nat_gateway_id = aws_nat_gateway.core.id
  }

  route {
    cidr_block = "192.168.0.0/16"
    gateway_id = aws_vpn_gateway.office.id
  }
}

resource "aws_route53_zone" "internal" {
  name = "corp.example.internal"

  vpc {
    vpc_id = aws_vpc.core.id
  }
}

{
  "id": "aws_route_table.app",
  "result": {
    "class": "MANUAL_REVIEW",
    "confidence": "LOW"
  }
}
{
  "id": "aws_route53_zone.internal",
  "result": {
    "class": "REDESIGN",
    "confidence": "MEDIUM",
    "target": {
      "service": "self-managed internal DNS (e.g. CoreDNS or BIND on servers or SKE)"
    }
  }
}

• Die Routingtabelle wird für einen Architekten zurückgehalten

  Keine der beiden Routen lässt sich sicher schreiben. STACKIT kennt keine NAT-Gateway-Ressource, daher wird die Standardroute zum NAT-Gateway zurückgehalten, und die feste Ausgangsadresse des Gateways bleibt nicht erhalten. Die Route ins Büro läuft über die VPN-Konfiguration, die die STACKIT-VPN-FAQ als Ort für das VPN-Routing nennt. Die Klasse ist MANUAL_REVIEW mit Konfidenz LOW, und jede Route steht als nicht übernommen mit dem Hinweis, was stattdessen zu tun ist.

• Privates DNS ist ein Redesign

  Private Zonen von Route 53 antworten nur innerhalb der zugeordneten VPCs oder über einen Inbound-Endpunkt einer hybriden Umgebung. STACKIT DNS ist öffentliches autoritatives DNS: Seine Einträge sind bauartbedingt öffentlich auflösbar, und das ACL-Feld der Zone erzwingt nichts. Der Lauf stuft die private Zone deshalb als REDESIGN ein und schlägt einen selbst betriebenen Resolver vor, etwa CoreDNS oder BIND auf Servern oder SKE, statt interne Namen zu veröffentlichen.

• Beide Befunde zeigen sich vor dem Aufbau

  Weil der Plan beides als Entscheidung führt, erfährt ein Team von der fehlenden NAT-Adresse und vom öffentlichen DNS-Modell, solange es noch wählen kann, und nicht erst nach dem ersten Cutover.

So wird das Netzwerk zugeordnet

Klassen, wie der Lauf sie entschieden hat. Das Customer Gateway ist eine Support-Ressource des VPN; die Zuordnung der Routingtabelle und der DNS-Eintrag gehen in der Routingtabelle und der Zone auf. Deshalb ergeben 14 Ressourcen 11 Einheiten.

Firewall-Regeln: auf beiden Seiten zustandsbehaftet, mit einer Falle

Security Groups bei AWS und bei STACKIT sind zustandsbehaftete Regelsätze; die Regeln lassen sich daher einzeln übertragen. Links die Gruppe der Eingabe, rechts das Ergebnis des Laufs.

resource "aws_security_group" "app" {
  name   = "app-tier"
  vpc_id = aws_vpc.core.id

  ingress {
    description = "HTTPS from the office network"
    from_port   = 443
    to_port     = 443
    protocol    = "tcp"
    cidr_blocks = ["192.168.0.0/16"]
  }

  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

resource "stackit_security_group" "app" {
  project_id = var.project_id
  name       = "app-tier"
}

resource "stackit_security_group_rule" "app_ingress_1" {
  project_id        = var.project_id
  security_group_id = stackit_security_group.app.security_group_id
  description       = "HTTPS from the office network"
  direction         = "ingress"
  ether_type        = "IPv4"
  ip_range          = "192.168.0.0/16"
  port_range = {
    max = 443
    min = 443
  }
  protocol = {
    name = "tcp"
  }
}

• Allow-all-Egress wird nicht geschrieben

  Die Quellregel, die jeden ausgehenden Verkehr erlaubt, decken die Standard-Egress-Regeln von STACKIT ab; der Lauf schreibt dafür keine Regel. Sollen die Workloads nicht alles außerhalb erreichen, ist die Einschränkung des Egress eine eigene Designaufgabe: Der Entwurf behält den Plattform-Standard bei.

• Eine ungenutzte Gruppe schränkt nichts ein

  In dieser Demo nutzt kein Server die Gruppe, daher markiert der Lauf sie als verwaist: Ihre Regeln begrenzen keinen Verkehr, bis ein Server oder eine Schnittstelle die Gruppe trägt. Prüfen Sie die Zuordnung jeder Gruppe im Entwurf, bevor Sie sich darauf verlassen.

• Adressbereiche ändern sich

  Eine Regel, die einen AWS-internen Bereich nennt, etwa eine Prefix List, muss mit STACKIT-Netzwerkpräfixen neu formuliert werden. Network ACLs haben kein zustandsloses Gegenstück: Im veröffentlichten Lauf für AWS Retail Store sind die sieben Network ACLs durch die Standardwerte des Moduls abgeschaltet; der Lauf führt für sie die Klasse REDESIGN mit STACKIT Security Groups als Ziel.

Eine sinnvolle Reihenfolge für den Netzwerkumzug

Die Reihenfolge ist allgemeine Praxis, verknüpft mit dem, was der Lauf schreibt. Der Lauf selbst ordnet die Einheiten nach Abhängigkeit in migration/technical-sequencing.md.

1. 01

   1 · Alle Adressbereiche erfassen

   Erfassen Sie die CIDRs aller VPCs, Subnetze und Büronetzwerke. AWS empfiehlt überschneidungsfreie Bereiche, wenn mehrere Netzwerke auf ein gemeinsames Netzwerk vor Ort treffen; für STACKIT gilt dasselbe. Behalten Sie die Präfixe der Subnetze, in denen Maschinen ihre Adressen behalten.

2. 02

   2 · Netzwerke und Security Groups aufbauen

   Sie hängen nicht von Daten ab und lassen sich direkt übertragen. Prüfen Sie sie mit einem Plan in einem Testprojekt, bevor etwas von ihnen abhängt.

3. 03

   3 · Das Routing-Design entscheiden

   Beantworten Sie die zurückgehaltene Routingtabelle: gemeinsame Ausgangsadresse oder eine öffentliche IP je Server, die ein Dritter auf seiner Freigabeliste führt, und wie das VPN die Büro-Routen trägt.

4. 04

   4 · Das VPN parallel aufbauen

   Legen Sie Gateway und Verbindung bei STACKIT an, während das alte VPN noch läuft. Stimmen Sie das Fenster mit den Verantwortlichen für das Bürogerät ab, die den neuen Peer und die Schlüssel einrichten müssen.

5. 05

   5 · DNS vor den Servern bereitstellen

   Interne Namen müssen aus den neuen Netzwerken auflösen, bevor der erste Workload eintrifft; der selbst betriebene Resolver kommt also vor den Anwendungswellen.

6. 06

   6 · Per Namen umstellen, den Rückweg behalten

   Senken Sie die DNS-TTLs rechtzeitig, stellen Sie die Namen nach den Prüfungen um und behalten Sie das alte VPN und die alte Zone, bis das Rollback-Fenster verstrichen ist.

Entscheidungen, die bei Ihren Netzwerkarchitekten liegen

• Ausgangsadresse

  Die gemeinsame, veränderliche Ausgangsadresse des STACKIT-Netzwerks akzeptieren oder Servern eine öffentliche IP geben, wo eine externe Freigabeliste die alte NAT-Adresse nennt.

• Routing-Design

  Ob das Ziel überhaupt eine Routingtabelle braucht und wie Routen in Netzwerke vor Ort getragen werden: statische Routen oder BGP am VPN.

• Internes DNS

  Welcher Resolver interne Namen bedient, wo er läuft und wie die STACKIT-Netzwerke ihn erreichen. Öffentliche DNS-Zonen können zu STACKIT DNS ziehen, private nicht.

• Standard-Nameserver

  Der Entwurf setzt ipv4_nameservers jedes Netzwerks aus einer Variablen, deren Standardwert die drei eu01-Adressen des DNS Resolver von STACKIT sind. Stand November 2026 sagt die Resolver-Seite von STACKIT, dass der Dienst noch nicht allgemein verfügbar und nur für Workloads innerhalb von STACKIT gedacht ist; laut Entwurf löst er nur öffentliche Namen auf. Die Variablenbeschreibung ergänzt, dass ein öffentliches Projekt sonst öffentliche Resolver erhält und ein Projekt in einer Network Area die Standard-Nameserver der Area nutzt. Bestätigen Sie den Standardwert oder richten Sie ihn auf Ihren internen Resolver.

• VPN-Plan und Cutover

  Der Service-Plan des Gateways, die Zonen der Tunnel, wer das Bürogerät ändert und wann.

• Erreichbarkeit der Server

  STACKIT-Netzwerke kennen keine Trennung in öffentlich und privat: Ein Server ist erreichbar, wenn er eine öffentliche IP hat und seine Gruppe es erlaubt. Entscheiden Sie, welche Server keine bekommen.

Fragen, die Netzwerkteams stellen

Quellen

• STACKIT VPN
• STACKIT VPN: FAQ
• STACKIT DNS: FAQ
• STACKIT DNS Resolver: Konzepte
• AWS Site-to-Site VPN: Überblick
• Amazon Route 53: Private Hosted Zones