Subnet (Subnetz)

CIDR-Notation (/24): 192.168.1.0/24. Das bedeutet: Die ersten 24 Bits (192.168.1) sind die "Straße". Die letzten 8 Bits (0-255) sind die "Hausnummern". Es gibt 256 Adressen.

• .0: Name des Netzes.
• .1: Oft der Router (Gateway).
• .255: Broadcast (Schreien an alle). Nutzbar: 254 Hosts.

1. VLAN vs Subnet

Oft verwechselt.

• VLAN (Layer 2): Trennung der Kabel (virtuell). Switch-Ebene.
• Subnet (Layer 3): Trennung der IP-Adressen. Router-Ebene. Best Practice: One Subnet per VLAN. VLAN 10 = 10.0.10.0/24. VLAN 20 = 10.0.20.0/24. Das macht Routing und Firewall-Regeln einfach und logisch.

2. Variable Length Subnet Masking (VLSM)

Früher (Classful Routing) gab es nur A, B, C Netze (riesig oder klein). Heute (Classless) schneiden wir den Kuchen präzise. Ich habe ein kleines Büro (10 PCs). Ich gebe ihm ein /28 Netz (16 Adressen). Ich habe ein riesiges WLAN. Ich gebe ihm /22 (1024 Adressen). Der Router versteht das ("Longest Prefix Match"). Das spart wertvolle IPv4-Adressen.

3. Public vs Private Subnats (Cloud)

In AWS VPCs:

• Public Subnet: Hat einen Weg zum Internet Gateway (IGW). Server hier haben öffentliche IPs.
• Private Subnet: Hat keinen direkten Weg raus. Nur über ein NAT Gateway im Public Subnet. Sicherheitsregel: Datenbanken gehören immer in Private Subnets. Niemand aus dem Internet darf sie direkt pingen können.

Das Isolations-Konzept: Broadcast Domains & Layered Defense

Physisch trennt ein Subnetz den Broadcast-Traffic (Layer-2 "Lärm", wie DHCP-Requests oder ARP-Anfragen). Jeder Switch-Port, der in ein Subnetz gemappt ist, flutet diese Rahmenpakete nur innerhalb der Netzgrenze. Der dazwischenstehende Router (Gateway) lässt Broadcast-Pakete per Design unbarmherzig droppen. Aus DevSecOps-Perspektive dient das Subnet als radikaler Checkpoint für Security. Durch Architekturmuster wie das DMZ-Pattern baut man "isolierte Sandboxen". Subnetz A (Bastion-Hosts & Loadbalancer) darf per Security Group Traffic von Ports 80/443 empfangen. Subnetz B (Backend Nodes) verbietet sämtlichen globalen Traffic und toleriert Traffic einzig aus Bereich A. Die Netzwerk-Segmentation wirkt bei Hacker-Penetration (Lateral Movement) wie Panzertüren auf einem Ozeandampfer.

Private vs. Public Subnets (Die NAT-Brücke)

Im Cloud-Zeitalter (AWS VPCs / Azure VNets) sind Subnetze keine physischen Kabelbäume mehr, sondern reine Software Defined Networks (SDN) Konstrukte. Ein "Public" Subnetz unterscheidet sich formal nicht durch seine internen IP-Adressen (z.B. 10.0.1.0/24), sondern lediglich durch den Eintrag in sein Routing-Tablet. Liegt auf der Route 0.0.0.0/0 (Internet) ein ansteuerbares Internet-Gateway (IGW) als Ziel, ist es Public. Fehlt diese Route strickt (Private Subnetz), sterben Request out-of-the-box. Will ein Backend-Server dort Updates herunterladen (Apt-get), muss eine kostspielige Brücke zum Public Subnet geschlagen werden: Das NAT-Gateway. Es übersetzt die private Quell-IP der internen VMs im Flug in seine eigene öffentliche IP, leitet ans IGW und schleust das Echo (via Connection Tracking) zurück nach drinnen – klassisches Outbound-Maskieren.

Overlap & Cloud VPN Peering Disasters

Die Planung der CIDR-Subnetzblöcke in der Firmen-Cloud ist irreversibel und hochbrisant. Legst du leichtsinnig das Kubernetes-Cluster-VPC auf 10.0.0.0/16 und richtest ein Jahr später einen AWS Transit Gateway (TGW) oder Site-to-Site VPN Tunnel zu eurer On-Premise-Zentrale ein, droht das Ende. Wenn die Zentrale ebenfalls das Haus-Netz 10.0.0.0/16 verwendet, reißt das Routing (Tunnel) mit einem CIDR Overlap Konflikt komplett zusammen. Der TCP/IP Stack kann Pakete nicht differenzieren, Ping-Echo Endlosschleifen oder Black-Houles entstehen. Das Beheben einer CIDR-Kollision bedeutet oft ein monatelanges Um-IP-Adressieren der globalen Kern-Infrastruktur. Planter IPv4 Subnetting stets disjunkt.