Kommunikation auf Schicht 3

[Eleu]

Hallo,

mit dem Winsock Steuerelement kann man prinzipiell Nutzdaten, entweder über UDP oder TCP übertragen (Socket)

Wenn ich es richtig verstanden habe, befindet sich das TCP Protokoll, dann bei der Kommunikation in den Nutzdaten des IP Paketes.

Ist es irgendwie möglich, mit Visual Basic direkt auf diesen Nutzdatenbereich des IP Paketes zu schreiben.

Also direkt Nutzdaten auf Schicht 3 übertragen zu können (Ohne Socket).

Ich habe in dem Zusammenhang etwas über ICMP Tunneling gelesen.

Gruß

Eleu

https://de.wikipedia.org/wiki/ICMP-Tunnel

 

Bearbeitet 20. März 2017 von Eleu

[etreu]

Was willst du denn genau machen?

Hast du denn verstanden wie der Tunnel funktioniert und warum das gemacht wird?

[Eleu]

Die Frage ist eigentlich theoretischer Natur.

Ziel könnte z.B. sein, eine schlankere und somit schnellere Kommunikation aufzubauen, da ja dann die ganzen Kontrollmechanismen

die  in TCP enthalten sind, entfallen 

[Gast halcyon]

Man kann mit hardwarenahen Sprachen (z. B. C) direkt Bytes über eine serielle Schnittstelle senden. Das ist natürlich möglich denn letztendlich passiert ja genau das auf der untersten Ebene.

Das Problem dabei ist: Der Gegenüber muss die auch Lesen können. Was du tust ist dann im Endeffekt ein neues Protokoll zu implementieren. Wenn du zwei Geräte miteinander direkt verbindest (zwei Computer mit einem Kabel), die beide dein Protokoll verstehen - kein Problem. Sobald du aber die Daten über ein Netzwerk mit Standard Komponenten verschickst, wird dein Paket bereits am ersten Layer3 Switch verworfen werden. Grund: Die können mit deinem Byte-Strom nichts anfangen, weil die dein Protokoll nicht kennen. In dem TCP Header sind ja bswp. Adresse des Senders und des Empfängers enthalten, und die werden an expliziten Bit-Stellen durch die Geräte/Software ausgelesen, die ein Paket passiert.

Wenn man die Kontrollmechanismen von TCP nicht benötigt - ich verstehe hier runter die Bestätigung und das erneute senden des Paketes im Fehlerfall - dann nimmt man dafür üblicherweise UDP.

Bearbeitet 20. März 2017 von halcyon

[Eleu]

vor 9 Minuten schrieb halcyon:

Man kann mit hardwarenahen Sprachen (z. B. C) direkt Bytes über eine serielle Schnittstelle senden. Das ist natürlich möglich.

Das Problem dabei ist: Der Gegenüber muss die auch Lesen können. Was du tust ist dann im Endeffekt ein neues Protokoll zu implementieren. Wenn du zwei Geräte miteinander direkt verbindest, die beide dein Protokoll verstehen - kein Problem. Sobald du aber die Daten über ein Netzwerk mit Standard Komponenten verschickst, wird dein Paket bereits am ersten Layer3 Switch verworfen werden. Grund: Die können mit deinem Byte-Strom nichts anfangen, weil die dein Protokoll nicht kennen. In dem TCP Header sind ja bswp. Adresse des Senders und des Empfängers enthalten, und die werden an expliziten Bit-Stellen durch die Geräte/Software ausgelesen, die ein Paket passiert.

Wenn man die Kontrollmechanismen von TCP nicht benötigt - ich verstehe hier runter die Bestätigung und das erneue senden des Paketes im Fehlerfall - dann nimmt man dafür UDP.

Hallo und Danke,

ich glaube das habe ich soweit verstanden.

Ich hatte zu dem Thema auch folgendes im Netz gefunden:

https://msdn.microsoft.com/de-de/library/system.net.networkinformation.ping(v=vs.110).aspx

Es geht dort um die Verwendung der Ping Klasse

Da wird die Methode Send(String) aufgeführt.

Was bringt mir das, einen String zu senden, wenn auf der Gegenseite nichts damit gemacht wird?

Wozu ist das gut?

Gruß

Eleu

[Gast halcyon]

9 minutes ago, Eleu said:

https://msdn.microsoft.com/de-de/library/system.net.networkinformation.ping(v=vs.110).aspx

 

Es geht dort um die Verwendung der Ping Klasse

Da wird die Methode Send(String) aufgeführt.

Was bringt mir das, einen String zu senden, wenn auf der Gegenseite nichts damit gemacht wird?

Die Methode erwartet als String die IP Adresse oder den Hostname des Computers, an dem der Ping Befehl geschickt werden soll. Nur damit das klar ist: Du befindest dich hier auf Layer 7. Das ist schon die Kapselung der Kapselung der ... Auf den Schichten darunter wird dann das TCP/IP Paket gestrickt, mit der Adresse/Hostname, den du als String hier übergeben hast.

Bearbeitet 20. März 2017 von halcyon

[Eleu]

vor 3 Minuten schrieb halcyon:

Die Methode erwartet als String die IP Adresse oder den Hostname des Computers, an dem der Ping Befehl geschickt werden soll. Nur damit das klar ist: Du befindest dich hier auf Layer 7. Das ist schon die Kapselung der Kapselung der ... Auf den Schichten darunter wird dann das TCP/IP Paket gestrickt, mit der Adresse/Hostname, den du als String hier übergeben hast.

Ach so...

Danke dir.

[Eleu]

Guten Morgen,

ich bin es noch Mal.

Ich habe das nachfolgende Skript auf meinem Host ausgeführt, welches m.E. die Ping - Klasse verwendet:

Set MyShell = CreateObject("WScript.Shell")
 Set MyFiles = CreateObject("Scripting.FileSystemObject") 
 IP = "192.168.4.20"


Proggi = "%comspec% /c ping.exe -n 1 -a" & " " & IP & " " & ">c:\temp\temp.txt"
 Return = MyShell.Run(Proggi,0,True) 
 Set TempFile =MyFiles.OpenTextFile("C:\temp\temp.txt") 
 Abfrage = Tempfile.Readall
 If instr(Abfrage, "ytes=") > 0 Then
Ausgabe = MsgBox("Ping an " + IP + " erfolgreich!", 1)
 Else
Ausgabe = MsgBox("Host " + IP + " nicht erreichbar", 1)
 End if
tempfile.close

Gleichzeitig habe ich mit wireshark mitgesniffert und als Filter habe ich "ip.addr == 192.168.4.20" eingegeben

 

vor 16 Stunden schrieb halcyon:

Die Methode erwartet als String die IP Adresse oder den Hostname des Computers, an dem der Ping Befehl geschickt werden soll. Nur damit das klar ist: Du befindest dich hier auf Layer 7. Das ist schon die Kapselung der Kapselung der ... Auf den Schichten darunter wird dann das TCP/IP Paket gestrickt, mit der Adresse/Hostname, den du als String hier übergeben hast.

Sorry, ich sehe da kein TCP / IP, sondern nur das IP - Protokoll und das ICMP Protokoll.

Wenn ich aber doch nun dem IP -Paket Nutzdaten hinzufügen könnte, die auf der Gegenseite ausgelesen werden können, hätte ich doch eine Möglichkeit das ICMP Protokoll für mich zu nutzen.

Beim ICMP Tunneling wird das doch auch gemacht?

Zum, Beispiel beim ssh icmp tunnel.

Wie bekommt man denn das SSH Protokoll (was ja eigentlich TCP (Schicht 4) in das IP Paket untergebracht?

Gruß

Eleu 

Bearbeitet 21. März 2017 von Eleu

[etreu]

Der Tunnel wird via ICMP realisiert. Das liegt daran, dass es dort auch einen relativ freien Datenbereich gibt. Bei IP wird angegeben, wie die Daten zu interpretieren (welches Protokoll zum Dekodieren zu verwenden ist).

Bearbeitet 21. März 2017 von etreu

[Gast halcyon]

Du hast recht, Ping benutzt ICMP. Wusste ich gerade auch nicht ! Das ändert aber natürlich nichts daran, dass alle Komponenten - wie auch bei TCP - das Protokoll kennen müssen, um es zu verarbeiten. Auch wenn ICMP wie ein eigenes Protokoll gelesen/behandelt wird, ist es ein Teil des IP Protokolls, was eben bestimtme Eigenschaften aufweist, wodurch die Gegenstelle weiß, dass dieses Paket z. B. nur zu Diagnose Zwecken verschickt wurde. Deshalb ist es auch möglich, Ping abfragen allgemein durch eine FW zu verwerfen.

Das SSH Protokoll ist ein Anwendungsbasiertes Protokoll, deshalb kannst du dich  nur zu einer Gegenstelle per SSH verbinden, wenn eine entsprechende SSH-Software (Dienst) auf der Gegenseite läuft. Und zwar am Endknoten, wo das Paket ankommt. Hier ist es nicht nötig, dass jede Komponente im Netzwerk weiß, dass es sich um ein SSH verschlüsseltes Paket handelt, da dass ja an den Zwischenstellen nicht gelesen, sondern nur weiter verschickt werden muss. Das wird einfach per TCP/IP an die vorgesehene Adresse und Port geschickt und der SSH-Dienst, der auf dem entsprechenden Port lauscht, weiß dann schon wie es zu lesen ist unter Hinzunahme vorher ausgetauschter Schlüssel/Zertifikate. Landet das Paket bei einem anderen Port als derjenige, wo SSH lauscht, ist es lediglich ein TCP/IP Paket, dass im Datenbereich eine Menge Bitmüll enthält. Das wird dann von der Applikation verworfen, wo es am Ende ankommt.

Ich kann dir allerdings nicht im Detail erklären, wie die Pakete bei unterschiedlichen Protokollen genau gestackt sind, da ich hier technisch nicht so tief drin stecke.

Aber ansonsten klar, du kannst natürlich Protokolle wie ICMP nutzen, da diese Pakete heute gewöhnlich eben von jeder Komponente gelesen werden können. Das ist natürlich eine andere Sachlage als deine Ursprungsfrage, in der es dir um nicht standardisierte byte-basierte Verbindungen ging.

Bearbeitet 21. März 2017 von halcyon

[Eleu]

Hallo,

also ein Frame kapselt ein IP- Paket, um es auf Layer 2 weiter zu transportieren.

Die Daten des IP – Paketes, als solches, liegt dann im Nutzdatenbereich des Ethernet Frames.

 

Ich beziehe mich bei meinen Überlegungen auf das Bild im wiki - Link

https://de.wikipedia.org/wiki/Datenframe

 

Soweit so gut.

Auf layer 3 kapselt ein IP Paket nun das ICMP Protokoll.

Ich denke, dass dann die Daten des ICMP Protokolls, im Nutzdatenbereich des IP Paketes liegen.

Wie ja auch im Bild dargestellt.

 

Was ich noch nicht begriffen habe ist, wie denn nun auf Anwenderebene das IP Paket überredet werden kann,

in seinen Nutzdatenbereich das SSH Protokoll aufzunehmen?

Ich meine, diese Daten müssen ja irgendwie in diesen Nutzlastbereich hineinkommen?

Es gibt dann ja keinen Socket, sondern alles läuft dann nur auf Schicht 3 ab.

 

Nehme ich in VB6 ein Winsock Steuerelement für die TCP/IP Kommunikation, passiert das irgendwie

über das Betriebssystem, dass das TCP Protokoll in den Nutzdatenbereich des IP Paketes integriert wird.

Das ist für mich dann nicht transparent?

 

Wie kann man denn den Nutzdatenbereich des IP Paketes auf Schicht 3, über die Anwenderebene,

mit eigenen Nutzdaten füttern?

 

Dem Router ist es doch Wurscht, was für Daten im Nutzdatenbereich des IP – Paketes liegen?

Er leitet das Paket auf Layer 3 weiter, insofern es die übrigen Kriterien erfüllt  

 

Gruß

Eleu

 

PS: Oder vielmehr, wie kann ich den Nutzdatenbereich des ICMP Protokolls auf Anwenderebene ansprechen.

Bearbeitet 21. März 2017 von Eleu

[Gast halcyon]

1 hour ago, Eleu said:

Was ich noch nicht begriffen habe ist, wie denn nun auf Anwenderebene das IP Paket überredet werden kann, in seinen Nutzdatenbereich das SSH Protokoll aufzunehmen?

 

Ich meine, diese Daten müssen ja irgendwie in diesen Nutzlastbereich hineinkommen?

Ich glaube du musst das anders sehen. Als Sender existiert das IP Paket auf Anwendungsebene noch nicht bzw. muss erstellt werden, auf der Empfängerseite ist es auf der Anwendungsebene schon "aufgebrochen" und kann gelesen werden. Angenommen du willst als Programmierer eine SSH Verbindung initiieren, dann gibt es dafür Libarys, welche dir die Technik unten drunter wegkapseln. Das heißt die SSH-Daten kommen durch die Anwendungsebene und werden dann nach "unten" gereicht und dort ins Paket gebaut. Auf der anderen Seite wird das Paket gelesen, "aufgebrochen" und die SSH Software kann die Daten lesen. Letztendlich ist ein IP Paket ein durch das Protokoll standardisierter Bytestrom. Der kann alles beinhalten, was der "Ersteller" darein schreibt.

Ich bin da leider technisch auch nicht drin, wie man zweifelsfrei merkt. Das einzige was ich dazu noch beitragen kann ist noch mal zu unterstreichen, dass "IP Pakete" oder was auch immer über die Leitung gejagt wird, keine "Objekte" in dem Sinne sind, in man wörtlich etwas reinpackt oder herausnimmt. Es werden immer nur Byte-Ströme verschickt, die dann auf der Gegenseite interpretiert werden. Wie das interpretiert wird, bestimmt das Protokoll. Die Empfängerseite liest die Bytes ein und sieht "ahh okey 1010010 bla..., dass muss ein gültiges TCP/IP Paket sein, ich guck weiter rein ... 00101101 ... ah okey hier fangen die Daten ...  1000011 ahh okey das ist wohl SSH ... 1010100110 das sind die verschlüsselten Daten, ich entschlüssel die mal 1100000 ... ". Man könnte auch einfach sagen, dass bestimmte Muster in den Bytestrom gesucht wird, und je nach dem welches Muster das ist, werden die Daten Anhand eines anderen Protokolls "verstanden" und anschließend verarbeitet. Das geht natürlich nur, wenn man sich auf eine Reihenfolge festgelegt hat. Und genau das sind sollen die Protokolle gewährleisten. Nur wer sich ans Protokoll hält, kann erfolgreich kommunizieren. Wer nicht standardisierten Byte-Müll sendet, kriegt auch nichts zurück.

Das OSI Modell ist keine exakte Architektur Implementierung, sondern nur ein theorethisches Modell dass klar machen soll, in welcher Reihenfolge diese Byteströme interpretiert werden. Das hilft zum einen der Kommunikation unter IT'lern, zum anderen hilft es eben wenn man Fehler sucht. Wie das exakt implementiert ist, hängt von den Implementierungen der Technik und Software jedes einzelnen Systems ab, wo das Paket gebaut oder gelesen oder weiter verschickt wird. Wie ein SSH Paket gebaut wird, weißt du nur, wenn du dir eine SSH Libary anschaust und dort schaust, welche Methoden dort genutzt werden und welche Technik im  Computer widerum diese Methoden bereitstellt. Du landest dann irgendwo bei den Sockets und dann musst dir angucken wie die Sockets im jeweiligen Betriebssystem implementiert sind usw... So kann man ja den "Bau" eines Paketes bis auf Kernel Ebene aufdröseln. Im nächsten System kann es schon wieder anders sein. Hauptsache, die Bytes werden in der richtigen Reihenfolge verschickt, so dass andere Systeme, die sich ebenfalls an den Standard (die Protokolle) und nach den "Mustern" "Ausschau halten" die dann lesen und verarbeiten können.

1 hour ago, Eleu said:

Nehme ich in VB6 ein Winsock Steuerelement für die TCP/IP Kommunikation, passiert das irgendwie

über das Betriebssystem, dass das TCP Protokoll in den Nutzdatenbereich des IP Paketes integriert wird.

Das ist für mich dann nicht transparent?

 

Ja genau, es ist nicht Transparent. Das soll es auch nicht sein, damit du es als Programmierer einfacher hast. Wenn du wissen willst was in den Sockets passiert (denn die VB Socket Elemente machen nichts anderes, als die Sockets des Betriebssystem zu kapseln und dir als sinnvolle Methoden bereitzustellen), musst du dir die Socket Implementierung des Betriebssystems anschauen. Zumindest auf Unix und Linux Systemen ist der Quellcode ja offen.

Hier findest du alle Kernel Implementierungen für die Sockets und Protokolle wie IPv4, IPv6, TCP, UDP etc. und alle sonsten Netzwerkbasierten Dinge:

http://lxr.free-electrons.com/source/net/

Wenn du dir da anschaust, wie beispielweise ipv4 implementiert wurde, wird dir schwindelig. Dann weißt du auch, warum du davon am besten als Programmierer nichts wissen sollst. Es reicht, dass du weißt, was es ist, und deine Programmiersprache bietet die Methoden an, welche diesen technischen "Overhead" für dich wegkapseln. Du sagst dann nur noch "baue Verbindung zu IP x.x.x.x" auf, der Rest passiert irgendwo auf einer anderen Ebene. Das ist auch ganz allgemein der Sinn hinter Schnittstellen - nicht nur (aber vor allem) in der Informatik.

Und wie gesagt, willst du es wirklich im technischen Detail wissen, kommst du nicht herum zum einen die entsprechende RFC, also die Spezifikation zu lesen (siehe: z. B. für IPv4 https://tools.ietf.org/html/rfc791) lesen. Zum anderen dann zu schauen, wie das Betriebssystem das Protokoll gemäß der Spezifikation implementiert hat. Dazu siehe link oben zum Kernel Quellcode (z. B. ipv4 http://lxr.free-electrons.com/source/net/ipv4/)

Bearbeitet 21. März 2017 von halcyon

[Gast halcyon]

- doppelpost -

Bearbeitet 21. März 2017 von halcyon

[Gast halcyon]

1 hour ago, Eleu said:

PS: Oder vielmehr, wie kann ich den Nutzdatenbereich des ICMP Protokolls auf Anwenderebene ansprechen.

In dem du eine Sprache wie C nimmst, und dann direkt mit der API des Betriebssystem sprichst, welche in irgendeiner Form das Kernel Modul für ICMP kapselt. Du kannst du dir das mal in dem Klassiker "The Linux Programming Interface: A Linux and UNIX System Programming Handbook" anschauen. So eine API gibt es bestimmt auch für Windows (? WIN32 ->http://www.sockets.com/ms_icmp.htm. ICMP Implementierung auf WIndows: http://www.sockets.com/ms_icmp.c) Vielleicht kannst du das sogar in in WB die WIN32 API ansprechen, das weiß ich nicht.

 

Bearbeitet 21. März 2017 von halcyon

[Eleu]

Hallo halcyon,

ist ja doch etwas mehr Stoff

Werde mir das noch mal in Ruhe ansehen. Zumindest haben mich deine Ausführungen wieder etwas näher an die Praxis herangeführt.

Wenn man sich gedanklich von dem OSI - Modell löst und sich das ganze Frame als Byte  - Strom vorstellt, (Vermutlich beginnend von links nach recht im Bild) dann wird einem die ganze Komplexität der Technologie, die dahintersteckt, diese Informationen hintereinander in zeitlicher Folge zu entschlüsseln, etwas bewusster.

Vielen Dank.

Gruß

Eleu 

 

 

[Gast halcyon]

Danke !

Ja ich hoffe es hilft ein wenig. Ich bin bei dem Thema Netzwerktechnik auch recht am Anfang. In der Berufsschule hab ich da leider gar nichts zu gelernt (nicht mal Subnetting) und in den Vorlesungen im Studium hab ich nur Bahnhof verstanden, weil der Professor mit Protokollen, Paketen jeglicher Art und OSI Layern um sich geworfen hat, als wäre das alles selbstverständlich ohne jemals zu definieren, was eigentlich ein Protokoll ist. Es wird ja immer nur gesagt, man könne sich das Protokoll in der RFC anschauen - aha. Das dass aber nur eine theorethische Spezifikation ist, war mir nicht klar. Also blieben Protokolle und allerlei Dinge für mich "Hexerei" die einfach "da sind", aber keiner weiß eigentlich, wie genau . Das habe ich erst verstanden, als ich im Rahmen einer Betriebssystem-Vorlesung mich mit dem Buch "Moderne Betriebssysteme" von Tanebaum und dem Buch "The Design and Implementation of the FreeBSD Operating System" beschäftigt hatte. Gerade letzteres hat mir richtig die Augen geöffnet weil extrem praktisch und den Source Code von BSD, ist eben wie von Linux, verfügbar. Im Gegensatz zu Linux allerdings nicht versplittert auf Kernel und alles was sonst ein Linux definiert sondern eben zusammen. Wenn man sich BSD installiert, kann man sich den vollständigem Quellcode direkt mit herunterladen und der ist sogar sofort kompilierfähig. Und erst da habe ich gesehen, dass die Protokolle eigentlich nur in C geschriebene Implementierungen sind, die das Betriebssystem mitliefert und die versuchen die RFC umzusetzen. Wie sie das tun, kann bei jedem Betriebssystem völlig anders sein. Wenn man Langeweile hat, könne man sogar sein eigenes Protokoll nachimplementieren und gegen das vorhandene austauschen. Naja ...

Aber wie gesagt, ich habe davon selbst nicht sehr viel Ahnung. Sobald meine Ausbildung und Studium diesem Sommer rum ist, möchte ich mich auch gerne mehr mit dem Thema Netzwerkanalyse & co. beschäftigen, wo ich dem ganzen dann auch wieder begegnen werde. Vor allem wollte ich mir dann mal die ganzen RFC's durchlesen, um zumindest theorethisch zu verstehen, was die ganzen Protokolle eigentlich im Detail tun und wie die zusammen hängen. Ich glaube nämlich, dass das viele Lehrer und Professoren selbst überhaupt nicht richtig verstanden haben. Ich denke die haben das so verstanden, wie sie es erklären: Es gibt das OSI Modell und irgendwelche Pakete, die durch Algorithmen ihren Weg zum Ziel finden. Wo die Pakete her kommen und wie die entstehen -> Alles schwarze Magie ...

Bearbeitet 21. März 2017 von halcyon

[Eleu]

 

Moin halcyon,

also ich habe im Rahmen meiner Ausbildung schon recht hardwarenah mit Assembler am Intel 8086 programmiert (Bin alt…)

und auch jetzt noch, habe ich direkt im Bereich der Automatisierungstechnik mit Bits und Bytes zu tun.

Vllt. kommt auch daher mein Bedürfnis, es immer bis auf die unterste Ebene runter zu brechen, damit ich es verstehe.

Geht mir also ähnlich wie dir..

Das große Ganze zu begreifen, ist einfach nicht mehr möglich und damit man einigermaßen klar kommt, muss man eben einige Dinge wohl als gegeben hinnehmen. Das müssen die Prof. wohl auch, denn sie sind ja auch nur Menschen. Das OSI Modell ist wohl eine ganz gute Sache, die Vorgänge verständlich darzustellen. Wireshark setzt genau darauf auf und es hat mir auch schon ein ums andere Mal geholfen Fehler zu finden. Zum Beispiel hatte ich mal den Fehler, dass ein Socket nach gewisser Zeit immer wieder dicht gemacht wurde und wie sich herausstellte, lag es dann daran, dass eine Komponente im Netz kein keep alive sendete.

Hab dafür ne ganze Weile gebraucht, aber ohne wireshark…no chance..

Naja …nur mal so…

Ich wünsch dir noch viel Erfolg bei deinem Studium und was du sonst noch so vor hast..

Gruß

Eleu