Seit fast zwei Jahren ist DSL verfügbar. Wer aber unter Linux in den Genuss des breitbandigen Surfens kommen will, muss selbst Hand anlegen. Wenn die eigene Distribution auf einem Kernel der 2.4er Serie aufbaut, gilt es dabei andere Wege zu beschreiten als mit Kernel 2.2.x.
“Linux, damit kenne ich mich nicht aus, wird von uns auch nicht unterstützt.” Wer kennt sie nicht, die Antworten der Hotline? Dabei sollte man meinen, dass mit der stetig wachsenden Verbreitung von Linux auch dieses Betriebssystem zum Supportumfang des Zugangsproviders gehören sollte.
Doch statt sich darauf zu verlassen, ist ein Blick in einige Howtos (http://www.linux.org/docs/index.html) oft hilfreicher, will man dem Pinguin einen breitbandigen Anschluss ans weltweite Netz verschaffen. Die Problematik liegt in einem speziellen Protokoll namens “Point to Point over Ethernet” (PPPoE) begründet, nachzulesen unter http://rfc.net/rfc2516.html. Da die meisten DSL-Provider in Deutschland diese Technik wählen, kommt die Masse der DSL-Kunden nicht darum herum, ihre Rechner entsprechend auszustatten. Dazu bestehen zwei Möglichkeiten.
Pseudo-Terminal oder Kernel-Patches?
Der einfachste Weg ist der ab Seite 18 beschriebene über ein Pseudo-Terminal.
Die von mir bevorzugte Lösung ist eine Implementierung des Protokolls im Kernel. Standardmäßig bietet der 2.2er Kernel aber keine PPPoE-Unterstützung. Die meisten Distributionen bringen jedoch nicht die von Linus Torvalds veröffentlichte Version mit, sondern haben die Kernel-Quellen bereits mit einigen Patches versehen. Somit ist es wahrscheinlich, dass auf dieses Protokoll dennoch zurückgegriffen werden kann. Damit beschäftigt sich ein eigener Artikel ab Seite 28.
Kernel-Version 2.4 enthält PPPoE-Unterstützung bereits in den ungepatchten Quellen. Einige neuere Distributionen (z. B. SuSE 7.1) bieten auch schon eine mehr oder weniger komfortable, menügesteuerte Konfiguration des DSL-Zugangs an, allerdings meist nur für den 2.2er Kernel. Eine Ausnahme ist die neue SuSE 7.2, welche eine komfortable Konfiguration über das grafische Setup-Tool YaST2 anbietet. Über das Tool lassen sich nicht nur die ADSL-Zugänge der Deutschen Telekom (T-DSL, Abbildung 1) konfigurieren, sondern auch andere ADSL-Verbindungen (Abbildung 2). Dieses aktuelle YaST2 erspart auch den weiter unten beschriebenen Konfigurationsmarathon.
Abbildung 1: T-DSL-Konfiguration mit YaST2
Abbildung 2: SuSE 7.2 unterstützt auch andere ADSL-Zugänge
Soll der 2.4er Kernel mit seinen zahlreichen Verbesserungen zur Anwendung kommen, sind einige Änderungen nötig. Damit PPPoE überhaupt möglich wird, muss er mit PPP support kompiliert werden (Abbildung 3). Folgende Zeile sollte Gewissheit verschaffen, ob die eingesetzte Distribution PPPoE unterstützt:
find /lib/modules/`cat /proc/sys/kernel/osrelease`/ -name "*pppo*"
Abbildung 3: PPP-Unterstützung im Kernel anschalten
Erscheinen zwei Zeilen von der Form
/lib/modules/Kernel-Version/kernel/driver/net/pppoe.o /lib/modules/Kernel-Version/kernel/driver/net/pppox.o
als Antwort, so bietet der eingesetzte Kernel PPPoE-Support.
Außerdem gilt es, den “Point to Point Protocol Daemon” (pppd) zu ersetzen. Die Vorgehensweise ist im Kasten “Selbstkompiliert: pppd mit PPPoE-Support” beschrieben.
Selbstkompiliert:
pppd
mit PPPoE-Support
Um ein auf Kernel 2.4.x basierendes System PPPoE-fähig zu machen, benötigt man die Quellen des pppd (ppp-2.4.1-pppoe2.tgz von http://www.shoshin.uwaterloo.ca/~mostrows/). Es handelt sich hierbei um den für PPPoE gepatchten PPP-Daemon in der Version 2.4.1. Der (ungepatchte) Quellcode pppd-2.4.1.tar.gz kann nicht verwendet werden bzw. muss zunächst mit dem ebenfalls unter dieser URL erhältlichen Patch ppp-2.4.1-pppoe.patch2 angepasst werden.
Installation
Die Quellen werden mit tar xvfz ppp-2.4.1-pppoe2.tgz entpackt. Nach dem Wechsel ins neu entstandene Verzeichnis mit cd ppp-2.4.1-pppoe2 bereitet man die Quellen mit ./configure --prefix=/usr für die Kompilation mit einem C-Compiler (mindestens gcc in der Version 2.95.2) vor.
Diese Compiler-Suite ist Bestandteil einer jeden Standardinstallation. Gegebenenfalls muss sie mit Hilfe des Paketmanagement-Tools der jeweiligen Distribution nachträglich installiert werden. Dieses wird auf ggf. nicht erfüllte Paketabhängigkeiten aufmerksam machen und bietet oft sogar die Option an, fehlende Pakete automatisch einzuspielen.
Zusätzlich zum Compiler müssen autoconf und make installiert sein. Sind alle für das Kompilieren notwendigen Programme an Board, kann mit make die Übersetzung der Programme in den Binärcode beginnen. Tritt dabei ein Fehler auf, erfährt man davon, indem in den letzten Zeilen der Ausgabe mehrfach ein ** ERROR * auftaucht.
Bevor der Superuser root die erstellten Dateien nach einem fehlerfreien Kompilationsvorgang mit make install in die jeweiligen Verzeichnisse kopiert, sollten die Original-pppd-Dateien gesichert werden:
cp /usr/sbin/ppp* backupverzeichnis_fuer_pppd
Konfiguration
Wenn selbstkompilierte Versionen von pppd und pppoed zum Einsatz kommen, ist im Gegensatz zu den vorkompilierten Versionen von SuSE Folgendes zu beachten: Die Konfiguration nimmt man in einer Datei /etc/ppp/options vor, nicht in zwei Dateien, wie in den Listings 2 und 3. Den Inhalt dieser Datei entnehmen Sie bitte Listing 1.
Start
Aufgebaut wird die Verbindung mit
pppd eth1 file /etc/ppp/options
eth1 steht für die Ethernetkarte, welche mit dem DSL-Modem verbunden ist; in diesem Fall die zweite Netzwerkkarte.
Listing 1
/etc/ppp/options
für den selbstkompilierten
pppd-2.4.1
mit PPPoE-Support
# /etc/ppp/options # # # Die Optionen koennen mit man pppd # nachgelesen werden. # Obwohl sich diese Manpage auf die # Datei pppd.conf und deren Optionen # bezieht, sind die Erklaerungen # auch fuer diese Datei gueltig. # # # pppd-2.4.1-Optionen # fuer Kernel 2.4 # # Unterstuetzung fuer PPPoE plugin /usr/lib/pppd/2.4.1/pppoe.so # # Plugin ermoeglicht die Weitergabe # des Passworts an den pppd plugin /usr/lib/pppd/2.4.1/passprompt.so # # Keine besondere Authentifizierung noauth # # Empfangen der DNS-Adressen vom # Provider usepeerdns # defaultroute # # Die lokale und die Point-to- # Point-Adresse werden vom # Provider vorgegeben ipcp-accept-local ipcp-accept-remote # # dial on demand - automatischer # Verbindungsaufbau # Weglassen des Stichworts == kein # automatischer Verbinungsaufbau demand # # Benutzername und Passwort # (muessen auch in # /etc/ppp/pap-secrets eingetragen sein) user "[Anschlusskennung][T-onlineNr]0001@t-online.de" password "geheim" # # Passwort wird nicht protokolliert hide-password nodetach # Kompressionsverfahren muessen # ausgeschaltet werden nopcomp novjccomp noccp # # Auflegen nach 180 s Inaktivitaet idle 180 # max. Uebertragungseinheit # (Empfang und Versand) mru 1492 mtu 1492 # Die Adressen fuer ppp0, wenn # keine Verbindung aufgebaut wurde 192.168.2.1:192.168.2.254
SuSE bietet hierzu speziell für den 2.4er Kernel gepatchte Versionen an. Obwohl sich diese noch im Beta-Stadium befinden, laufen sie auf meinem Rechner seit ca. drei Monaten anstandslos. Die vorkompilierten Pakete, zu finden unter ftp://ftp.suse.com/pub/people/bk/pppoe/ppp-2.4.0-5.i386.rpm und ftp://ftp.suse.com/pub/people/bk/pppoe/pppoed-0.48b1-6.i386.rpm, werden mit
rpm -Uhv ppp-2.4.0-5.i386.rpm rpm -Uhv pppoed-0.48b1-6.i386.rpm
installiert. Verweigert der Paketmanager die ppp-Installation, kann man ihn mit rpm -Uhv --force --nodeps ppp-2.4.0-5.i386.rpm zur Mitarbeit überreden. Allerdings sollten Sie diesen Befehl nur verwenden, wenn Sie wissen, was Sie tun!
Jetzt müssen noch zwei Konfigurationsdateien geändert werden.
Konfigurationsmarathon
In der Datei /etc/ppp/peers/pppoe24 (Listing 2) legt man Optionen für das Programm pppoe24 fest, welches den pppd initiiert. Lassen Sie sich nicht von der Zahl 24 im Namen verwirren! Damit unterscheidet SuSE Linux zwischen dem pppoe24 für Kernel 2.4.x und pppoe für Kernel 2.2.x. Wenn Sie den pppoed selbst kompiliert haben, trägt das Binary keine Zahl zur Unterscheidung im Namen.
Listing 3 gibt die modifizierte Konfigurationsdatei /etc/pppoed.conf für den pppoed24 wieder. Diese Datei wird auch vom Konfigurationstool YaST2 modifiziert.
Listing 2
Modifizierte
/etc/ppp/peers/pppoe24
für das vorkompilierte SuSE-Paket
pppoed-0.48b1-6.i386.rpm
# /etc/ppp/peers/pppoe24 # # # Die Optionen koennen mit man pppd # nachgelesen werden. # Obwohl sich diese Manpage auf die # Datei pppd.conf und deren Optionen # bezieht, sind die Erklaerungen # auch fuer diese Datei gueltig. # # # PPPoE-Optionen # fuer Kernel 2.4 # # Unterstuetzung fuer PPPoE plugin /usr/lib/pppd/plugins/pppoe.so # # Plugin ermoeglicht die Weitergabe # des Passworts an den pppd plugin /usr/lib/pppd/passwordfd.so # # Keine besondere Authentifizierung noauth # # Empfangen der DNS-Adressen vom # Provider usepeerdns # noipdefault # Die lokale und die Point-to- # Point-Adresse werden vom # Provider vorgegeben ipcp-accept-local ipcp-accept-remote # Passwort wird nicht protokolliert hide-password nodetach # Kompressionsverfahren muessen # ausgeschaltet werden nopcomp novjccomp noccp # max. Uebertragungseinheit # (Empfang und Versand) mru 1492 mtu 1492 # Die Adressen fuer ppp0, wenn # keine Verbindung aufgebaut wurde 192.168.2.1:192.168.2.254
Listing 3
Neue
/etc/pppoed.conf
für SuSE
# /etc/pppoed.conf # Vgl. man pppoed fuer die # Erklaerung der Optionen # # Welche Netzwerkkarte ist mit dem # DSL-Modem verbunden? interface = eth1 # # Benutzername (user) und Passwort # (password) # (Allgemeines Beispiel fuer # T-Online) user = "[Anschlusskennung][T-onlineNr]0001@t-online.de" password = "geheim" # # (Leerlauf-)Zeit, nach der die # Verbindung getrennt werden soll # (in Sekunden) idle = 180 # # Dial on demand (automatischer # Verbindungsaufbau) demand = yes
In der pppoed.conf verstecken sich persönlichen Zugangsdaten für den DSL-Zugang sowie Besonderheiten der eigenen Hardware. interface gibt an, an welcher Netzwerkkarte das DSL-Modem angeschlossen ist. idle bezeichnet die Zeit (in Sekunden), nach der die Verbindung getrennt wird, wenn über diesen Zeitraum keine Daten mehr geflossen sind. Mit demand=yes oder demand=no kann ein automatischer Verbindungsaufbau an- bzw. abgeschaltet werden.
Die hinter user= und password= gemachten Angaben müssen sich zusätzlich in folgender Form in der Datei /etc/ppp/pap-secrets wiederfinden:
# # /etc/ppp/pap-secrets # "[Anschlusskennung][T-onlineNr]0001@t-online.de" * "geheim"
Verbindungsaufnahme
Damit ist die Konfiguration abgeschlossen, und ein Testlauf kann beginnen. Aufgebaut wird die Verbindung, indem root den soeben konfigurierten Daemon mit pppoe24 startet. Dieser kann, sofern man ihn nicht für ein Ausführen im Hintergrund konfiguriert hat, mit [Strg-C] gestoppt werden. Wird er nicht manuell beendet, stoppt er automatisch nach der in der Datei /etc/pppoed.conf vorgegebenen idle-Zeit.
Für den selbstkompilierten pppd mit PPPoE-Unterstützung zeigt der entsprechende Kasten die Vorgehensweise.
Die (hoffentlich) aufgebaute Verbindung überprüft man, indem man Testpakete an einen entfernten Rechner schickt. Mit dem Befehl ping senden wir z. B. 15 (-c 15) Testpakete an den T-Online-DNS-Server:
ping -c 15 194.25.2.129
Troubleshooting
Zur Fehlersuche lässt sich in der Datei /etc/ppp/options der Debug-Modus einschalten:
# Kernel-Debug, max. Informationsausgabe kdebug 9
Damit werden sehr viele Debug-Informationen in der Datei /var/log/messages abgelegt, was man mit
tail -f /var/log/messages
in Echtzeit beobachten kann. Da die messages-Datei dadurch schnell sehr groß werden kann, empfiehlt es sich, diesen Modus nach dem Testen sofort wieder abzuschalten.
Finden sich im Fehler-Log ausschließlich Informationen der Form sending PADI, gefolgt von einem Abbruch des Verbindungsaufbaus, liegt vermutlich ein Fehler in der Verkabelung vor. Die Fehlermeldung Password authentication failure ist ein eindeutiges Zeichen für ein falsches Passwort (oder die Überlastung des DSL-Netzes bzw. des Access Concentrators).
Passwort-Schwierigkeiten
Sofern in der Datei /etc/ppp/pap-secrets ein falsches Passwort steht, haben Sie bei T-Online weitere neun Verbindungsaufbauversuche frei. Nach der zehnten falschen Passworteingabe wird der Account gesperrt. Die automatische Wiederfreischaltung des gesperrten Zugangs erfolgt etwa zwischen Mitternacht und 2 Uhr nachts.
Wenn Sie im Log den Benutzernamen sehen, die Verbindung anschließend jedoch abgebrochen wird, haben Sie möglicherweise den Usernamen falsch eingegeben. Beachten Sie die Anführungszeichen und bei T-Online das Suffix @t-online.de in den Dateien /etc/ppp/options bzw. /etc/ppped.conf und /etc/ppp/pap-secrets. Bei diesem Provider ist zudem die Reihenfolge von Anschlusskennung, T-Online-Nummer und Mitbenutzersuffix (meistens 0001, in seltenen Fällen kommt vor die “0001” noch ein “#”-Zeichen: immer dann, wenn Anschlusskennung und T-Online-Nummer zusammen weniger als 32 Stellen haben) wichtig. Im Zweifelsfall lesen Sie bitte die Mitteilung über Ihre Zugangsdaten nach, die Sie von Ihrem Provider erhalten haben sollten.
Startprobleme
Sollte der pppd bzw. pppoe24 nicht starten, liegt der Schluss nahe, dass die Kernel-Module pppox.o und pppoe.o noch nicht geladen sind. Aufschluss darüber gibt ein Blick auf die derzeit aktiven Module mit lsmod | grep "pppo". Wenn die Ausgabe dieses Kommandos weniger als zwei Zeilen lang ist, müssen die Module von Hand eingebunden werden. modprobe pppoe lädt das Modul pppoe.o und das von diesem benötigte pppox.o gleich mit.
Ein weitere mögliche Fehlerquelle ist die fehlende Einbindung der Netzwerkkarte(n) ins System. Überprüfen lässt sich dies mit dem Befehl ifconfig. Der Kasten Interface-Konfiguration zeigt eine Beispielausgabe. Wird nichts ausgegeben oder erscheint lediglich das Loopback-Device lo, gilt es, die Netzwerkkarten mit dem distributionsabhängigen Konfigurationstool (z. B. YaST bzw. YaST2 für SuSE oder linuxconf für Red Hat) einzurichten.
Liegt’s an der Firewall?
Sind die Interfaces richtig konfiguriert, kann das Problem mit dem Befehl ping weiter eingegrenzt werden. Senden Sie dazu an eth0 und (sofern vorhanden) eth1 sowie lo Testpakete. Der Befehl ping -c 10 127.0.0.1 (zehn Testpakete ans Loopback-Interface) sollte die Ausgabe
PING 127.0.0.1 (127.0.0.1): 56 data bytes 64 bytes from 127.0.0.1: icmp_seq=0 ttl=247 time=1.726 ms […] 64 bytes from 127.0.0.1: icmp_seq=14 ttl=247 time=0.726 ms — 127.0.0.1 ping statistics — 15 packets transmitted, 15 packets received, 0% packet loss round-trip min/avg/max = 0.7/0.785/1.726 ms
erzeugen. Wird kein Paket übermittelt, liegt dies in der Regel an restriktiven Firewall-Einstellungen. Zu Testzwecken (und nur dazu) können die Regeln für die lokale iptables-Firewall mit
iptables -X iptables -F iptables -t nat -X iptables -t nat -F iptables -P INPUT EXCEPT iptables -P OUTPUT EXCEPT iptables -P FORWARD EXCEPT
gelöscht werden. Jetzt sollte ein ping die Testpakete übertragen können. Um Angriffen aus dem Internet nicht kampflos ausgeliefert zu sein, überarbeiten Sie im Anschluss daran bitte die Firewall-Regeln.
Das Versenden von Testpaketen an die anderen Interfaces sollte ebenso positive Ergebnisse erzielen. Wird der Versuch wider Erwarten nicht mit Erfolg belohnt, empfehle ich einen Blick ins Handbuch des Distributors oder ins HowTo http://www.linux.org/docs/ldp/howto/Net-HOWTO/index.html.
Falsche Route
Können die lokalen Netzwerkadressen mit Testpaketen versorgt werden, jedoch keine Rechner im Internet angesprochen werden, empfiehlt sich ein Blick ins Routing. Der gleichnamige Kasten zeigt ein Beispiel. Entscheidend ist hierbei die letzte Zeile, das Default-Gateway. Dieses muss auf ppp0 verweisen und kann zu Testzwecken mit folgendem Befehl eingerichtet werden:
route add default gw 192.168.2.254
Allerdings sollte der pppd das Default-Gateway automatisch eintragen. Überprüfen Sie daher, dass das Konfigurationstool Ihrer Distribution die zweite Netzwerkkarte bei ihrer Installation nicht aus Versehen zum Default-Gateway befördert hat. In diesem Fall gilt es, den entsprechenden Eintrag wieder zu löschen. Weiterführende Informationen zum Routing sind zu finden unter http://www.linux.org/docs/ldp/howto/Adv-Routing-HOWTO.html.
Das Testen der Verbindung sollte dabei in jedem Fall über die IP-Adresse erfolgen und nicht über den aufzulösenden Namen www.t-online.de. Ein positives Ergebnis des ping-Befehls sieht so aus:
PING 194.25.2.129 (194.25.2.129): 56 data bytes 64 bytes from 194.25.2.129: icmp_seq=0 ttl=247 time=68.700 ms[…] 64 bytes from 194.25.2.129: icmp_seq=14 ttl=247 time=67.126 ms — 194.25.2.129 ping statistics — 10 packets transmitted, 10 packets received, 0% packet loss round-trip min/avg/max = 66.545/67.857/69.411 ms
Achten Sie darauf, dass wenigstens ein Paket tatsächlich übertragen wurde. Dann kann der Browser gestartet werden: Der nun endlich konfigurierte Zugang sollte wie in Abbildung 4 Übertragungsraten von bis zu 90 kBit/s erreichen können.
Abbildung 4: Mit Breitband-Geschwindigkeit zum FTP-Download
Falls keine Verbindung zustande kommt, bietet der Kasten “Troubleshooting” Anhaltspunkte zu möglichen Fehlerquellen.
Umstieg auf Kernel 2.4 und seine Module
Möchten Sie eine Kernel-2.2-basierte Distribution auf Kernel 2.4.x aktualisieren (und den 2.4er Kernel aus den Sourcen übersetzen), dann beachten Sie bitte, dass sich bei den Kernelmodulen einiges geändert hat. Aus diesem Grund muss das modutils-Paket in einer Version ab 2.4.0 vorliegen. Informationen über die Versionsnummer liefert insmod --version. Normalerweise halten die FTP-Server der jeweiligen Distributionen aktualisierte Versionen bereit.
Alternativ liefert http://rpmfind.net/linux/rpm2html/search.php?query=modutils eine Auflistung vorkompilierter modutils-Pakete. Ein Paket für i686-Prozessoren findet man z.B. unter ftp://ftp.rpmfind.net/linux/PLD/current/PLD-1.0/i686/PLD/RPMS/modutils-2.4.6-2.i686.rpm.
Die Konfigurationsdatei für die Module trägt ab Kernel bzw. modutils 2.4 den Namen /etc/modules.conf und nicht mehr /etc/conf.modules. Befindet sich noch eine alte Datei conf.modules im /etc-Verzeichnis, sollte sie in modules.conf umbenannt werden:
cd /etc mv conf.modules modules.conf
Listing 4 zeigt Zeilen der Datei /etc/modules.conf, die ggf. angepasst werden müssen. Anschließend sollten die Abhängigkeiten der Module mit depmod -aev neu aufgelöst werden.
Listing 4
/etc/modules.conf
für 2.4er Kernel
# /etc/modules.conf (Auszug) #[…] alias /dev/ppp ppp_generic alias char-major-108 ppp_generic alias tty-ldisc-3 ppp_async alias tty-ldisc-14 ppp_synctty alias ppp-compress-21 bsd_comp alias ppp-compress-24 ppp_deflate alias ppp-compress-26 ppp_deflate alias tty-ldisc-3 ppp alias ppp-compress-21 bsd_comp alias ppp-compress-24 ppp_deflate alias ppp-compress-26 ppp_deflate[…]
Das Pinguin-Gateway
Möchte man den Rechner als Router für ein kleines Netzwerk betreiben, ist ein automatischer Start des PPPoE-Daemons sinnvoll. Listing 5 zeigt ein Startskript, Listing 6 ein Stoppskript, getestet unter SuSE Linux 7.1, jedoch so distributionsunabhängig gehalten, dass sie auch auf anderen Distributionen unverändert oder nur leicht angepasst laufen sollten.
Legen Sie beide Skripte im init.d-Verzeichnis, meist ein Unterverzeichnis von /etc, ab, wechseln Sie ins rcx.d-Verzeichnis Ihres Default-Runlevels (bei SuSE rc5.d, vgl. z.B. Dr. Linux in Heft 07/2001), und verlinken Sie das Startskript auf einen S-Namen, das Stoppskript auf einen K-(“kill”)-Namen:
ln -s /etc/init.d/pppdpppoe.start S08pppd ln -s /etc/init.d/pppdpppoe.stop K35pppd
Des Weiteren muss die maximale Übertragungseinheit (MTU) für die Netzwerkkarte, die mit dem lokalen Netz verbunden ist, angepasst werden:
ifconfig eth0 mtu 1492
Stellen Sie diese MTU auch bei den anderen Rechnern ein, die dieses Gateway nutzen wollen. Für andere Linux-Rechner ist das mit obiger Zeile getan, bei anderen Betriebssystem ist es nicht ganz so trivial. Unter Windows 9x müssen Sie die Registry mit regedit unter
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Class\NetTrans\000[n]\
um den neuen Eintrag MaxMTU mit der Zeichenkette 1492 erweitern. Den Schluss-String [n] tauschen Sie gegen die laufende Nummer der entsprechende Netzwerkkarte aus (zu vergleichen mit eth[n] unter Linux).
Für WinNT legen Sie in der Registry unter
HKEY_LOCAL_MACHINE/System/CurrentControlSet/Services/El90[n]1/Parameters/Tcpip/
einen neuen Eintrag MTU an und geben hierfür als DWORD 1492 ein.
Weiterleitung
Der Linux-Gateway-Rechner muss jetzt noch so konfiguriert werden, dass er für’s Internet gedachte Pakete der lokalen Rechner weiterleitet. Einige Distributionen kennen dafür einen speziellen Parameter (ENABLE_FORWARD in der zentralen Konfigurationsdatei /etc/rc.config bei SuSE oder IPFORWARDING in Calderas /etc/rc.d/init.d/network). Ist dieser Wert auf "yes" gesetzt, kann man auf den nachfolgenden Befehl verzichten:
echo 1 > /proc/sys/net/ipv4/ip_forward
Ob Paketweiterleitung eingeschaltet ist, verifizieren Sie mit dem Befehl cat /proc/sys/net/ipv4/ip_forward: Bei einem Wert 0 werden Netzwerkpakete nicht weitergeleitet; gibt das Kommando eine 1 aus, hingegen schon.
Ab Kernel 2.4 kommt iptables (http://netfilter.samba.org/) als Firewall zum Einsatz, deren Module durch modprobe ip_tables geladen werden. Diesem Paketfilter muss nun noch mitgeteilt werden, dass Pakete, die das Device ppp0 betreffen, ins Netz der Netze weitergeleitet werden sollen:
iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE
Damit sollten auch an das Linux-Gateway angeschlossene Rechner in den Genuss des Highspeed-Surfens kommen.
Listing 5
Startskript für den
pppoed
#! /bin/sh # #/sbin/init.d/pppdpppoe.start # failed=" ERROR, nicht gestartet" return=" OK" /sbin/modprobe pppoe echo -n "PPPD Start : " /usr/sbin/pppd eth1 file /etc/ppp/options > /dev/null & pstree | grep "pppd" > /dev/null || return=$failed echo -e "$return" exit 0
Listing 6
Stoppskript für den
pppoed
#! /bin/sh # #/sbin/init.d/pppdpppoe.stop # failed=" ERROR, nicht gestartet" return=" OK" echo -n "PPPD Stop : " killall pppd || return=$failed # alternativ: kill -15 `cat /var/run/ppp0.pid` || return=$failed echo -e "$return" exit 0
Interface-Konfiguration
Für die Beispielkonfiguration habe ich jeweils die zweite Ethernetkarte des Gateway-Rechners (eth1) mit ppp0, dem “generierten” Interface zum Internet, verknüpft. Die Karte eth0 ist mit dem lokalen Netzwerk verbunden. Sollte in Ihrem Rechner nur eine Karte eingebaut sein, weil Sie Ihren Einzelplatzrechner direkt ans DSL-Modem anschließen, ändern Sie bitte in allen Konfigurationsdateien den Eintrag eth1 auf eth0.
Zum Überprüfen, welche Netzwerk-Interfaces überhaupt angesprochen werden können, eignet sich der Befehl ifconfig; im Falle nur einer Ethernet-Karte fehlt in der folgenden Beispielausgabe der Eintrag zu eth1.
eth0 Link encap:Ethernet HWaddr 00:55:66:77:88:99
inet addr:192.168.1.254 Bcast:192.168.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1492 Metric:1
RX packets:59427 errors:0 dropped:0 overruns:0 frame:0
TX packets:66465 errors:0 dropped:0 overruns:0 carrier:0
collisions:51 txqueuelen:100
Interrupt:12 Base address:0xc000
eth1 Link encap:Ethernet HWaddr 00:50:60:70:80:90
inet addr:192.168.2.1 Bcast:192.168.2.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST DYNAMIC MTU:1492 Metric:1
RX packets:50704 errors:0 dropped:0 overruns:0 frame:0
TX packets:43225 errors:0 dropped:0 overruns:0 carrier:0
collisions:24 txqueuelen:100
Interrupt:11 Base address:0x6100
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
ppp0 Link encap:Point-to-Point Protocol
inet addr:192.168.2.1 P-t-P:192.168.2.255 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:48473 errors:0 dropped:0 overruns:0 frame:0
TX packets:41056 errors:0 dropped:97 overruns:0 carrier:0
collisions:0 txqueuelen:3
Lassen Sie sich nicht vom lo-Eintrag verwirren. Dieses Loopback-Interface stellt sicher, dass sich Ihr Rechner auch ohne Netzzugang selbst TCP/IP-Pakete zusenden kann. Erst dadurch werden Dinge wie lokale Mailzustellung oder ein lokaler Web-Server möglich. ppp0 ist mit keiner Netzwerkkarte verknüpft, es ist vergleichbar mit lo kein physikalisches Interface. inet addr gibt die IP-Adresse des jeweiligen Interfaces an.
Die weiteren Parameter sind nicht weiter interessant, es kommt vielmehr darauf an, dass das jeweilige Interface überhaupt aufgeführt wird. Bei Interesse hilft http://www.linux.org/docs/ldp/howto/Net-HOWTO/index.html weiter.
Routing
Wenn alles glatt gegangen ist, sollte der Befehl route -n etwa folgende Routen für Ihre Datenpakete kennen (Verfügen Sie nur über eine Netzwerkkarte, fällt der Eintrag für eth1 weg.):
Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.2.254 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0 192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 0.0.0.0 192.168.2.254 0.0.0.0 UG 0 0 0 ppp0
Diese Tabelle ist wie folgt zu interpretieren: Die Ziel-Adressen, deren letzte Zahl eine Null ist, bezeichnen keinen Host, sondern ein Netz. Datenpakete, die für den für LANs reservierten Adress-Raum 192.168.1.1–192.168.1.254 gedacht sind, gehören ins lokale Netz und werden über die Karte eth0 abgewickelt. Analog wird das lokale Netz 192.168.2.0 über das Interface eth1 geroutet. Pakete an alle anderen Adressen (dies entspricht dem Eintrag 0.0.0.0) werden über das Device ppp0 ins Internet geleitet. Bitte beachten Sie, dass die Point-to-Point-Adresse als Gateway eingetragen wird, und nicht die Adresse des Devices.
Glossar
- Pseudo-Terminal
- Linux unterstützt das Konzept eines virtuellen Terminals. Ein Pseudo-Terminal ist nicht mit einem physikalischen Terminal verknüpft, sondern mit einem Unix-Prozess. Schreibt ein Programm auf das Pseudo-Terminal, erscheinen die Daten auf der Standard-Eingabe des dahinter liegenden Prozesses. Ansprechen lassen sich Pseudo-Terminals über Gerätedateien namens /dev/ptyx, wobei x eine Zahl von 0 bis 2048 sein kann. Pseudo-Terminals kann man nutzen, wenn beim Konfigurieren des Linux-Kernels im Abschnitt Zeichenorientierte Geräte der Punkt Unix98 PTY support aktiviert wurde.
- Patch
- Ein Patch (englische Bezeichnung für “Flicken”) ist in der Open-Source-Welt eine Datei, die die Unterschiede zwischen einem Original-Quellcode und einer verbesserten und/oder fehlerbereinigten Version enthält. Mit dem Einspielen des Patches in den originalen Quelltextbaum erhält man die neue Version.
