[linux-l] ping funktioniert nicht

[Steffen Dettmer]

* Ihno Krumreich wrote on Sun, Dec 07, 2003 at 22:20 +0100:
> On Sun, Dec 07, 2003 at 02:40:18PM +0100, Steffen Dettmer wrote:
> > * Peter Koppatz wrote on Sat, Dec 06, 2003 at 23:01 +0100:
> > > Ah jetzt d?mmerts: Werden die Pakete durchgereicht ohne sie
> > > zu manipulieren, dann tr?gt der Rechner den Titel: Router
> > > Wenn aber mit den Paketen ein wenig voodoo gemacht wird,
> > > ist es ein Gateway.  Hab ich das jetzt ein f?r allemal
> > > kapiert?
> > 
> > Na, so in etwa. Nach ISO ist ein Router ein Schicht-3 Dienst. Er
> 
> Routen ist ein Schicht 3 Dienst. 

Ja, so würde ich das sagen: Ethernet Schicht 2, IP Schicht 3, TCP
Schicht 4. (natürlich haut das nicht so richtig hin, weil ICMP
ja Schicht 4 ist, aber eigentlich zu IP gehört etc.).

> > kennt also das Netzwerkprotokoll (IP) und kann hier und darunter
> > was ?ndern, also fragmentieren, de-fragmentieren, NAT machen und
> 
> Fragmentieren und defragmentieren ist ein Funktion der Schicht
> 2 Der Router (in Schicht 3) hat davon keine Ahnung. 

Schicht 2, die Sicherungsschicht oder data link layer, kann ein
"Frame" (also ne Reihe von Bits) von einer Station zu einer
(direkt angeschlossenen) andere geschickt werden, und man hat
halbwegs Sicherheit, daß die Bits zu ankommen, wie man sie
geschickt hat. Damit ist CSMA/CD bei Ethernet beschäftigt. Ein
Frame hat ne bestimmte maximal-Größe, vielleicht 1500 Bytes
(Ethernet), vielleicht 378 (PPP, glaub ich) oder 56 (ATM, glaub
ich).

> Neben der Weiterleitung von Datenpaketen kann ein Router einen
> Medienwechsel vornehmen (Also vom lokalen Ethernet auf ISDN und
> beim Provider dann villeicht auf X.25 oder wieder Ethernet)

Nein, so einfach eben nicht. Ein Router kennt ja nur die Ziel-IP
Adresse des IP Packetes, aber keine X.25 Adresse für den Pfad.
X.25 steht auch nicht auf dem Niveau von Ethernet und "unter" IP,
sondern eher auf IP/TCP Ebene, BTW. 

Da braucht man dann ein Gateway. Das kann dann wissen, daß es den
Dienst ABC, den ein Client als "10.45.1.54, TCP port 4133" auf
dem Gateway anspricht, über eine X.25 Verbindung zu 845612141 mit
CUD "13444" im virtuellen Channel 0 abrufen muß, und in Channel 1
die Abrechnungsdaten und Authorisierung gemacht werden muß. Oder
sowas in der Art.

Das ist oft auch für den Clienten nicht mehr transparent.
Beispielsweise wenn man so ein "Pad" hat, was von einem Gateway
über X.3 (das ist sowas wie ein Hayes-Kommandosatz, nur eben
nicht AT-sonstwas, sondern eben anders) benutzt wird. Wenn man
z.B. HTTP über X.25 sprechen möchte (was sicherlich Blödsinn
ist), würde der Client vielleicht *vor* dem HTTP Header noch ein
Gatewayheader schicken müssen, vielleicht auch ein Handshake
machen, sowas wie Gateway-Anmeldung, CUD schicken, OK abwarten,
und dann den HTTP Header über die nun aufgebaute Verbindung
schicken.

Oft trixt man das auch transparent hin, in dem der Gateway z.B.
ne Tabelle hat:

Port   	Zielnummer	CUD	Channel
1000	889312412	1944	0
1001	889312412	1976	0
1002	889312412	1976	1
1003	889312418	1944	0
1004	889312418	1976	0
1005	889312418	1976	1

(vielleicht ist Port 1003 das Backup für Port 1000 und 1004 für
1001 usw.). Essentiell ist jedenfalls, daß das Gateway
zusätzliches Wissen braucht. Ein Router ist für ein Protokoll,
z.B. IP *oder* X.25 (obwohl er dann wohl eher Datex-P-Node heißt
oder weiß ich was). Vielleicht hat er das Wissen in Form einer
Tabelle, vielleicht kommt es vom Clienten, oder beides, aber es
gibt Wissen, daß über das IP hinausgeht (IP kennt ja kein CUD,
bei X.25 ist es oft sehr wichtig).

In der Praxis trixt man manchmal noch weiter: da hat man
plötzlich in einem IP Netzwerk ne ISDN Strecke. Paßt überhaupt
nicht. Doof. Also nimmt man sich ein Gateway, der ISDN kann. Das
heißt dann HDLC anstatt Ethernet und darauf läuft dann X.75 oder
sowas. Nun kann ein Router damit nicht so viel anfangen, weil das
dann z.B. keine 65535 ports mehr kann (sondern nur 10 oder was
X.75 bietet, weiß nicht genau). Also packt man oben auf das X.75
ein PPP Protokoll. Da oben drauf packt man dann wieder ein IP,
und nun kann man das IP aus dem LAN "tunneln". Natürlich muß die
Gegenstelle das genauso (bzw. rückwärts machen), aber dann ist es
transparent. Das ist ne sehr häufige Sache, nämlich wenn man z.B.
mit Windows "über ISDN ins Internet geht". Das Gateway, also der
PPP-Daemon braucht zusätzliches Wissen, hier als "Tabelle", da
steht dann ein PPP-Password drin, LCP Optionen, IP-Adressen, die
vereinbart werden und auf X.75 "gemappt" werden (was hier ja
einfach ist, weil man bei solchen Verbindungen immer weiß, wer
genau an der Gegenstelle sitzt, nämlich genau einer, und das ist
auch ein PPP-Daemon). Das sieht dann für die Clienten prima
Transparent aus, aber auch für den Server: beide sehen X.75 ja
nicht, es wird nur zwischendruch was getunnelt. Tunneln ist eine
schöne umkehrbare Gateway-Aufgabe und geht daher "zufällig"
transparent.

PPP ist überhaupt CooL; kann zwar nur peer-to-peer Verbindungen,
dafür aber mehrere Protokolle: so kann man auch IPX gleich
mittunneln. Ethernet kann das auch, aber ein IP-Router kann IPX
eben nicht routen, und von IPX auf IP zu wechesln geht auch nicht
(Netware bietet auch einfach "zwei" gleiche Dienste an, einmal
über IPX, einmal über IP, wenn man Glück hat, funktioniert eins
davon :)).

Ist vielleicht mal interessant, sich ein Trace von so einem Stack
anzugucken. Man sollte einen Tracer haben, der die Protokolle
kennt und entsprechend anzeigt. Da kann man dann erkennen, wie
die "geschachtelt" sind, daß vor dem ersten IP Frame schon z.B.
sieben PPP Frames getauscht wurden etc. Davor kam vielleicht ein
"ATZ\nATDT123451212\n", was da überhaupt nicht reinpaßt :-) Fetzt
schon.

> > vor allem an die n?chste Station per Ethernet senden (also neues
> > Ethernetframe bauen). Ein Router wei? also, da? er ein IP Frame
> > hat, aber nicht, ob das ein HTTP Request oder eine DNS Anfrage
> > ist. Es interessiert ihn nicht.
> 
> Genauso interressiert es ihn nicht wie die darunterliegenden
> Schichten ein IP-Pakete transportieren.

Ja, wenn es denn IP ist. Du kannst aber über ISDN erstmal kein
IP-Frame schicken, weil auf der Gegenstelle erstmal keiner was
damit anfangen kann. Du kannst da natürlich ein IP Frame direkt
in ein HDLC Frame einpacken, so wie man es in ein Ethernetframe
einpacken kann, aber es packt dann niemand aus. Im Ethernet
gibt's ein Protokolltyp für IP (zwei Byte im 802.3 oder weiß ich
was das ist), im HDLC gibt's sowas nicht. Wenn Du einen seriellen
Draht hast, an dem z.B. ein X.3 Pad hängt, oder ein Hayes-Modem,
kann man dem natürlich ein IP Frame direkt schicken, aber das
kommt nur zu einem "ERR" oder "ERROR". Das Pad erwartet eben
sowas wie ein "stat" und das Modem sowas wie ein "ATDT" oder
irgendwas, bevor überhaupt was mit einer Gegenstelle passiert.
Wenn man per Modem eine klassische Mailbox anruft, kommt nach dem
ATDT etc. das Frame auch an, aber vermutich wird die Mailbox mit
"Login incorrect\n\nLogin:\n" antworten, was der Router verwirft,
da es gar kein gültiges IP Frame ist... Es paßt einfach vorn und
hinten nicht.

> Auch ich bin mit dem Begriff Gateway schlampig umgegangen! Aber
> ich werde mir obige treffende Definition zu Herzen nehmen und
> in Zukunft Gateway wieder korrekt benutzen.

Na ja, meistens ergibt sich die Bedeutung ja aus dem Kontext.

Aus der anderen Mail:

> Der Begriff Gateway bezeichnet einen Rechner, durch den man
> durch muss, um zu einem bestimmten Bereich zu gelangen.

Das kann aber auch ein Router sein :) Durch den muß man ja auch
"durch", um zu einem bestimmten Bereich (subnetz) zu gelangen.

> Es ist dabei egal, ob die Technologie Router, NAT oder Proxy
> ist.

Router und NAT sind für mich eines (nämlich was auf IP Ebene),
Proxy was anderes und Gateway wieder was anderes. Ich hab z.B.
mal an einem X.75 -> TCP Gateway mitgearbeitet. Das funktioniert
so: Client baut eine X.75 Verbindung auf. Die ist dann da und
redet mit einem Dienst. Der liest dann erstmal eine Zeile, in der
muß ne IP Addresse, ein Doppelpunk und ein Port stehen. Dann hat
das System ne Liste von ein paar IPs, die irgendwie per Routing
erreichbar sind (meistens PPP). Kommt der Client an, sendet er
also die IP und den Port. Der Gateway baut dann ne TCP Verbindung
dorthin auf, was klappt, wenn die in der Routingtabelle steht und
die entsprechende PPP Verbindung (die weiteres Wissen hat,
beispielsweise Passwörter) geklappt hat. Der Rest der Daten wird
dann bidirektional (und ab da transparent) kopiert. Das
Gatewayprotokoll ist damit nach dem Aufbau transparent (damit
mußte an den Clienten wenig geändert werden), aber auch
eingeschränkt (man kann z.B. nicht die IP wechseln, man muß die
X.75 Verbindung abbauen und eine neue aufbauen, was hier
unerheblich war, weils sowas fast nie gibt in dem Fall). Ändert
die Gegenstelle ihre Telefonnummer oder ihr PPP Passwort, muß das
Gateway umkonfiguriert werden (ändert sich in einem IP Netz eine
IP Adresse, so muß i.d.R. kein Router umkonfiguriert werden,
sondern nur die Clienten).

Ist schon eine interessante Welt. Außerhalb von IP zum Teil zwar
ziemlich genial, aber auch weniger einfach, find ich, und vor
allem immer ziemlich anders/speziell. 

oki,

Steffen

-- 
Dieses Schreiben wurde maschinell erstellt,
es trägt daher weder Unterschrift noch Siegel.