6. Probleme mit dynamischen IP-Nummern

Was sind dynamische IP-Nummern?

IP-Nummern sind knapp und daher teuer. Die Provider versuchen deshalb, IP-Nummern einzusparen, indem sie sich nur so viele IP-Nummern zuweisen lassen, wie sich Kunden gleichzeitig bei Ihnen einwählen können. Die Anzahl der potenziellen Rechner, die sich einwählen könnten, ist aber höher; daher kann nicht mehr für jeden Rechner eine IP-Nummer fest zugeordnet werden.

Der Trick besteht also darin, daß auf eine feste Zuordnung Rechner - IP-Nummer verzichtet wird und stattdessen bei jedem Verbindungsaufbau aus einem freien Pool eine ausgewählt wird, die dem Client mitgeteilt wird. Diese Technik wird nur beim PPP-Protokoll benutzt, nicht jedoch bei rawip.

Diese Methode ist prima, wenn man nur eine Arbeitsstation hat und Session-orientiert arbeitet: Verbindung aufbauen, surfen, surfen, Mails austauschen, surfen und schließlich Verbindung abbauen.

Will man nur ein klein wenig mehr (transparenten Internetzugriff), stellt sich schnell heraus, daß das Internetkonzept und dynamische IP-Nummern nicht zusammenpassen.

Folgende Punkte sind für einen transparenten Internetzugriff wünschenswert:

1. Dial-on-demand: es wird nicht manuell entschieden, daß eine Verbindung auf- oder abgebaut werden soll. Wer soll das in einem größeren Netz auch machen? Die Wählleitung wird automatisch aufgebaut, sobald Pakete vorhanden sind, die nicht im lokalen Netz zugestellt werden können.
2. Automatischer Verbindungsabbau, wenn eine gewisse Zeit keine Pakete über die Leitung gehen.
3. Pausen verursachen keine Kosten, wenn keine Daten über die Leitung gehen. Liest man z.B. eine etwas längere Web-Seite, braucht die Wählleitung nicht aufgebaut zu bleiben.
4. Verhindern, daß vergessen wird aufzulegen. Es blinkt und klackt ja nicht mehr bei ISDN :).

Dieses läßt sich mit ISDN wunderbar lösen, vor allem deshalb, weil der Verbindungsaufbau im Gegensatz zu einem Modem sehr schnell geht. Tatsächlich dauert er nur wenige Sekunden.

Folgende Punkte sind bei dynamischen IP-Nummern nicht realisierbar:

1. Server-Funktionalität: die IP-Nummer des Rechners ist für einen anderen Rechner im Internet nicht bestimmbar. Außerdem wird der Provider vermutlich nicht selbst eine Wählverbindung aufbauen wollen und können - zumindest nicht bei diesen kostengünstigen Verträgen.
2. Mails können nicht direkt zum eigentlichen Mailserver durchgestellt werden - denn an welche IP-Nummer sollten sie geschickt werden - sondern sie müssen bei einem Provider abgelegt werden, von dem sie vom IZG abgeholt werden.
3. Das Offene-Sockets-Problem: Halten einer logischen Verbindung über die Verbindungsunterbrechnung hinaus ist nicht möglich. Loggt man sich beispielsweise per Telnet bei seiner Arbeitsstelle ein, wird nach einer gewissen Zeit der Inaktivität aufgelegt. Drückt man nun eine Taste, wird die Verbindung automatisch wiederhergestellt, aber man bekommt eine andere IP-Nummer zugewiesen. Die Socket-Verbindung zwischen dem eigenen Rechner und dem Arbeitgeber ist damit ungültig geworden, da für einen Socket u.a. Quell- und Ziel-IP-Nummern wichtig sind. Die gleiche Problematik stellt sich bei WWW oder FTP-Verbindungen, die unterbrochen werden.

Sehr wohl aber ist man genauso wie sonst auch nicht gegen Angriffe aus dem Internet geschützt. Ein Hacker kann nur nicht voraussagen, welchen Rechner er angreift; er sucht sich halt nur zufällig eine IP-Nummer aus oder belauscht eine Verbindung und kann den Rechner angreifen. Der Vorteil liegt allerdings darin, daß der Hacker weniger Zeit hat, da die Verbindung abgebaut und mit einer neuen IP-Nummer aufgebaut wird, wobei zwischen den beiden IP-Nummern erstmal kein Zusammenhang zu erkennen ist. Als wirksamer Schutz reicht dies aber nicht aus.

Aus dem Offene-Sockets-Problem ergeben sich zwei Punkte, die bei einem IZG mit dynamischen IP-Nummern beachtet werden müssen:

1. Anfragen laufen in's Leere: Ein Web-Browser hat ein Socket zum Web- oder Proxy-Server offen, nach dem Reconnect ist dieser ungültig, aber der Browser hat keine Möglichkeit, dies zu erkennen. Abhilfe schafft es hier, auf Abbruch und Reload zu drücken.
2. Die Sockets bleiben auch nach Beendigung des Client-Programms offen, es werden immer wieder Pakete darüber geschickt, bis ein Timeout von etwa 20 Minuten abläuft. In dieser Zeit wird ständig eine Verbindung aufgebaut bzw. bleibt bestehen.

Abhilfe schafft für dieses Probem, daß man dem Client nicht erlaubt, direkt in das Internet eine Verbindung aufzubauen (über Masquerading), sondern nur über Proxies, siehe Abschnitt Squid. Aber auch diese Methode ist nicht zuverlässig.

6.1 Der RST-Provoking Mode

Wirkliche Abhilfe schafft nur die Aktivierung des RST-Provoking Mode. Dabei wird bei dem Paket die Quell-IP-Nummer gegen die jetzt aktuelle dynamische IP-Nummer ausgetauscht, was bewirkt, daß beide Seiten diesen Socket schließen.

Dieser Modus ist leider noch nicht in den offiziellen Kernel gekommen. Den Patch von Erik Corry findet man hier:

http://www.image.dk/~ehcorry/linux/

Er ist für Kernel der Version bis 2.0.33 passend, ab Version 2.0.34 wird er vermutlich im Standardkernel sein. Im Standardkernel von SuSE Linux 5.2 und im Quellpaket lx_suse ist dieser Patch schon enthalten.

Zur Aktivierung gibt man dieses Kommando ein:

echo 7 > /proc/sys/net/ipv4/ip_dynaddr
        

ip_rewrite_addrs(): shifting saddr from 1.1.1.1 to 149.228.142.50 (state 2)
        

Um den Mode bei SuSE zu aktivieren, trägt man in /sbin/init.d/i4l_hardware vor dem Start des isdnlog folgende Zeilen ein:

test -z "$I4L_DYNIP" ||
echo 7 > /proc/sys/net/ipv4/ip_dynaddr
        

I4L_DYNIP="yes"
        

6.2 Welche IP-Nummer setze ich denn eigentlich?

Der Provider stellt nur dynamische IP-Nummern zur Verfügung, während der Konfiguration von i4l werde ich aber nach IP-Nummern gefragt - welche IP-Nummer soll ich denn da angeben?

i4l arbeitet mit einer transparenten Netzanbindung, d.h. logisch gesehen ist die Verbindung immer aktiv, auch wenn noch gar nicht gewählt wurde und keine dynamischen IP-Nummern ermittelt werden konnten. Um dieses Pseudo-Netzwerk zu konfigurieren, müssen aber zwangsläufig IP-Nummern angegeben werden.

Es empfiehlt sich daher, eine Pseudo-IP-Nummer zu benutzen, z.B. dieselbe, die man auch für seine Ethernetanbindung benutzt. Das ist möglich, da die PPP-Verbindung als pointopoint-Verbindung (beim ifconfig) konfiguriert wurde. Dies ist ein spezieller Modus, durch den der Kernel weiß, daß hier nur eine Verbindung zwischen zwei Punkten stattfindet. Warum Point-To-Point (PtP) als pointopoint angegeben wird, weiß ich auch nicht.

Um keinen Konflikt mit offiziellen IP-Nummern zu provozieren, sollte man eine aus dem privaten Bereich wählen, z.B. 192.168.1.1.

Falls man bei T-Online angeschlossen ist oder dies plant: Benutze nicht 192.168.0.*. Darüber werden zum Teil interne Dienste wie CEPT abgehandelt.