Netzwerktopologien

Die fünf Wege, auf denen ein Kundennetzwerk TRANXACT erreicht, die Vorbereitungen des Netzwerkteams für eine VPN- oder private Verbindung, die /22-Adressplanung und das Subnetzlayout, Hub-and-Spoke-Peering, DNS und Zertifikate, Egress und Operatorzugriff.

Im Netzwerk verlieren die meisten Implementierungen Zeit. Alle unten aufgeführten Optionen sind auf AWS, Microsoft Azure und Google Cloud verfügbar; lediglich die Produktnamen unterscheiden sich.

Fünf Verbindungsoptionen

Was das Kundennetzwerkteam pro Region vorbereitet

Adressplanung

• Mindestens ein /22 privater (RFC 1918) Adressbereich pro Region – 1.024 Adressen.
• Ein zweites, anderes /22 für die Live DR-Region.
• Keines darf sich mit Kunden-, Partner- oder Landing-Zone-Netzwerken – Büros, Rechenzentren, anderen Clouds – überschneiden.
• Kubernetes-Pod- und Servicebereiche werden innerhalb oder neben dem Bereich geplant und unterliegen der gleichen Regel der Überlappungsfreiheit, wenn sie geroutet werden.
• Vermeiden Sie die reservierten und Link-Local-Bereiche des Cloud-Anbieters.
• Die Angabe der Bereiche obliegt dem Kunden (INFRA_2.2.02, Ausgeschlossen). Eine Änderung nach dem Build erfordert einen erneuten Build (INFRA_2.2.12, Zusatzleistung, per Änderungsantrag).

Sammeln Sie den vollständigen IP-Plan des Kunden, bevor Sie eine Auswahl treffen. Eine Überschneidung blockiert VPN, Peering und DR-Routing gleichzeitig, und ein fehlendes /22-Netz kann den gesamten Aufbau lahmlegen.

Die Subnetze innerhalb einer Region

Eine Möglichkeit, 10.40.0.0/22 zu gestalten – eine Illustration zu Schulungszwecken, kein TRANXACT-Standard; der Ledger Architect legt den eigentlichen Plan beim Entwurf fest:

Primary region   10.40.0.0/22   (10.40.0.0 - 10.40.3.255)
  ingress        10.40.0.0/26
  gateway        10.40.0.64/27
  admin          10.40.0.96/27
  egress (NAT)   10.40.0.128/27
  database AZ1   10.40.0.192/27
  database AZ2   10.40.0.224/27
  nodes AZ1      10.40.1.0/24
  nodes AZ2      10.40.2.0/24
  nodes AZ3      10.40.3.0/24

Live DR region   10.40.4.0/22   (same layout, never overlapping the primary)

Peering: Hub-and-Spoke-Architektur

Für Kunden mit einer bestehenden Landing Zone in derselben Cloud fungiert TRANXACT als Spoke und die Landing Zone des Kunden als Hub. Das Peering bildet den Demarkationspunkt. Das Hub-Gateway leitet den Datenverkehr an Büros und Rechenzentren weiter, und der Kunde kann seine eigenen Firewalls oder virtuellen Netzwerkgeräte im Hub einsetzen.

Namensauflösung und Zertifikate

Benutzer und Integrationen verbinden sich mit einem standortunabhängigen Namen. Dieser wird über den Traffic Manager in beiden Live-Regionen aufgelöst, sodass bei einem Live DR Failover keine Neukonfiguration erforderlich ist.

Daten werden übertragen

Der Kunde listet alle ausgehenden Ziele auf (INFRA_2.6.03, Ausgeschlossen); TRANXACT verwaltet die Zulassungsliste, eine Serviceanfrage pro Ziel (INFRA_2.6.02).

Wie TRANXACT-Betreiber ins Land gelangen

• Über einen Zero-Trust- oder Bastion-Zugangspunkt im dedizierten Admin-Subnetz. Kein Knoten oder keine Datenbank wird direkt exponiert.
• Just-in-time, zeitlich begrenzte Höhenanpassung, genehmigt pro Änderung oder Vorfall — vom Kunden genehmigt (TO_4.5.05, Ausgeschlossen).
• MFA für jede Bedieneridentität; Prinzip der minimalen Berechtigungen; rollenbasierte Zugriffskontrolle.
• Jede Administratorsitzung und jeder Cloud-API-Aufruf wird protokolliert und kann in das SIEM-System des Kunden exportiert werden.
• Die Plattform wird von Betreibern verwaltet. Der Zugriff auf Geschäftsdaten erfolgt nur über ein vom Kunden genehmigtes Ticket.

Gängige Integrationsszenarien

Jede Integration erfolgt über die TRANXACT-APIs oder einen verwalteten Dateitransfer. Es wird keine Verbindung zur Datenbank hergestellt.

Machen Sie dazu den Kurs, mit Diagrammen und einer Überprüfung.