Netzwerktopologie-Diagramm: Büro-LAN, Site-to-Site-VPN und eine Cloud-VPC

Frag drei Leute nach dem Netzwerkdiagramm, und du bekommst drei verschiedene Bilder: ein Foto vom Rack, eine Tabelle mit IP-Adressen und einen Screenshot aus der Cloud-Konsole. Keines davon beantwortet die Fragen, die in einem Review oder bei einem Ausfall aufkommen: Welche Segmente gibt es, was darf mit was sprechen, und wie kommt Traffic zwischen Büro und Cloud hin und her?

Dieser Guide baut ein logisches Netzwerktopologie-Diagramm für ein typisches kleines Unternehmen, ein Büro-LAN mit WLAN und einem Site-to-Site-VPN zu einer Cloud-VPC, und behandelt die Konventionen, die ein solches Diagramm lesbar halten.

Physische oder logische Topologie

Die meisten Gespräche brauchen die logische Sicht. Überlass die physische den Leuten, die im Rack arbeiten, und misch die beiden nicht auf einer Seite: Portnummern neben Firewall-Richtlinien machen beides schwerer lesbar.

Gängige Topologien im Überblick

• Stern. Jedes Gerät hängt an einem zentralen Switch. Fast jedes Büro-LAN ist ein Stern oder ein Baum aus Sternen.
• Mesh. Nodes sind mit mehreren anderen verbunden, sodass Traffic mehr als einen Weg hat. Üblich zwischen Core-Switches, in Rechenzentrums-Fabrics und in WLAN-Mesh-Systemen.
• Hybrid. Echte Netze kombinieren beides: Sterne am Rand, redundante Verbindungen im Kern, Tunnel zwischen Standorten.

Bus- und Ringtopologien sind in modernen LANs weitgehend Geschichte.

Das Beispiel: ein Büro und eine Cloud-VPC

Ein Unternehmen mit 40 Leuten hat ein Büro mit Laptops für die Mitarbeitenden, Gäste-WLAN, einem Fileserver und Druckern. Seine interne App läuft in einer Cloud-VPC, und die Mitarbeitenden erreichen sie über ein Site-to-Site-VPN statt über das öffentliche Internet.

Zuerst kommt der Adressplan, denn das Diagramm baut darauf auf. Alle internen Bereiche stammen aus den privaten Blöcken von RFC 1918, und die öffentliche Adresse nutzt einen Dokumentationsbereich aus RFC 5737:

Zwei Regeln bestimmen diesen Plan. Erstens dürfen sich Büro (10.10.0.0/16) und VPC (10.20.0.0/16) nicht überlappen, sonst kann das VPN nicht zwischen ihnen routen. Zweitens solltest du 192.168.0.0/24 und 192.168.1.0/24 im Büro vermeiden: Viele Heimrouter nutzen diese Bereiche, und Leute im Homeoffice würden in einem Client-VPN damit kollidieren.

Die Firewall routet zwischen den VLANs, also lebt dort auch die Richtlinie:

Das Site-to-Site-VPN in einem Absatz

Ein IPsec-VPN nutzt IKE auf UDP-Port 500, um die Gegenstellen zu authentifizieren und Schlüssel auszuhandeln, und ESP, IP-Protokoll 50, um den verschlüsselten Traffic zu transportieren; liegt ein NAT im Weg, kommt UDP 4500 zum Einsatz. Bei AWS hat jede Site-to-Site-VPN-Verbindung zwei Tunnel mit unterschiedlichen öffentlichen IP-Adressen, die an einem Virtual Private Gateway oder Transit Gateway enden; konfiguriere beide auf deiner Firewall, damit Wartung an einem Tunnel das Büro nicht abschneidet. Die Büroseite braucht eine feste öffentliche IP. Das Routing ist statisch oder dynamisch per BGP, und die Routing-Tabellen der VPC brauchen Rückrouten nach 10.10.0.0/16, entweder vom Virtual Private Gateway propagiert oder von Hand eingetragen.

Das Diagramm

So liest du es:

• Oben links, der Rand. Die Bürofirewall hat die feste öffentliche Adresse und ist die IPsec-Gegenstelle. Sie routet zwischen den drei VLANs und setzt die Richtlinientabelle von oben durch.
• Mitte, das Büro-LAN. Der Core-Switch führt die VLANs 10, 20 und 30 als Trunk. Der Access Point bekommt Strom und einen Trunk vom Switch und ordnet die Mitarbeitenden-SSID VLAN 10 und die Gäste-SSID VLAN 20 zu.
• Rechts, die Cloud. Die gestrichelte Kante ist das IPsec-VPN mit zwei Tunneln zur VPC. App-Server und verwaltete Datenbank liegen in einem privaten Subnetz ohne Route aus dem Internet.
• Die Legende erklärt die Linienstile: Ethernet, WLAN, Power over Ethernet und WAN.

Was du beschriften solltest

• Bereich und VLAN-ID jedes Segments. Eine Box namens „Mitarbeiternetz“ ohne 10.10.10.0/24 lässt sich gegen nichts prüfen.
• Gateways und VPN-Gegenstellen. Welches Gerät jedes Segment routet und welche öffentlichen Adressen den Tunnel bilden.
• Was eine Grenze überqueren darf. Schreib die Richtlinie an die Kanten oder in eine Tabelle neben dem Diagramm, nicht nur in die Konfiguration der Firewall.
• Die Zuordnung von SSID zu VLAN für jedes Funknetz.
• Die Richtung des Verbindungsaufbaus, wo sie wichtig ist, zum Beispiel dass das Cloud-Subnetz nur antwortet.

Was du weglassen solltest

• Jeden Laptop und jedes Telefon. Ein Node pro Geräteart und Segment reicht.
• Kabelfarben und Portnummern in einem logischen Diagramm. Die gehören ins physische.
• Interna des Cloud-Anbieters. Die VPN-Endpunkte gehören zum Virtual Private Gateway; die AWS-Seite des Tunnels musst du nicht zeichnen.

Nutze eine Legende

Linienstile tragen in einem Netzwerkdiagramm Bedeutung, also erklär sie. Eine kleine Legende mit Ethernet, WLAN, Power over Ethernet, WAN und VPN ist in einer Minute angelegt und erspart jedem neuen Leser das Raten. Wenn du Segmente einfärbst, schreib auch dazu, was die Farben bedeuten.

Aktuell halten

Netzwerkdiagramme veralten mit der ersten unangekündigten Änderung. Mach das Diagramm zum Teil der Änderung: Wenn jemand ein VLAN hinzufügt, eine Firewall-Regel ändert oder einen Tunnel ergänzt, verlinkt das Change-Ticket das aktualisierte Diagramm, und ein Reviewer prüft beides. Architekturdiagramme, die nicht veralten beschreibt genau dafür einen Workflow. Die Cloud-Seite im Detail zeigt der Guide zum AWS-VPC-Diagramm, und wie du das flache Büronetz durch identitätsbasierten Zugriff ersetzt, das Zero-Trust-Architekturdiagramm.

In Archboard nachbauen

1. Melde dich mit Google oder GitHub an und leg ein Diagramm an.
2. Füge aus dem Netzwerk-Pack Internet-, Firewall-, Netzwerk-Switch- und WLAN-Nodes für den Büro-Rand und das LAN hinzu.
3. Füge drei Subnetz-Rahmen aus dem Netzwerk-Pack für die VLANs 10, 20 und 30 hinzu, jeweils mit dem Bereich im CIDR-Feld des Rahmens, und setz in jeden einen Gerät- oder Server-Node: Laptops der Mitarbeitenden, Gastgeräte, den Fileserver.
4. Füge einen VPC-Rahmen aus dem Netzwerk-Pack mit einem Subnetz-Rahmen darin hinzu und setz eine Recheninstanz und eine Verwaltete Datenbank aus dem Cloud-Pack in das Subnetz.
5. Verbinde die Nodes und stell für jede Kante die Verbindungsart ein (Ethernet, Wi-Fi, PoE oder WAN). Zeichne das VPN als gestrichelte Kante von der Firewall zur VPC.
6. Füge eine Netzwerklegende aus dem Netzwerk-Pack für die Verbindungsarten hinzu.

Das Beispiel nutzt 15 Diagramm-Nodes und bleibt damit im Free-Plan. Die Seite zum Anwendungsfall Netzwerk zeigt, was das Netzwerk-Pack noch abdeckt.

FAQ

Was ist der Unterschied zwischen einem Netzwerkdiagramm und einem Netzwerktopologie-Diagramm? Die Begriffe werden oft synonym verwendet. Ein Topologiediagramm betont, wie Segmente und Geräte verbunden sind; ein logisches Topologiediagramm ergänzt Adressbereiche, Routing und Richtlinien.

Sollte das Diagramm IP-Adressen zeigen? Zeig Bereiche für jedes Segment und Adressen für Gateways und VPN-Gegenstellen. Einzelne Host-Adressen gehören in ein IP-Adressverwaltungs-Tool.

Warum Gäste in ein eigenes VLAN? Damit die Firewall ihnen das Internet geben kann und sonst nichts. In einem gemeinsamen Segment kann ein Gastgerät Drucker, Dateifreigaben und alles andere erreichen, was dem lokalen Netz vertraut.

Brauche ich zwei VPN-Tunnel? Bei AWS kommt jede Verbindung mit zwei Tunneln, und beide sollten auf deinem Gerät konfiguriert sein, damit einer den Traffic trägt, während der andere gewartet wird.

Wie oft sollte ein Netzwerkdiagramm aktualisiert werden? Bei jeder Änderung, die Adressierung, Routing oder Firewall-Regeln berührt. Kopple das Diagramm an den Change-Prozess, nicht an einen Kalender.

Kostenlos starten — ein Seat, keine Kreditkarte.