Im Netzwerkbereich verlieren Implementierungen Zeit – nicht weil es schwierig ist, sondern weil die benötigten Informationen von Teams stammen, die nicht in die Vertriebsgespräche eingebunden waren. Binden Sie diese Teams frühzeitig ein.
| Option | Status | Wähle es, wenn |
|---|---|---|
| Öffentliches HTTPS | Standard | Die Benutzer sind Browser und die Integrationen sind HTTPS. Kein Netzwerkaufbau. |
| Site-to-Site-VPN | Optional | Private Integrationen (MES, Legacy) oder Administratorbeschränkungen. |
| Private Verbindung | Optional | Vorhersehbare Bandbreite und Latenz sind erforderlich, andernfalls ist die Internetverbindung nicht möglich. VPN bleibt als Ausweichpfad bestehen. |
| Peering / privater Link | Optional | Der Kunde verfügt bereits über eine Landezone in derselben Cloud. |
| Verkehrsknotenpunkt | Optional | Die Landezone ist sternförmig aufgebaut; TRANXACT wird als Speiche befestigt. |
Was das Netzwerkteam mitbringt
| Site-to-Site-VPN | Private Verbindung | |
|---|---|---|
| Gerät | IPsec-fähige Firewall oder Router mit einer statischen öffentlichen IP-Adresse | Edge-Router an einem Cloud-Meet-Me-Standort |
| Redundanz | Zwei Tunnel pro Region zu separaten Gateways | Redundante Leitungen; VPN als Backup |
| Protokoll | IKEv2, AES-256, SHA-256, DH-Gruppe 14+ (vorgeschlagen) | BGP über eine private virtuelle Schnittstelle |
| Routing | BGP bevorzugt; statisches GP akzeptiert | BGP mit vereinbarten ASNs und Routenfiltern |
| Live DR | Ein zweites Tunnelpaar zur DR-Region | Eine Verbindung oder ein VPN zur DR-Region |
| Der Kunde besitzt | Geräte-, ISP-Leitungs- und lokale Firewall-Regeln | Leitungs- und Netzbetreibervertrag |
Die Einrichtung von Leitungen dauert beim Anbieter oft mehrere Wochen. Bestellen Sie die Leitung bei Vertragsunterzeichnung und nutzen Sie bis dahin eine VPN-Verbindung.
Adressplanung
Pro Region ist mindestens ein /22-Netz aus privatem RFC-1918-Adressraum (1.024 Adressen) und ein zweites, separates /22-Netz für die Live DR Region vorgesehen. Beide Netze dürfen sich nicht mit Kunden-, Partner- oder Landing-Zone-Netzwerken überschneiden. Pod- und Servicebereiche werden innerhalb oder neben diesen Netzen geplant und unterliegen bei Routing denselben Regeln. Die reservierten und Link-Local-Bereiche des Providers sind zu vermeiden.
Primary 10.40.0.0/22 ingress /26 · gateway /27 · admin /27 · egress /27
database AZ1 /27 · database AZ2 /27
nodes AZ1 /24 · nodes AZ2 /24 · nodes AZ3 /24
Live DR 10.40.4.0/22 same layoutEine Änderung der Adressbereiche nach dem Build erfordert einen erneuten Build – eine Änderungsanforderung für zusätzliche Dienste (INFRA_2.2.12). Eine Überlappung blockiert VPN, Peering und DR-Routing gleichzeitig, und ein fehlendes /22-Netz kann den gesamten Build lahmlegen.
Nabe und Speiche
Bei Peering oder einem Transit-Hub fungiert TRANXACT als Spoke und die Landezone des Kunden als Hub; das Peering bildet den Demarkationspunkt. Der Kunde ist für das Hub-Routing und die Hub-Inspektion verantwortlich und muss transitives Routing explizit zulassen – andernfalls können die Niederlassungen hinter dem Hub den Spoke nicht erreichen, selbst wenn das Peering aktiv ist.
Ein Name, zwei Regionen
Der Kunde stellt den FQDN, ein öffentliches CA-Zertifikat (sofern nicht die Option „Zertifikatverwaltung“ beauftragt wurde), den öffentlichen DNS-Eintrag und eine private Zone oder bedingte Weiterleitung bereit, falls privater Zugriff genutzt wird. TRANXACT bietet Ingress in beiden Live-Regionen hinter einem globalen Traffic Manager, eine niedrige TTL, regionsspezifische Hostnamen für Überwachung und Übungen sowie das Failover-Runbook.
Verwenden Sie in einer Integration niemals .local-Suffixe, IP-Adressen oder regionsspezifische Namen – diese führen beim ersten Failover zu Fehlern. Ein abgelaufenes Zertifikat oder ein fehlender DR-Eintrag sind die häufigsten vermeidbaren Ausfallursachen.
Ausgang und wie Bediener hineinkommen
Alle ausgehenden Ziele werden vom Kunden aufgelistet und von TRANXACT auf die Zulassungsliste gesetzt; für jedes Ziel wird eine separate Serviceanfrage gestellt. Die Operatoren greifen über einen Zero-Trust- oder Bastion-Punkt im Admin-Subnetz zu, wobei die Zugriffsrechte erst nach Genehmigung durch den Kunden und unter Einbeziehung von MFA (Multi-Faktor-Authentifizierung) erhöht werden und jede Sitzung protokolliert wird.
Die Büros von Calderwood nutzen das Netzwerk 10.0.0.0/12, die Azure-Landingzone hingegen 10.32.0.0/13 – der Bereich von 10.32.0.0 bis 10.39.255.255. Die primären Netzwerke 10.40.0.0/22 und 10.40.4.0/22 für Live DR sind somit frei von beiden. Das MES-System befindet sich im VPN; Bank- und Steuerportal laufen über die Ausgehende-Zulassungsliste.
Probier es aus Das Netzwerkteam von Calderwood schlägt 10.36.0.0/22 als primäre Region vor, „weil sie in unserem Netzwerk ungenutzt ist“. Stimmt das?
Das Netzwerk 10.36.0.0/22 befindet sich innerhalb des Landing-Zone-Bereichs 10.32.0.0/13 (10.32.0.0–10.39.255.255). Es wird möglicherweise aktuell nicht genutzt, ist aber an die Landing-Zone weitergeleitet. Daher würden Peering, VPN- und DR-Routing in Konflikt geraten. Überprüfen Sie daher den gesamten IP-Plan – Büros, Rechenzentren, alle Cloud-Standorte – und nicht nur die aktuell genutzten IPs.