VPN Hard-& Softwarevoraussetzungen |
||
---|---|---|
#0
| ||
11.09.2003, 14:36
Member
Beiträge: 124 |
||
|
||
11.09.2003, 16:41
...neu hier
Themenstarter Beiträge: 10 |
#17
Dein letzter Gedanke kam mir heute auch: Anwendungen vom Client aus auf dem Server.... Hm....
Im Hinblick auf so 'ne Möglichkeit wäre ja zB ein Citrix MetaFrame 'ne Lösung. Der hätte ja auch einen Secure Gateway und könnte an einen DB-/Fileserver angeschlossen sein (Dateneinsicht/ -bearbeitung). Und für den direkten Datenaustausch hätten wir dann ja immernoch VPN. ...*weiter nachdenk*... Aber ich danke dir, daß du mich in meiner Feststellung bestätigst |
|
|
||
12.09.2003, 14:14
...neu hier
Themenstarter Beiträge: 10 |
#18
...bzw. wie wäre es mit einem VPN-Tunnel vom ISP in Verbindung mit einer MetaFrame-Lösung im Unternehmen??
Der ISP bietet zwar keine herausragende Sicherheit, aber via den Tunnel könnte man sich die teure Direktverbindung zum MetaFrame sparen - also das ganze kostengünstiger gestalten. Die Clients würden sich über den ISP einwählen, getunnelt und könnten auf den Citrix zugreifen, um dort eine Session zu eröffnen. Oder hab ich da irgendwo 'nen Denkfehler und da läuft mir irgendwas quer?? |
|
|
||
15.09.2003, 20:18
Member
Beiträge: 124 |
#19
MetaFrame und "einfaches" VPN... da stecken zwei völlig verschiedene Konzepte
dahinter. Insofern würd ich tatsächlich erstmal ein wenig Ordnung in meine/ deine Gedanken bringen wollen... VPN... am besten geeignet für den Datenaustausch. Um Anwendungen auf einem entfernten Server auszuführen eher nicht - viel zu langsam. MetaFrame... eignet sich hervorragend um serverbasierte Anwendungen einem Client-/ Servernetz zur Verfügung zu stelllen. ABER Die Einrichtung des MetaFrames ist eine sehr komplexe und kostspielige Sache. Das beginnt damit, dass das MetaFrame auf WIN Terminalserver aufsetzt - Kostenpunkt Lizensen. Citrix selbst ist auf Grund der Lizenspolitik auch nicht ganz billig: es gibt verschiedenen "Ausbaustufen" die pro Stufe und Clientanzahl zu buche Schlagen. Mal von den Kosten für Anwendungen ganz abgesehen (Serverlizensen). Weiter: Um Anwendungen über das MetaFrame sinnvol ausführen zu können, bedarf es sehr, sehr guter Hardware in Bezug auf Arbeitsspeicher und Prozessor- leistung. Jede Clientsitzung wird komplett als eigene Session auf dem Server ausgeführt. Stichwort Bandbreite: denk garnicht erst über DSL nach. Citrix- Sitzung laufen zwar sehr stark komprimiert, aber bei entsprechender Anzahl Clients geht's dann doch irgendwann auf die Bandbreite... Einen Vorteil haben Citrix-Sitzungen allerdings: sie können mit bis zu 128 Bit (RC5) verschlüsselt werden, d.h. VPN entfällt. Die Benutzer-/ und Anwendungsverwaltung des MetaFrame an sich ist relativ unspektakulär und setzt auf WIN auf - diese allerdings sollte man perfekt beherschen. Sehr viel komplexer ist die Resourcenadministration, da es praktisch möglich ist, jedes Gerät, dass an einen Client angeschlossen ist (Drucker, Brenner, HDD, Scanner, Audio/Video...) jedem anderen Client innerhalb des Netzwerkes zur Verfügung zu stellen. Wie gesagt: Ihr solltet euch sehr gut im klaren darüber sein, welchen Zweck ihr mit dem Netzwerk verfolgt... Grüße, dicon __________ Knie nieder NICHTS und danke der Welt, dass sie dir ein Zuhause gibt und dich am Leben hält. |
|
|
||
sorry, dass ich mich in euer "Vieraugengespräch" einklinke, aber ich hätte da noch
ein paar Anmerkungen über die zumindest nachgedacht werden sollte:
snoop242: Im Moment ist auf LAN-Seite schon ein Router installiert, hinter dem 3 Server stehen
Auf Basis dieser Konfiguration macht es meiner Meinung nach keinen Sinn, hinter
den Router einen VPN-Server (egal, ob Hard- od. Software) zu stellen. Ich geh
mal davon aus, dass das LAN u.a. via NAT durch den Router nach außen
abgeschirmt wird. Wenn der Router nicht VPN- bzw. IPsec-fähig ist, ist es
fast unmöglich einen VPN-Tunnel aufzubauen, wenn der Endpunkt sich
hinter NAT versteckt. Das betrifft btw alle VPN-Protokolle (IPsec, L2TP, PPTP...).
Die Integrität des IP-Headers eines "VPN-Paketes" wird laufend geprüft. Wird
z.b. der Header verändert nachdem er durch IPsec gekappselt wurde,
und das tut NAT, wenn der VPN-Server hinter dem Router steht, stimmt die
Integrität des Paketes nicht mehr und es wird verworfen - auf deutsch: keine
Integrität, kein Tunnel. Das mal nur als ganz, ganz einfache Erklärung für das
Problem.
Ein Lösungsvorschlag wäre, Router und VPN-Gateway zu kombinieren - bei der
beschriebenen Netzwerkform idealer Weis als Hardwarelösung. Auf jeden Fall
sollte NAT abgeschlossen sein, bevor die Pakete im VPN-Tunnel verschwinden.
Ähnliche Gedanken sollten sich auch die geplanten Fremd-LANs machen, die
ihr an euer LAN anbinden wollt. Auch diese werden hinter einem Router stehen
und benötigen die gleichen Voraussetzungen wie ihr: NAT vor IPsec.
Möglicherweise hab ich's überlesen oder falsch verstanden: Die Lizenzfrage für
Clientsoftware bzw. Userlizensen auf Serverseite stellt sich in der Regel nur bei
Hardwarelösungen. Nehmen wir zum Beispiel einen win2003a-server: die
Userlizensen kauft ihr mit der Serversoftware, d.h. die Anzahl möglicher,
gleichzeitiger Verbindungen auf den Server. Der Server läßt sich von Hause aus
als VPN-Server einrichten. Auf Clientseite gibt's dann auch keine Probleme,
solange diese über OS win2000 oder neuer verfügen, da hier VPN via IPsec
serienmäßg möglich ist.
Abschließend vielleicht noch ein Gedanke: Solange der Zugriff von außen nur auf
Daten erfolgt, ist VPN sicher 'n guter Gedanken... sollen aber Anwendungen via
Terminalsitzungen realisiert werden, möglicherweise über einen
Application-Server, halte ich die Idee für nicht mehr so praktikabel...
Wollt's nur angemerkt haben...
Grüße, dicon
__________
Knie nieder NICHTS und danke der Welt, dass sie dir ein Zuhause gibt und dich am Leben hält.