Tunnel (Networking)

SSH Tunnel (Local Forwarding): Du bist im Café. Du willst auf deine Datenbank zu Hause zugreifen (Port 5432). Die Firewall blockiert das. Aber SSH (Port 22) ist offen.

ssh -L 9999:localhost:5432 user@home-server

Jetzt verbindest du dich lokal auf Port 9999. SSH "schmuggelt" die Datenbank-Pakete durch den SSH-Tunnel zum Server. Für die Firewall sieht es aus wie normale SSH-Textdaten.

1. Overhead & MTU Issues

Tunneling klebt zusätzliche Header an jedes Paket (IP Header + Tunnel Header + Payload). Dadurch wird das Paket größer. Wenn das Paket vorher 1500 Bytes (Ethernet MTU) war, ist es jetzt 1550 Bytes. Router werfen es weg ("Packet too big"). Lösung: MSS Clamping oder Fragmentation. Der Tunnel muss dem PC sagen: "Sende kleinere Pakete (1400 Bytes), damit ich noch Platz für meinen Header habe." Häufige Fehlerquelle bei VPNs (Webseiten laden, aber Bilder nicht).

2. IPsec vs. WireGuard

• IPsec (IKEv2): Der alte Standard. Komplex, schwer zu konfigurieren, läuft im Kernel. Sehr sicher, sehr kompatibel.
• WireGuard: Der neue Herausforderer. Basiert auf UDP. Extrem simpler Code (4000 Zeilen). Schneller Handshake, "Stealth" (antwortet nicht auf Ping, wenn Key falsch ist). Modernster Tunnel-Standard.

3. Tunneling over HTTP/DNS (Hacking)

Hacker nutzen Tunnel, um aus Firmennetzen auszubrechen. Wenn Firewall alles blockt außer DNS (Port 53)... Dann encodiert Malware Daten in DNS-Anfragen: kreditkartendaten.hacker.com. Der DNS-Server des Hackers packt die Daten aus. Das nennt man DNS Tunneling (Exfiltration). Schwer zu erkennen.

IP-in-IP und das MTU Blackhole

Wenn man einen IP-in-IP Tunnel baut, zwängt man ein 20-Byte IPv4 Paket komplett samt Header als "Daten-Payload" in ein neues 20-Byte IPv4 Paket, um es über unroutbare Netze zu schicken (insgesamt also 40 Bytes Header). Wenn der Client nun ein 1500-Byte Paket (Standard-LAN MTU) sendet, wird das getunnelte Paket 1520 Bytes groß. Auf dem Weg ins Internet stößt es an einem Router mit 1500-Byte Limit an. Normalerweise sendet der Router ein ICMP Fragmentation Needed zurück an den Absender. Manche paranoide Firewalls blocken jedoch alle ICMP-Pakete (ICMP Drops). Das getunnelte Paket wird kommentarlos vernichtet. Der TCP-Handshake (winzig) klappt noch, aber beim ersten großen Payload ("TLS Hello" oder "HTTP GET") friert die Verbindung tot ein: Das berüchtigte MTU Blackhole.

SSH Dynamic Port Forwarding (Der Mini-VPN)

Normales SSH Forwarding mapmt einen lokalen Port auf einen entfernten Zielserver (Local Forwarding). Was, wenn man wie mit einem VPN überall ins fremde Netz surfen will? Das ist Dynamic Port Forwarding (ssh -D 1080 user@server). SSH spannt dabei lokal einen vollständigen SOCKS5-Proxy-Server auf. Du stellst deinen Firefox-Browser auf "SOCKS Proxy: localhost:1080". Jeder Request (egal an welche Ziel-IP/Domain) wird nun dynamisch durch den dunklen SSH-Tunnel zum Zielserver gepumpt und von dort als Proxy ins Internet oder Firmen-LAN abgesetzt. Selbst die DNS-Auflösungen werden (bei SOCKS5) durch den Tunnel genagelt (verhindert DNS Leaks am Flughafenwlan).

WireGuard Cryptokey Routing

Alte IPsec VPNs trennen die Routing-Tabelle strikt vom Authentifizierungsablauf. Ein Angreifer konnte Pakete oft in Interfaces injizieren. WireGuard führte die Revolution des Cryptokey Routing ein. Jeder Peer in WireGuard kriegt eine Liste definierter AllowedIPs zugewiesen, gebunden an seinen kryptografischen Public-Key. WireGuard droppt Pakete sofort und leise auf Kernel-Ebene, wenn (a) die Sender-IP nicht zur Liste des Public-Keys passt oder (b) das Paket nicht einwandfrei authentifiziert ist. Es gibt kein langes Handshake-Warten. Stimmt der Krypto-Header nicht zum Routing-Target, schweigt WireGuard wie ein schwarzes Loch (Stealth Design). Keine Portscans schlagen auf Port 51820 an, wenn der Private-Key lokal fehlt.