Die Zutaten
Im Abstrakt war es bereits kurz angerissen worden, was zur Verfuegung steht: Ein Uralt-Notebook von Toshiba mit der Typenbezeichnung T4400C (das C steht fuer Color). An Anschluessen gibt es das, was in den fruehen 1990er Jahren typisch war: Seriell, Paralell, VGA und als Leckerbissen PS/2. Naja, und noch eine Stromversorgung. Kein USB, kein PCMCIA-Slot. Ach ja, da war noch ein hoechst proprietaerer Anschluss fuer eine Docking-Station... aber lassen wir das, die Wahrscheinlichkeit, so eine aufzutreiben ist eher 0.
Was ist sonst noch an Material in der Bastelkiste des Netzwerkfrickelns, was in der Naehe der Maschinen bleiben kann? Eine Linux-Kiste mit einem steinalten SuSE 8.1, serielle Kabel und noch das Uebliche an Hilfsgeraeten (serielles Terminal oder etwas in der Art).
Die Grundidee
Die Grundidee war die Uebliche: http://google.de/.
Das fuehrte mich zu http://linuxgazette.net/issue41/smyth.html. Der Ansatz ist Folgendes: Das Windows wird mit einem Null-Modem-Kabel mit der Linuxbox verbunden. Auf dem Windows wird eine Modemeinwahlverbindung eingerichtet und das Linux emuliert das Modem gleich mit. Auf der Linux-Seite wird ein ganz normales serielles getty gestartet, als wenn es fuer normale Nutzerlogins per seriellem Terminal waere. Und den Rest uebernehmen die beiden kleinen Helferlein pppd und chat. Und dann ist das Grundproblem geloest, der Rest sollte nur noch irgendwie-muessen-die-Daten-von-einem-Interface-zum-Anderen sein. Also eigentlich ja kinderleicht.
Die Umsetzung
Wie ueblich ist die Theorie einfach, schlicht und elegant. Und die Praxis widerborstig und voller Engstellen. Aber von Anfang.
Die serielle Verbindung war kein Problem, momentan haengt am seriellen Anschluss der Linuxbox ein Terminal. Check.
Ich habe wie im Artikel der linuxgazette beschrieben einen Nutzer fuer die PPP-Verbindung angelegt und ihm die richtigen Rechte sowie pppd das setuid-Flag gegeben. Auch check.
Die Datei .ppprc im Home des PPP-Nutzers angelegt und von der linuxgazette kopiert. Ihm pppd als Shell gegeben. Check.
Auf dem Windows eine Modemverbindung ohne Nutzernamen angelegt und die gewuenschten Optionen eingestellt. Auch Check.
Jetzt sollte es eigentlich klappen.
Eigentlich.
In der Praxis sah es wie folgt aus: Das Windows beginnt mit der Einwahl, zeigt mir das Prae-Waehl-Terminalfenster, ich logge mich darauf ein, sage dem System, es soll weitermachen (F7) und... bekomme eine Meldung, dass das Modem nicht mit dem Windows reden will. Das Windows ist ganz doll traurig und fragt tapfer, ob es in 60, 59, 58, ... Sekunden den naechsten Anlauf nehmen soll.
Und nun?
Ich dachte, es waere einfach (nur abschreiben). Was kommt nach dem Denken? Das Nachdenken. Das tat ich dann. Als erstes stellte sich mir die Frage, ob das mit der Shell funktioniert. Das tat es, prinzipiell. Wenn ich die richtige Kommunikation mitchat fuehre. Gegeben war im Artikel der linuxgazette die folgende Kommunikation:
PC Modem
ATH
OK
AT
OK
ATE0V1
OK
ATX3
OK
ATDT
CONNECT
ab hier reden dann PPPs miteinander.
Woher weiss ich eigentlich, dass das auch wirklich so ist? Also mal das Windows, dass sich anmelden will seriell umgestoepselt -- an ein anderes Terminal. Dann erstmal ohne nachzudenken alle Anfragen mit "OKCONNECT) das Kabel ziehen um den Rest nicht vom Bildschirm zu verlieren ;)Dieses simple Experiment ergibt den folgenden Dialog:
PC Modem
AT
OK
ATE0V1
OK
AT
OK
ATDT1
CONNECT
PPP-Gequassel.
Das sieht dann doch ein wenig anders aus, als im Artikel der Gazette. Moeglich, dass ich einen anderen Treiber in einer anderen Windows-Version genutzt habe. Und ein Detail, ueber welches ich mich schon gewundert hatte -- Wie soll das klappen, wenn dem ATDT-Befehl keine Nummer folgt? Schliesslich laesst Windows nicht zu, dass man eine Modem-Verbindung waehlt, ohne eine Telefonnummer eingegeben zu haben. Input validation bei der Arbeit. In dem von mit mitgeschnittenen Ausschnitt war es eine 1 als Telefonnummer. Also mal die .ppprc angepasst. Das Ergebnis sieht dann wie folgt aus:
connect '/usr/sbin/chat -v AT OK ATE0V1 OK AT OK ATDT1 CONNECT' -detach modem lock :172.16.0.90Ich habe auch auf die Hardware-Flusssteuerung verzichtet - in meinem Nullmodemkabel sind die entsprechenden Adern schlicht und ergreifend nicht durchgeschleift. Und da ich nur mit 9600 Baud arbeite und auch nicht beabsichtige, dies zu aendern sollte es auch keine Notwendigkeit geben. 9600 Baud wird meine Linuxbox eigentlich immer ins LAN loswerden koennen. Ausserdem ist die IP an meine Verhaeltnisse angepasst.
Ausprobiert. Und siehe da, ich habe ein
ppp0-Device auf der SuSe geschenkt bekommen:
ppp0 Protokoll:Punkt-zu-Punkt Verbindung
inet Adresse:172.16.0.99 P-z-P:172.16.0.90 Maske:255.255.255.255
UP PUNKTZUPUNKT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:8328 errors:0 dropped:0 overruns:0 frame:0
TX packets:8639 errors:0 dropped:0 overruns:0 carrier:0
Kollisionen:0 Sendewarteschlangenlaenge:3
RX bytes:376348 (367.5 Kb) TX bytes:1452654 (1.3 Mb)
Das sieht so schonmal ganz schoen aus. Die beiden nun verbundenen Kisten koennen sich auch froehlich gegenseitig mit Pings oder TCP erreichen. Sehr fein, erstmal. Und nun der Rest der Welt. Erste Idee: NAT. Denn dann muss man nicht an den LAN-weiten Routing-Tabellen rumspielen und feste IPs vergeben.
Ich, NAT und meine SuSE
Auf einem FreeBSD haette ich jetzt einfach NAT mit ipnat gemacht, die Regel waere schlicht und ergreifend map eth0 172.16.0.90/0 -> 0/32. Aber wie macht man das auf einer SuSE?
SuSE war ja eine der Distributionen, die den Nutzer wo immer es geht vom haendischen Editieren der Konfigurationsdateien befreien moechte (um es mal freundlich auszudruecken). Also wird man das wahrscheinlich mit dem Allzwegprograemmchen yast machen koennen. Hoffentlich. Also einem ersten Reflex folgend mal in Richtung Firewall getappst...
yast @ linux +------------------------------------------------------------------------------+ | Yast2 Control Center | +------------------------------------------------------------------------------+ | | | +--------------------------+ | | | Software | | | | Hardware | | | | Netzwerk/Basis | | | | Netzwerk/Erweitert |+--------------------------------------------+ | | | Sicherheit & Benutzer ->|| Benutzer bearbeiten und anlegen | | | | System || Einstellungen zur Sicherheit | | | | Sonstiges || Gruppen bearbeiten und anlegen | | | | Verlassen || Firewall | | | +--------------------------++--------------------------------------------+ | | | | | | | | Firewallkonfiguration für fortgeschrittene Anwender | | | | | | [Hilfe] [Verlassen] | | | +------------------------------------------------------------------------------+Dort kann man (um mal nicht alles als Screenshot zu zeigen...) dann Folgendes einstellen:
- Interne/Externe Schnittstelle fuer NAT (gut).
- Firewall: Welche Dienste dieser Maschine sollen von der externen Schnittstelle aus erreichbar sein? Gegeben sind zum Ankreuzen nur http/https/smtp/pop3/pop3s/imap/imaps/telnet/ssh/rsync. Ach ja, und eine Textbox, in die man bei Bedarf weitere Ports durch Leerzeichen getrennt eingeben kann. Ich will aber nur NAT und keine Firewall, denn das externe Interface haengt ja nur in meinem LAN, nicht im Internet.
- Im naechsten Dialog ging es dann schonmal weiter in Richtung NAT: Man kann Traceroute sowie Masquerading (NAT) ueberhaupt erlauben.
- Auf der letzten Seite schliesslich kann man noch das Logging einstellen.
Also doch Routing
Zunaechst einmal testweise auf meinem FreeBSD-Notebook von Hand die Route gesetzt und ein paar Pings geschickt. Meh, geht nicht. Irgendwie will die SuSE die Pakete nicht routen. Muss man das diesem System von Hand sagen?
+------------------------------------------------------------------------------+ |+--------------------+ Routing-Konfiguration | || In diesem Dialog + | ||kann das Routing | Standardgateway | ||eingestellt werden. | 172.16.0.200##############################v | ||Die Standard-Route | | ||(Default-Route) | +Routing-Tabelle--------------------------+ | ||betrifft jedes | |[ ] Konfiguration für Experten | | ||mögliche Ziel; | |+---------------------------------------+| | ||jedoch mit der | ||Ziel |Dummy oder Gateway|Netzmas|| | ||Einschränkung, dass,| || || | ||wenn ein anderer | || || | ||Eintrag existiert, + || || | ||der auf eine | |++----------------------------+---------+| | ||gewünschte Adresse | | [Hinzufügen][Bearbeiten][Löschen] | | ||passt, dieser | +-----------------------------------------+ | ||anstelle der | | ||Standard-Route | [x] IP-Weiterleitung aktivieren | ||verwendet wird. | | ||Durch die Angabe | | ||einer Standard-Route| | |+--------------------+ [Zurück ] [Abbrechen] [Beenden] | +------------------------------------------------------------------------------+Ja.
Aber danach klappte es. Um einen Eindruck zu geben:
\
D a s \
\
I n t e r +--[172.16.0.200]-------+----------+----------[172.16.0.99]-------[172.16.0.90]
/ Default-gw | | linuxbox Windows per PPP
n e t / DHCPD | ...
/ [172.16.0.103]
(Unendliche Weiten) / Mein Notebook
Um den Zustand festzuhalten: Die "normale" Gateway verteilt nun auch die Information, dass man die 172.16.0.90 erreicht, indem man die 172.16.0.99 als Route nutzt. Und alles ist fein.
Und warum jetzt dieser Aufwand?
Warum nun dieser Aufwand, nur um eine total veraltete Hardware irgendwie ans Netz zu bringen?
- 1. Weil ich kann.
- 2. Weil eine serielle Verbindung sehr viel schneller mit MacGuyver-Mitteln improvisiert werden kann als eine Ethernetverbindung. Ich will nicht dazu aufrufen, aber man kann es sogar ohne Stecker nur mit Blumenbindedraht schaffen :D
- 3. Weil dieses Wissen ueber das zarte Menuett von
chatundpppdvielleicht nochmal hilfreich werden kann. Es gibt mehr aeltere Systeme, als man denkt .. und es ist immer gut zu wissen, wie man diese im Zweifelsfalle mit einem modernen System koppeln kann. - 4. Weil ich nun eine kabelgebundene Verbindung zweier Rechner habe, die eine geringere Bandbreite hat als 1.44MB-Disketten.
Ach ja, und WinSCP laeuft nicht, weil eine Abhaengigkeit auf dem Windows 95 fehlt.