Netzwerk-Grundlagen
Netzwerk-Grundlagen verstehen
Netzwerk-Probleme entstehen meist durch Unverständnis der Grundkonzepte, nicht durch fehlerhafte Tools. Container erreichen sich nicht, weil Port-Mapping und Netzwerk-Namespaces unverstanden bleiben. UFW blockiert Docker-Container, weil iptables-Ketten und Interface-Binding unbekannt sind. DNS-Auflösung schlägt fehl, weil /etc/resolv.conf und systemd-resolved-Interaktion unklar ist.
Diese Artikelserie erklärt die technischen Grundlagen ohne distributions-spezifische Details. IP-Adressen funktionieren auf Debian genauso wie auf OpenBSD - nur die Konfigurationswerkzeuge unterscheiden sich. SSH-Keys verwenden identische Kryptographie, unabhängig vom Betriebssystem. Firewall-Konzepte bleiben gleich, ob iptables, ufw oder pf zum Einsatz kommt.
Was macht Netzwerk-Verständnis aus?
Jeder Netzwerk-Service lauscht auf spezifischen Ports an definierten IP-Adressen. Ein Webserver auf 192.168.1.100:80 akzeptiert HTTP-Verbindungen nur von Clients, die diese exakte Kombination erreichen können. Routing-Tabellen entscheiden, welcher Netzwerk-Pfad für ausgehende Pakete gewählt wird. DNS übersetzt lesbare Namen in numerische IP-Adressen - ein reiner Übersetzungsdienst ohne Magie.
Der TCP/IP-Stack arbeitet in Schichten: Ethernet-Frames transportieren IP-Pakete, die wiederum TCP-Segmente oder UDP-Datagramme enthalten. Jede Schicht fügt eigene Header hinzu und entfernt sie beim Empfänger wieder. Diese Kapselung ermöglicht es, dass HTTP-Requests über verschiedene physische Medien transportiert werden können - von Ethernet über WLAN bis zu Glasfaser.
Moderne Linux-Systeme verwenden Netfilter für Paketfilterung. Jedes Netzwerk-Paket durchläuft definierte Hooks: PREROUTING, INPUT, FORWARD, OUTPUT, POSTROUTING. Tools wie iptables, ufw oder firewalld sind nur verschiedene Interfaces für dieselbe Kernel-Infrastruktur. Docker manipuliert diese Regeln automatisch - ohne Verständnis der Netfilter-Architektur bleiben Container-Netzwerk-Probleme unlösbar.
Der systematische Aufbau
Network Namespaces (isolierte Netzwerk-Umgebungen) trennen Netzwerk-Stacks voneinander. Jeder Docker-Container läuft in einem eigenen Namespace mit separater Routing-Tabelle, eigenen Interfaces und unabhängigen Firewall-Regeln. Bridge-Netzwerke verbinden diese Namespaces über virtuelle Ethernet-Paare (veth). Das erklärt, warum Container-Services manchmal vom Host, aber nicht von anderen Containern erreichbar sind.
SSH-Verbindungen basieren auf Public-Key-Kryptographie. Der Client beweist seine Identität durch eine digitale Signatur mit seinem privaten Schlüssel - der Server verifiziert mit dem öffentlichen Schlüssel. Dieses Verfahren funktioniert ohne Passwort-Übertragung und bleibt auch bei kompromittierten Netzwerk-Verbindungen sicher. SSH-Agent speichert entschlüsselte private Schlüssel im Arbeitsspeicher für eine komfortable Nutzung ohne wiederholte Passphrase-Eingabe.
Reverse Proxies terminieren eingehende Verbindungen und erstellen neue Verbindungen zu Backend-Services. Nginx empfängt HTTPS-Requests auf Port 443, entschlüsselt sie und leitet HTTP-Requests an lokale Services auf anderen Ports weiter. Diese Architektur ermöglicht SSL-Terminierung, Load-Balancing und Domain-basiertes Routing mit einem einzigen öffentlichen IP-Zugang.
Für wen ist diese Serie?
Die Artikel richten sich an technisch interessierte Anwender, die Netzwerk-Grundlagen verstehen wollen. Linux-Erfahrung erleichtert das Verständnis, ist aber nicht zwingend erforderlich:
Docker-Anwender, die Container-Netzwerk-Herausforderungen verstehen möchten. Warum funktioniert Port-Mapping manchmal nicht? Weshalb können Services sich gegenseitig nicht erreichen? Wie löst man UFW-Docker-Konflikte systematisch?
Systemadministratoren, die verschiedene Netzwerk-Konfigurationen verstehen möchten. Welche Konfigurationsdateien haben Vorrang? Wie funktioniert DNS-Auflösung in verschiedenen Setups? Was unterscheidet systemd-networkd von traditionellen Ansätzen?
Unternehmer, die sichere Netzwerk-Infrastrukturen aufbauen wollen. Wie konfiguriert man sichere Zugriffe? Welche Firewall-Strategien schützen Services ohne Benutzerfreundlichkeit zu beeinträchtigen? Wie überwacht man Netzwerk-Verkehr systematisch?
Sicherheitsbewusste Anwender, die verschiedene Firewall-Konzepte verstehen möchten. Packet Filter (pf) arbeitet anders als iptables - aber die zugrundeliegenden Netzwerk-Prinzipien bleiben identisch.
Die 6 Artikel im Überblick
Grundlegende Konzepte
IP-Adressen und Ports: Das Fundament für Self-Hosting
DNS und Domains: Namensauflösung und lokale Server
Sichere Verbindungen
SSH-Keys: Sichere Verbindungen ohne Passwörter
SSH für mehrere Server: Effiziente Verwaltung
Filterung und Weiterleitung
Firewall-Prinzipien: Paket-Filterung und Connection-Tracking
Reverse Proxy verstehen: Grundlagen für Service-Konsolidierung
Technischer Fokus und Abgrenzung
Die Serie konzentriert sich auf distributions-übergreifende Netzwerk-Konzepte. Diese Grundlagen gelten für Debian, OpenBSD, Arch Linux und andere Unix-artige Systeme gleichermaßen.
Behandelte Kernthemen:
- TCP/IP-Stack und OSI-Schichten-Modell
- IPv4/IPv6-Adressierung und Subnetting
- DNS-Hierarchie und Resolver-Mechanismen
- SSH-Protokoll und Public-Key-Infrastruktur
- Netfilter-Framework und Paket-Filterung
- HTTP-Proxy-Konzepte und SSL/TLS-Terminierung
Verwandte Grundlagen-Serien:
Diese Netzwerk-Grundlagen bilden das Fundament für spezialisierte Themen:
- Container-Netzwerke: Docker-Bridge, Overlay-Networks, Service-Discovery (geplant)
- VPN-Technologien: Sichere Verbindungen, Tunneling-Protokolle, Site-to-Site (geplant)
- Monitoring-Strategien: Netzwerk-Metriken, Traffic-Analyse, Performance-Monitoring (geplant)
Distributions-spezifische Implementierungen:
- Debian: /etc/network/interfaces, systemd-networkd, UFW-Konfiguration (geplant)
- OpenBSD: hostname.if, pf.conf, rcctl-Integration (geplant)
- Arch: netctl, systemd-networkd, iptables-Verwaltung (geplant)
Typische Service-Integration
Die Netzwerk-Grundlagen ermöglichen systematische Service-Konfiguration. Ein typisches Self-Hosting-Setup verwendet:
- Port 22: SSH für sichere Server-Verwaltung
- Port 80/443: HTTP/HTTPS über Reverse Proxy für öffentliche Services
- Port 25/587: SMTP für E-Mail-Versand (Listmonk)
- Port 8448: Matrix-Federation für dezentrale Kommunikation
- Interne Ports: PostgreSQL (5432), Redis (6379) nur für localhost-Zugriff
Nginx terminiert SSL auf Port 443 und leitet Requests basierend auf Domain-Namen an Backend-Services weiter: plausible.example.com → Port 8000, matrix.example.com → Port 8008. Firewall-Regeln blockieren direkten Zugriff auf Backend-Ports von außen.
Aufbau-Kontinuität und Referenz-Funktion
Jeder Artikel baut systematisch auf vorherigen auf, funktioniert aber auch als eigenständige Referenz. Spätere Service-Installationen verweisen gezielt auf relevante Grundlagen-Artikel:
“Die IP-Port-Grundlagen aus Artikel 1 erklären, warum dieser Service auf 127.0.0.1:8080 lauscht.”
“SSH-Key-Management aus Artikel 3 zeigt, wie sichere Server-Zugriffe ohne Passwörter funktionieren.”
“Reverse Proxy-Konzepte aus Artikel 6 ermöglichen SSL-Terminierung für alle Self-Hosting-Services.”
Diese Struktur vermeidet Redundanz zwischen Grundlagen und Service-spezifischen Anleitungen. Die Netzwerk-Konzepte bilden eine solide Basis für eigenständige Problemlösung.