VPN-Server, VPN-Client und dann?

Hi,

vielleicht wirds jetzt verständlicher:

1. Client (z.B. bei dir zu Hause mit internet zugang, firewall, virenscanner) baut einen vpn-tunnel auf. Danach erfolgt die RDP-Anmeldung (durch den vpn-tunnel) am Server.
2. Auf dem entfernten Server ist VNC-Viewer installiert. Auf den entfernten Clients ist VNC-"Server" installiert und im Hintergrund aktiv.
3. In der RDP-Session den VNC Viewer vom Server starten und mit der entsprechenden Adresse verbinden. Dann kannst Du den "VNC-PC" (entfernter Client) komplett fernsteuern. Der User sieht allerdings alles, was Du tust.

Gruß

Trapper Tom

Hallo zusammen,


Was genau heißt das? Netz zu Netz oder Client zu Netz? Oder beides? Haben wir auf einer Seite eine feste IP, auf beiden oder auf keiner?

Prinzipiell empfehle ich meinen Kunden immer, das Problem mit wirklich VPN-fähigen Routern zu erschlagen. Wenn Du mich fragst, dann nimm Lancom. Ansonsten gibt es solche Router auch von Bintec, Zyxel und sicher auch noch von anderen Herstellern.

Der Preis liegt zwar bei ungefähr dem zehnfachen, was Du für die Billig-DSL-Router zahlst. Aber das lohnt sich. Letztlich ist die Einrichtung viel einfacher. Trotzdem kannst Du Dir dabei noch richtig die Karten legen. ;) Wenn man aber die Arbeitszeit gegen den höheren Preis des Routers rechnet, dann kommt man insgesamt mit neuem Router preiswerter weg. Außerdem ist die Grundinstallation dann mit Sicherheit besser als ein selbst aufgesetzter VPN-Router.


Beides. Erst authentifiziert sich das andere Netz oder der andere Rechner gegenüber dem VPN-Server. Der Tunnel wird aufgebaut und dann kommt das Userlogin in der Domäne.


Das ist vom Prinzip her möglich. Die Frage ist, ob es bei Fernverkehrsleitungen Spaß macht. ;) Über welche Leitungen willst Du fernwarten?


Ein weiterer Grund, warum ich das immer mit Routern aufbaue, ist die höhere Sicherheit. Ich gehe mal von IPsec aus. Hier gibt es zwei Sicherheitsmechanismen. Der eine ist das Encapsulated Security Payload (ESP). Damit bezeichnet man die verschlüsselten Daten.

Der andere Mechanismus ist der Authentication Header (AH). Und der ist inkompatibel zum NAT/PAT-Routing. Das Problem ist folgendes:

Dein Server hat eine lokale IP (z. B. 192.168.0.2). Nach außen hat das Netz aber eine öffentliche IP (z. B.: 123.123.123.123). Nun muss dein NAT-Router beim Übergang vom lokalen ins Weiteverkehrsnetz diese IP ändern. Und noch viel schlimmer, er ändert auch den TCP-Port. Dieses Verhalten sorgt aber dafür, dass die Checksummen in AH nicht mehr stimmen. Somit wird das Paket von der Gegenseite abgelehnt und der Tunnel kann nicht aufgebaut werden.

Nun gibt es zwar Router mit sogenanntem VPN-pass-through. Die lassen solche Pakete möglichst unverändert passieren. Davon halte ich aber nicht so viel, da hier ein potentielles Sicherheitsloch in die Firewall gebohrt wird. Oder ich verzichte auf den AH. Dann wird das ganze IPsec unsicherer.

Geschickter ist es also, den Tunnel vor der Firewall aufzubauen. Hier kann ich alle Funktionen von IPsec benutzen. Ich erhalte also den sichersten Tunnel, der zur Zeit möglich ist. Aber ich habe dann das Problem, dass der Server nackt im Netz steht.

Die geschickteste Lösung ist, den Tunnel quasi in der Firewall oder in Zusammenarbeit mit der Firewall aufzubauen. Und genau das tun diese speziellen Router. Hier arbeiten Firewall und VPN-Server zusammen.

hth

Liebe Grüße

Erik

Hast Du richtig verstanden! So meinte ich es

Trapper Tom

Edit:

Den vpn-tunnel musst Du natürlich mittes dyndns aufbauen, wenn Du jedesmal eine neue IP-Adr. bekommst. Dyndns musst Du dann am Router entsprechend konfigurieren.

Gruß Tom

Kann es sein, dass Dein Server außer Fileserver, RAS u. VPN-Server auch noch als Internet-router fungiert?
Wenn ja, dann ist es warscheinlich ein DNS-Problem. Da muss ich hallerdings passen, da ich die Konfiguration Server als Internet-Router schon aus Prinzip noch nicht eingesetzt habe.

Gruß Tom