Diskussion:Tunnel (Rechnernetz)
Überarbeiten: Sicherheitsprobleme von Tunneln
Der Abschnitt ist murks. Natürlich kann man "von außen" die Pakete eines Tunnels nicht inspizieren - das ist ja auch grade der gewünschte Effekt (jedenfalls bei verschlüsselten Tunneln). Aber natürlich stellt man vor bzw. hinter das Tunnel-Ende eine weitere Firewall, in der die Pakete, die aus dem Tunnel kommen, kritisch begutachtet werden und ggf. verworfen werden können. ..siehe übrigens auch hier in der Diskussion im Abschnitt Sicherheitsprobleme.(Der vorstehende, nicht signierte Beitrag stammt von Togs (Diskussion • Beiträge) 0:11, 9. Nov. 2006 (CET))
- murks entsorgt Lehmi 02:00, 25. Jan. 2007 (CET)
Tunneln falsch verstanden
Ich glaube hier wurde Tunneln falsch verstanden, auch wenn es bei Tecchannel so beschrieben wird, hat tunneln IMHO erstmal nix mit Security oder PPP zu tun, sondern einfach Protokolle in anderen Protokollen einzubetten. Natürlich kann man so auch Security einbinden (z.B. VPN). Kommentare? Blubbalutsch 01:49, 8. Mär 2004 (CET)
Habe "keine Chance" in "kaum eine Chance" geändert. Es gibt grundsätzlich schon Möglichkeiten für den Admin, Tunnel zu erkennen. Wenn Datagramme ungewöhnlich groß werden, kann das zum Beispiel Verdacht erregen. --Moldy
STIMMT !
Im Zusammenhang mit Tunnel und VPN sollte m.E. unbedingt deutlich erklaert werden, dass es zwei voellig unabhaengige Themen betrifft. In Gesprächen mit Kunden etc. geht das regelmäßig durcheinander:
Ein Tunnel an sich hat lediglich die Aufgabe, die Datenpakete des einen Netztes in das andere (Ziel-) Netz zu transportieren. Erforderlioch ist das zB (insbesondere?) dann, wenn die beiden Partner private IP Adressen (z.B. 10.x.y.z, 192.168.x.y) nutzen, die im öffentlichen Netz nicht verwendet werden können. Weiterer Sinn ist, Datenpakete eines anderes Protokolls zu übermitteln. Ein Beispiel ist die in Ende der 80er / Anfang der 90er Jahre von Novell implementierte Lösung, IPX/SPX Datenpakete via IP zu übertragen. Prinzip: die Datenpakte werden komplett in eine weiteres Datenpaket eingepackt, welches dann über das transportierende Netz (heutzutage i.d.R. öffentliches Internet) gesendet werden.
Das zweite Thema ist die Verschlüsselung, um den Datenverkehr abzusichern. Dazu gibt es mehrere Protokolle Verfahren, sowohl was die Übertragung angeht (SSH, SSL,...) als auch die Art der Verschlüsselung. (Symetrisch, wer hält die Zertifikate etc.) Dieses hat aber zunächst einmal nichts mit dem übertragen von Datenpaketen zu tun, die über dan Transportweg sonst nicht übertragbar wären.
Heutige VPNs verwenden eine Kombination. Erst durch den Einsatz der Verschlüsselung werden die Daten unkontrollierbar. Die Kontrolle der Daten in einem verschlüsselten Tunnel ist folglich erst hinter dem Rechner / Knoten möglich, an dem die Daten wieder ausgepackt / entschlüsselt werden.
Der Artikel an sich ist eine sinnvolle Angelegenheit. Allerdings sei erwähnt, dass kaum ein Administrator ernsthaft eine "offene" VPN Strecke einrichten wird. Sinnvoller Weise wird man eine (weitere) Firewall einrichten, die den (ausgepackten) Datenverkehr in das eigene/interne Netz kontrolliert.
Nicht zu vergessen: würde man dieses nicht tun, wuerden alle Broadcasts etc auch in die VPN Strecke geschickt. Da diese häufig schmalbandig sind (Mobilfunk, analoge Modems etc), will man das unterbinden.
Letzter Hinweis, in diesem Kontext freilich nur indirekt relevant: Werden derartige Pakete (broadcasts) aber benoetigt, reduziert man das mittels Spoofing. Ich weiss garnicht, ob es dazu einen Artikel gibt.
Genug geschrieben, zum erstem Mal ueberhaupt in einem Wiki... vielleicht nutzt es Euch
NSp (Der vorstehende, nicht signierte Beitrag stammt von 80.143.74.50 (Diskussion • Beiträge) 21:56, 23. Nov. 2006 (CET))
Sicherheitsprobleme
Ich finde das mit dem Wohnungsschlüssel etwas übertrieben!
Es gibt schon administrative Mittel, mit denen man Tunnel-Benutzer einschränken kann. Je nach dem wie man den Tunnel benutzt.
Wenn z.B. ein MS-RAS-Server benutzt wird meldet sich der Tunnel-Benutzer ja auch an dem entsprechendem Computer an und kann von dort aus mit den geltenden Rechten von Windows eingeschränkt werden.
Mit Linux hab ich leider nicht ganz so viel zu tun, aber sicher gibt es auch dort ähnliche Mittel.
Außerdem soll ja auch nicht jeder das Recht bekommen sich per Tunnel einzuwählen. Jeder Mitarbeiter der dieses Recht hat, sollte darauf hingewiesen werden, dass Protokolldaten erfasst werden und nachvolziehbar ist, wann er sich in das System eingewählt hat. Somit wird es sicher keinem Mitarbeiter einfallen während der Verbindung irgendwas dummes zu tun.
Der Artikel ist mir etwas zu pauschal, indem er Tunnel einzig und allein als Sicherheitsrisiko darstellt, wobei natürlich gesund ist, dass darauf hingewiesen wird. (Der vorstehende, nicht signierte Beitrag stammt von 83.169.142.241 (Diskussion • Beiträge) 4:01, 16. Mai. 2005 (CEST))
Feste IP tunneln
Im Artikel T-DSL wird mit dem Satz "Eine weitere Möglichkeit besteht darin, eine feste IP-Adresse zu tunneln." auf diesen Artikel gelinkt. In diesem Artikel steht allerdings nichts darüber, wie man sich nun eine feste IP tunnelt. --Philip Seeger 09:21, 9. Sep 2005 (CEST)
Verschieben
Wäre dafür, den Artikel nach Tunnel (Netzwerktechnik) zu verschieben, spricht was dagegen? -- KL47 (Diskussion) 16:15, 19. Jul 2006 (CEST)
Erledigt. Lehmi 01:54, 25. Jan. 2007 (CET)
Fax / Aukkustikkoppler als Beispiel eines Tunnels???
Die Faxübertragung per Telefonnetz, oder die Übertragung von Daten per Akkustikkoppler, würde ich nicht als Beispiel eines Tunnels annehmen. Das ist doch genauso falsch, wie wenn man sagt, die Datenübertragung per DSL über "Telefondrähte" ist eine Anwendung eines Tunnels. Die "Telefondrähte" sind vielmehr teil der physikalen Schicht, über welche die Übertragung von Daten anstelle von Sprache erfolgt. Die englische Version des Artikels ist viel klarer und besser und beinhaltet vor allem diese Beispiele nicht.