Zum Hauptinhalt springen

Einheit 8 — Netzwerke, Subnetze und Firewalls

Was du nach dieser Einheit weißt: Du verstehst was ein Subnetz ist, wie Firewalls Datenverkehr kontrollieren und warum System A System B nicht erreichen kann obwohl beide im selben Unternehmen sind.

Was ist ein Subnetz?​

Ein Subnetz ist eine logische Unterteilung eines Netzwerks. Stell dir ein Bürogebäude vor: alle Mitarbeiter sind im selben Gebäude, aber jede Abteilung hat ihre eigene abschließbare Zone.

In der IT-Realität eines mittelgroßen Unternehmens gibt es typischerweise mehrere Subnetze:

Büro-Netzwerk:     192.168.1.0/24    (Mitarbeiter-PCs, Drucker)
Server-Netzwerk:   192.168.2.0/24    (ERP, Datenbankserver)
DMZ:               192.168.3.0/24    (Webserver, externe APIs)
Management:        192.168.4.0/24    (Netzwerk-Hardware, Switches)

Die /24 am Ende bedeutet: dieses Subnetz hat 254 mögliche Adressen (von .1 bis .254).

Warum Subnetze? Kontrolle und Sicherheit. Nicht jedes System soll mit jedem anderen sprechen können. Der Buchhaltungs-PC im Büronetzwerk braucht keinen direkten Zugriff auf den Datenbankserver.

Wie Firewalls den Verkehr kontrollieren​

Eine Firewall prüft jeden Netzwerkpaket an einem Netzwerkgrenzen und entscheidet ob er durchgelassen wird.

Die Entscheidung basiert auf Regeln:

ERLAUBT: Von Büronetzwerk (192.168.1.0/24) 
         zu ERP-API    (192.168.2.50, Port 443)
         Protokoll: HTTPS

ERLAUBT: Von Server-Netzwerk (192.168.2.0/24)
         zu Datenbank (192.168.2.100, Port 5432)
         Protokoll: TCP

BLOCKIERT: Von Büronetzwerk (192.168.1.0/24)
           zu Datenbank (192.168.2.100, Port 5432)
           → Mitarbeiter-PCs dürfen nicht direkt auf die DB

BLOCKIERT: Alles andere (Implicit Deny)

Der letzte Punkt ist entscheidend: Was nicht explizit erlaubt ist, ist verboten — das "Implicit Deny"-Prinzip. Eine neue Verbindung zwischen zwei Systemen klappt standardmäßig nicht. Jemand muss aktiv eine Regel erstellen.

Warum dieselbe API aus verschiedenen Netzwerken unterschiedlich erreichbar ist​

Konkret: 42°OS läuft auf einem Cloud-Server (öffentliche IP: 185.42.11.93). Das ERP des Kunden läuft On-Premises im Server-Netzwerk (192.168.2.50).

42°OS Cloud-Server
    │
    │  HTTP-Anfrage an 192.168.2.50
    │  
Internet
    │
Kunden-Firewall (externe)
    │
    ├── Regel: Eingehend von 185.42.11.93, Port 443 → ERLAUBT? 
    │                                                  (nur wenn explizit freigegeben)
    │
Kunden-Netzwerk
    │
Interne Firewall
    │
    └── ERP-Server 192.168.2.50

Damit 42°OS den ERP-Server erreichen kann, muss die externe Firewall des Kunden eine Regel haben die eingehende Verbindungen von der IP 185.42.11.93 zum Port des ERP erlaubt. Ohne diese Regel: Verbindung schlägt fehl.

Fehlerbild: Connection timed out oder Connection refused — die Verbindung kommt nie beim Server an.

Lösung: Kunden-IT muss explizit die IP-Adresse des 42°OS-Servers in der Firewall freigeben.

Firewalls zwischen Subnetzen (interne Firewall)​

Nicht nur nach außen gibt es Firewalls — auch zwischen internen Subnetzen:

Büronetzwerk (192.168.1.x)
    │
    ├── PC von Jonas (192.168.1.42)
    │       ↓ Verbindung zu ERP
    │
[Interne Firewall]
    │    ERLAUBT: Port 443 (HTTPS) → OK
    │    BLOCKIERT: Port 5432 (PostgreSQL direkt) → Nein
    │
Server-Netzwerk (192.168.2.x)
    ├── ERP-Server (192.168.2.50)
    └── Datenbank (192.168.2.100)

Jonas kann die ERP-Oberfläche öffnen (Port 443 erlaubt). Er kann nicht direkt auf die Datenbank zugreifen (Port 5432 blockiert). Das ist Absicht.

Relevanz für 42°OS: Wenn 42°OS in einem bestimmten Subnetz läuft, gelten für es genau die Firewall-Regeln dieses Subnetzes — nicht die Regeln des Büronetzwerks.

Weiter: Einheit 9 — VPN und seine Tücken