Informationen zu Gateways und Routing unter Windows

Informationen zu Gateways:

0) Auf Windows 7 muss der Dienst Routing und RAS laufen, damit zwischen den einzelnen NIC Subnetzen Daten geroutet werden. Das Anhalten des Dienstes ist im Verhalten gleich dem Gestartetsein. Also wenn man kein Routing haben will, dann muss man den Dienst wirklich beenden. Ohne Routing und RAS kann man aber als Host, welcher ja mehrere NICs besitzen kann um damit Mitglied der verschiedenen Subnetze sein zu können, kann man aber die Subnetz Mitglieder erreichen. Nur die Kommunikation von anderen Subnetz Mitgliedern untereinander wird durch das Abschalten des R.u.-RAS unmöglich.

1) Jedes Gateway auf einer Netzwerkschnittstelle kann nur die IP der Schnittstelle oder eine IP auf dem zugehörigen Subnetz sein.

2) Das Gateway für das Netzwerk einer Netzwerkschnittstelle ist immer die IP der Schnittstelle, d.h. der Rechner selbst ist sein Gateway

3) Ist kein Default Gateway definiert, so ist die IP der Netzwerkschnittstelle selbst per Definition das Default Gateway

4) In der Routingtabelle wird das Zielnetzwerk für ein Paket bestimmt. Im ersten Schritt wird das Gateway bestimmt, welches entweder

4.1) die IP der Netzwerkschnittstelle ist:
Es wird in der Routingtabelle des Rechners, welcher mehr als eine Netzwerkschnittstelle besitzen kann, ermittelt für welchen Empfänger das Paket ist.
4.1.1) Falls es einer der IPs seiner NICs ist, dann erfolgt die Auslieferung an diesen Rechner selbst.

4.1.2) Falls nicht, dann wird über alle Routen auf allen NICs ermittelt, ob es einen Ausgang gibt. Unter den vielen möglichen Ausgängen wird jenes gewählt, das die kleinsten Kosten ausgedrückt als Metrik besitzt. Auf diesem Ausgang wird an das ermittelte Gateway an dessen mit arp aufgelöste MAC Adresse das IP Paket mit der unveränderten IP Quell- und Zieladresse gesendet. Das Gateway erhält also auf seinem MAC Level ein IP Packet, das nicht seine IP als Zieladresse aufweist. Wenn das Gateway nicht als Router konfiguriert ist, wird es ein solches Paket verwerfen. 

4.2) eine IP im Netzwerk der Netzwerkschnittstelle:
Es wird die MAC Adresse des Gateways per arp ermittelt. Dann wird das IP Paket mit unveränderter IP Zieladresse an die Ethernetadresse des Gateways geschickt.
Der Gateway Rechner bekommt also ein Ethernet Paket, das zwar seine MAC Zieladresse trägt, aber dessen IP Nutzlast eine Ziel-IP hat, die nicht seine Eigene ist. Für die weitere Behandlung ist der Gateway verantwortlich.

5) Man kann auf Senderseite nicht bestimmen, dass ein Paket über einen bestimmten Zwischenknoten gehen soll.

3) Will man 5) erreichen, so geht das nur mit:
3.1) Man benutzt auf Senderseite einen Proxy, dessen Proxyadresse der Zwischenknoten ist. Dann muss auf dem Zwischenknoten auch ein Proxy Server laufen. Dabei werden die eigentlichen Zieladressen dem Proxy als Content im IP Paket mitgeteilt. Das Proxy Protokoll ist ein Anwendungsprotokoll, das mit IP an den Proxy Server und Client gesendet wird und welches dann auf den Endpoints entpackt und ausgewertet wird. Also encapsultated FTP(udp), HTTP(TCP),SMTP(UDP?).

3.2) Das verwendete Gateway weiss um den Willen des Senders und richtet mittels iptables eine Forwarding rule ein, mit dem es die Pakete vom Sender an den geünschten Zwischenknoten sendet und diesem es überläßt das Paket zu routen. Der Zwischenknoten muss hierbei aber auch so konfiguriert sein, dass er eine funktionierende Rückroute an den ersten Sender hat.

3.3) Das verwendete Gateway weiss um den Willen des Senders und macht ein transparentes Routing aka transparentes Proxying. Dabei verwendet es NAT im MASQUERADING Modus. Es erzeugt also dynamisch Proxy Verbindungen mit seiner IP im Netz des Zwischenknotens und leitet den Verkehr darüber stellvertretend für den Ausgangsserver weiter. Dabei merkt er sich die ausgehende Verbindung und rückübersetzt die Antworten an den Ausgangsserver zurück. Dies nennt man transparentes Proxying, da der Client nicht konfiguriert werden muss. DNAT ist also gleichbedeutend mit transparentem Proxing.

3.3) Das verwendete Gateway weiss um den Willen des Senders und hat eine Netzwerkbrücke über die Netzwekschnittstellen "Mit_Sender_Verbunden"  "Mit_Zwischenknoten_Verbunden" eingerichtet. Auf diesem Brücken-NIC kann er nun sowohl eine IP aus dem "Mit_Sender_Verbunden" Netzwerk als auch Eine aus dem "Mit_Zwischenknoten_Verbunden" Netzwerk vergeben. Dadurch dass das Gateway nun über sein Brücken-NIC direkten Zugang zum Zwischenknoten hat (Ethernet-Ebene), kann es als sein Brücken-NIC als default Gateway die IP des gewünschten Zwischenknotens eintragen und es wird klappen. Denn der Zwischenknoten ist nun in einem seiner Subnetze, die per Brücken-NIC vereint sind.
Notiz: VMWare-Host-Only-Nic läßt sich leider nicht in eine Brücken-NIC eintragen. Der Adapter unterstützt diese Operation nicht. Aber theoretisch ist die Zusammenschaltung von Subnetzen in Brückennetzen möglich unter Windows.

3.3.1) Variante: Brücke auf Ebene 2 (Link-Layer?, MAC Ebene)
Die beiden NICs des Host, die Zugang zur Brücken-NIC haben, bekommen eine zweite IP aus dem Fremd-Subnetz bzw. können sich eine vergeben. Dann können sie arp verwenden, um die IPs aus beiden Subnetzen zu ermitteln. Der Brücken-NIC braucht keine IP, da es sich wie ein HUB bzw. Layer-2-Switch verhält und die Ausgangs Nicks an diesen angeschlossen sind.

3.3.2) Variante: Brücke auf Ebene 3 (IP Layer)
Die Brücken-NIC ist als Router zu betrachten, der zwei NICs hat, welche jeweils mit den Subnetzen der beteiligten Ausgangssubnetze verbunden sind. Hier muss der Brücken-Nic je eine freie IP aus den beiden Ausgangssubnetzen bekommen und die Ausgangsnics müssen eine Route zum jeweiligen anderen Subnetz über die Gatewayadresse des Brücken-Nics setzen. Die jeweilige Brücken NIC ist ja jeweils aus einem Netz ein erreichbares Ziel.

3.3.3) Am ehesten ist Variante 3.3.1 zu vermuten!!!

==========================================================

IP Protokoll:

Ist Vermittlungsprotokoll und entspricht OSI ...

Sein Content sind Transportprotokolle.
Diese Umfassen ICMP (echo,Flussteuerung - SourceQuench,...), TCP (6), UDP(7?9?),

Kennen nur Quell und Ziel IPs.

Routing passiert auf IP Ebene.

Daneben gibt es Transportschichtebene nur für TCP und UDP Portnummern.
Diese klassifizieren einige wohl bekannte Anwendungsprotokolle auf Anwendungsebene, je TCP oder UDP verschiedene. Es ist also möglich, dass ein und dieselbe Portnummer für verschiedene Anwendungen steht, je nachdem, ob es sich um TCP oder UDP als darunterliegendes Transportprotokoll handelt.

Einige Anwendungsbeispiele:
UDP: SMTP(25), ftp(23), DNS, etc.
TCP: HTTP(80), HTTPS(443), etc.

Sowohl bei UDP als auch bei TCP kennt man Sockets und Socket-Pairs.
Dabei ist ein Socket das Tupel Socket=(IPAdress,Portnumber).
Ein Socket-Pair ist ein Tupel SocketPair=(SourceSocket,TargetSocket).

Derjenige, welcher zuerst eine Verbindung zum Anderen aufbaut, ist in der Rolle des Client und der Andere in der des Servers.

Der Server wird mit der Well-Known Portangabe im TargetSocket angesprochen.
Der Port im SourceSocket wird dynamisch zugewiesen und nachdem der Target angesprochen ist, kennt dieser den SourceSocket und damit dessen dynamischen Port. Wenn der TargetSocket nun dem Sender antworten möchte, dann verwendet er einfach den SourceSocket als seinen TargetSocket und den TargetSocket des Senders als seinen SourceSocket.

Im Gegensatz zu TCP kennt das UDP Protokoll keine verbindungsorientierte Kommunikation, in der die Reihenfolge der Empfang gesendeten Inhalte in der Socketkommunikation auf Transportprotokollebene sichergestellt ist. Vielmehr kann dies auf Anwendungsebene z.B. ftp geschehen. Die Verantwortung obliegt also der Anwendung.

Bei TCP hingegen wird der Anwendungsebene als Transportprotokollfeature diese Funktionalität bereitgestellt, so dass die Anwendung sichergehen kann, dass Daten als geordneter Strom von Bytes vorliegen. Dazu baut das TCP eine virtuelle Verbindung über ein 3-Wege-Handshake auf und schließt am Ende der Kommunikation diese über ein weiteres 2?-Handshake. Dazu werden sogenannte SYN,ACK,FIN, etc Flags im TCP Header verwendet und außerdem SIDs (Startzähler beim Client und Server) zur Bestätigung der zuletzte empfangenen Bytenummern als Bestätigungsmarker (ACK) mitgeschickt. Es wird außerdem ein Empfangsfenster definiert, bis zu der einer der Kommunikationspartner Bytes senden darf, bevor noch eine Bestätigung des Empfangs eintritt. Quasi ein Blankobrief, bis zu der alles gesendet werden darf. Der Empfänger kann nun z.B. nur die Hälfte des Empfangs bestätigen und der Sender beginnt das erneute Senden ab der neuen Position ohne weiteres zutun des Anwendungsprogrammes. Das Neusenden erfolgt dabei nach einem Timeout, wenn bis dahin die gesendeten Bytepositionen nicht bestätigt werden.
??Entweder auf ICMP Ebene, Geschwisterprotokoll zu TCP, oder zusätzlich auf TCP Ebene kann der Empfänger den Sender dazu auffordern, das Sendevolumen zu drosseln. Im letzteren Fall in Verbindung mit TCP über das setzen eines kleineren Sendefensters. Wschl. ist die Benutzung von ICMP SourceQuench allgemein das Signal, dass die IP Schicht allgemein die Verarbeitung beliebiger Transportprotokolle nicht bewältigen kann und daher IP Paket im Empfangspuffer verloren zu gehen drohen.

?Ein Socket-Pair ist immer als ein Vollduplex Kanal zu betrachten. Wenn der Client sendet, dann schreibt es in seinen lokalen Socket. Aufgrund dessen, dass dieser mit dem Remote-Socket verbunden ist, landet alles beim Remote-Server.
Wenn der Client empfängt, dann liest es seinen lokalen Socket. Wiederum ließt er mittelbar aus dem Remote-Socket.
Der Sever seinerseits sendet an den Client, indem er in seinen lokalen Socket, welcher der Remote-Socket des Clients war, schreibt und es landet im Remote-Socket des Servers (=lokaler Socket des Clients). Analog ließt er seinen lokalen Socket und mittelbar damit seinen Remote-Socket.

Die jeweiligen Remote Sockets im Gespann von SocketPair=(LocalSocket,RemoteSocket) werden also nur mittelbar über den LocalSocket gelesen oder geschrieben.