Zu wenige IP-Adressen
Marc Ruef | 19.04.2010

TCP/IP ist eigentlich eine ganz simple Sache. Wenn man sich die unterschiedlichen Mechanismen im Einzelnen anschaut, dann sind sie ganz einfach gehalten. Die Komplexität des Themengebiets generiert sich erst durch die Vielzahl der jeweiligen Technologien, ihrer schieren Unendlichkeit an Eigenarten und ihr verflochtenes Zusammenspiel miteinander. Angewandtes TCP/IP ist halt dann doch sehr vielschichtig und komplex.

Viele Leute, die das erste Mal in Kontakt mit TCP/IP kommen, tun dies über IP-Adressen. Die eindeutigen, oftmals in der dotted-decimal Schreibweise dargestellten Nummern (z.B. 192.168.0.1) werden gebraucht, damit in einem Netzwerk verbundene Systeme miteinander kommunizieren können. Nicht umsonst werden IP-Adressen gerne als "Telefonnummern" von vernetzten Hosts bezeichnet.

IP-Adressen sind begrenzt. Dies liegt in erster Linie an den 32-bit, die gebraucht werden, um eine solche im Rahmen von IPv4 darzustellen. Die kleinste mögliche IP-Adresse lautet 0.0.0.0 und die grösste mögliche lautet 255.255.255.255. Dazwischen kann theoretisch alles genutzt werden, um ein netzwerkfähiges System zu adressieren. In der Realität gibt es aber dann noch spezielle (z.B. Broadcast) und reservierte IP-Adressen (z.B. RFC1918), die nicht einfachso verwendet werden sollten.

Schlussendlich weiss jeder Netzwerkadministrator, dass er in seinem Netzwerk nur eine begrenzte Anzahl an Systemen mit eigenen IP-Adressen betreiben kann. Gehen ihm die IP-Adressen aus, dann hat er ein Problem. Auf dieses kann er mit unterschiedlichen Mitteln reagieren. Im schlechtesten Fall schaltet er Systeme ab oder fängt an reservierte IP-Adressbereiche zu nutzen. Im besten Fall versucht er mit einem durchdachten Zonenkonzept und NAT (Network Address Translation) einzelne Subnetze zu machen, wodurch er neue Adressbereiche für sich erschliessen kann (durch ausgeklügeltes Routing und Kaskadieren lassen sich Bereiche dann gar doppelt benutzen).

Ich musste eine lokale Sicherheitsüberprüfung bei einer kleinen Schweizer Bank durchführen. Meine Herangehensweise war wie üblich: Vor Ort gehen, Laptop in das jeweilige Segment einstecken, Tests durchführen, Daten auswerten und dokumentieren. Als ich um 08:45 Uhr beim Kunden eintraf, sah ich diesen jedoch schon vor dem Firewall-Interface sitzen. "Uns ist gerade aufgefallen, dass wir keine freien IP-Adressen mehr haben", hat er gesagt. Das ist ungünstig, denn wie sollte ich denn mit meinem Laptop die Netzwerktests durchführen?

Da wir die Segmentierung des Netzes nicht anfassen wollten, schliesslich handelte es sich um eine produktive Umgebung, haben wir uns für eine andere Lösung entschieden. Dabei standen unterschiedliche Möglichkeiten zur Auswahl:

1. Tests von einem bestehenden, produktiven System ausführen
2. Tests aus einem anderen Segment ausführen, mein System für sämtliche Zugriffe auf der Firewall freigeben
3. Einrichten eines hostbasierten NAT innerhalb der bestehenden VMware-Umgebung

Wir konnten uns durch die Kombination der unterschiedlichen Lösungsmethoden arrangieren (in gewissen Fällen musste mit Heisenbugs gerechnet werden) und das temporäre Problem war für mich gelöst. Ein Problem dieser Art ist jedoch nichts besonderes, wurde mir erst gerade vor Kurzem berichtet, dass einem grossen Schweizer Internet Service Provider die IP-Adressen für Kunden ausgegangen sind. Ein Horror-Szenario, denn da musste dann kurzfristig ein Umzoning der Netzsegmente durchgesetzt werden. Und jeder, der schon einmal soetwas gemacht hat weiss, dass man die neue Routing-Konfiguration nur selten beim ersten Mal richtig zum Laufen kriegt.