[lug-ld] S) Statt beim nächsten Treffen Kopie an Interessierte...
Pahle Heinz
heinz.pahle at gmx.de
Do Jan 30 23:57:11 CET 2020
Wen folgende Fachbegriffe und prinzipielle Vorgehen interessieren, möge
weiterlesen, andernfalls Ablage senkrecht.
Liebe LUGer,
es geht um gemeinsame Sprachregelung, die aber technisch korrekt sein
soll, damit nicht aneinander vorbeigeredet wird. Aktuell ist VPN und
drumherum (z.B. Tunnel) gefragt.
Dazu im einzelnen:
Wie funktioniert ein Tunnel, welche Dienste erbringt er?
Was ist also ein Tunnel in ganz wenigen Worten? [Definition]
Wie kommt man von einem Tunnel zu VPN? bzw.
Welche Dienste erbringt VPN? [Hier ein grober Überblick, nicht die
Realisation]
Nachdem ein Funktionsnachweis von JJ erbracht wurde, wobei alles
anscheinend keine Hexerei sei, ist der eine oder anders nun motiviert
tiefer zu blicken. Es wäre jetzt an der Zeit, das Ganze nicht nur als
black box zu sehen. Vielleicht muss man ja noch außen herum einiges
bearbeiten, um Profi-Hacker komplett auszuschließen.
Dann mal los
*Tunnel, tunneln* (braucht noch Frame, Protokoll)
Zuerst, weil es gebraucht wird, eine Klärung, was Frames (Rahmen) sind,
die im IT-Bereich über Netzwerke „laufen“. So ein Frame (Bytestrom
bestimmter Länge) kann in Abschnitte unterteilt werden, die jeweils eine
Bedeutungen haben.
Die Abschnitte eines Frames, ganz grob:
Ein Frame hat einen Header-Bereich (darin Ziel-/Quell-Adresse, wichtige
Kennungen, etc.), unmittelbar darauf folgend einen Payload-Bereich
(darin Nutzdaten) und anhängend einen Trailer-Bereich (darin
Fehlererkennung, etc.).
Wenn man von einem IT-Protokoll, z.B. IP, spricht, dann meint man a) den
genauen Aufbau eines Frames (oder einem Satz von Frames) und b) wie
beide Kommunikationsseiten miteinander interagieren (via
festgeschrie-bener Regeln).
Im Nutzdatenbereich kann wieder ein Frame liegen (so wird es auch
gemacht), diesmal zu einem anderen Protokoll gehörend, z.B. TCP.
Dieser Aufbau ist somit bei TCP/IP der Fall: ein TCP-Frame ist quasi im
IP-Frame (dort in Payload) komplett „eingelagert“. Das im
Nutzdaten-Bereich von IP transportierte Protokoll (Protokoll braucht
einen Frame), könnte auch etwas ganz anderes sein – ein Frame, der im
Nutzdatenbereich, die Daten für Sprachübertragung (Voice over IP) enthält.
Nehmen wir VoIP her, dann werden Sprachnachrichten quasi getunnelt; sie
„verschwinden“ im IP-Kanal, werden diesem somit übergeben (und weg
transportiert). Statt einer Punkt-zu-Punkt-Kupferleitung (frühes
Analogtelefon) wird ein sogenannter virtueller (hier IP-)Kanal
„geschaltet“, und das ist dann ein Tunnel.
Aber...
Der Begriff Tunnel ist jedoch nicht an Verschlüsselung der übergebenen
Daten gebunden und ein assoziieren damit ist ein verbreiteter Irrtum.
Das kommt vielleicht daher, weil es im realen Tunnel dunkel ist und man
von außen nicht hineingucken kann und das würde ja so schön passen.
Pustekuchen.
Zum Merken:
*Ein Tunnel ist ein virtueller Kanal.*
*Über einen / in einem Tunnel kann man beliebige Protokolle transportieren.*
Dieser Vorgang rechtfertigt am besten den Begriff Tunnelung (so gefühlt,
geht was ab), obwohl für einen solchen Vorgang an anderer Stelle auch
Kapselung (so gefühlt, einpacken ist nicht versenden) gesagt wird.
Das Gegenbeispiel, bei dem man nicht von Tunnelung spricht, obwohl das
Verfahren gleich ist: Beim ISO-7-Schichtenmodell kann man die oberen 6
Schichten, jeweils gleiche Ebene, als virtuelle (Software-)Verbindung
der beiden Kommunikationsseiten sehen. Und da spricht niemand von
Tunnelung, obwohl die Payload-Bereiche „volle Kanne“ mit Protokollen
gefüllt sind, Prinzip Matroschka Puppe. In diesem Fall gehören
Applikationschicht (oberste, #7) und die nach unten folgenden logisch
zusammen, es ist nichts Wesen fremdes dabei (wie z.B. bei VoIP). Somit
wird hier nicht getunnelt.
Steigerung...
*VPrivateN* (zu virtuell, siehe vorher; es folgt „privat“)
Um einen Payload „privat“ zu machen, ist verschlüsseln angesagt. Um noch
„privater“ zu sein, wird man die Herkunftsadresse (nicht die
Zieladresse) nach außen hin per Verschlüsselung verbergen (sie fällt
damit nicht unter den Tisch!). Und wenn es noch sicher in puncto
Echtheit sein soll, dann wird diese bezüglich Absender auch geprüft.
Daten-Unverfälschtheit in einem Payload-Bereich zu checken (CRC), das
ist eh ein Standard, der bei allen Frames gemacht wird, oft sogar in
Headerbereichen.
Die diversen Frames bezüglich VPN samt Protokoll-Beschreibung dazu, um
alle vorher beschriebene „Schmankerl“ zu erhalten, es gibt zudem 2
Varianten, die sind schon eine kleine Verständnis-Herausforderung, wenn
man das wissen will. Tipp: nach Vorlesungsskripten suchen, oder besser
Kurs besuchen, da Bücher selten Fragen auf Antworten geben.
So weit zur Sprachregelung und Prinzipiellem
Gruß
Heinz
PS:
Zur Vorgänger-Mail und meinem SHA1 abgesicherten Satz (hashen zwischen
Anführungszeichen):
„Es gibt eine IP-Ziel- und eine IP-Quell-Adresse, wobei man NUR ALLEINE
die Quelle verheimlichen darf.“
F6_31_E8_B2_9F_24_BC_62_DC_98_A3_E7_3C_2C_7C_EA_9F_57_D7_44
Geärgert hat mich die Schlampigkeit einfach „die Adressen“ (im Plural)
zu schreiben, was ja nicht hinhauen kann. Wahrscheinlich wurde das so
noch plump abgeschrieben.