Einfache VPN Verbindung

[Assarbad]

Zitat von sx2008:

Wenn es einfach werden soll bräuchte man eine völlig neue Architektur von Betriebssystem.

Bitte?

Zitat von sx2008:

Ein Betriebssystem in dem die Anwendungen nicht einfach so auf die Windows API zugreifen,
sondern beim Start der Anwendung eine ganze Liste von Schnittstellen mitbekommt.
Eine Anwendung braucht z.B. Schnittstellen zur Tastatur, Maus, Grafikkarte, Netzwerk, Audio, Filesystem und Registry.

Dann ist es ja gut, daß es das alles schon gibt. Oder muß sich dein Programm darum kümmern ob es eine Laptoptastatur oder eine "normale" ist? Von Firma A, B, C oder alle drei gleichzeitig eingesteckt sind? Ob PS/2 oder USB? Nein. Die Abstraktion von der du redest, existiert längst und zwar für "Tastatur, Maus, Grafikkarte, Netzwerk, Audio" und mehr.

Wovon du redest ist (u.a.) exakt der Sprung von den alten DOS-Spielen in denen man Soundblaster mit Port und IRQ einstellen muß (oder ein Dutzend anderer Soundkarten) zu den strukturierten Schnittstellen die bspw. DirectX bot als es eingeführt wurde.

Wozu du nun das Dateisystem und die Registry mit Hardware in einen Topf wirfst ist mir ohnehin ein Rätsel, aber selbst da hast du auf vielen Systemen eine Lösung bereits eingebaut. Die Lektüre von Andrew S. Tanenbaum's "Moderne Betriebssysteme" kann ich dir da nur ans Herz legen. Als erster Schritt sozusagen.

Zitat von sx2008:

So könnte z.B. eine Anwendung "A" eine Anwendung "B" starten und ihr ein Filesystem vorgaukeln,
dass es physikalisch gar nicht gibt.

Auf Windows Vista und 7 hast du FS Virtualization und Registry Virtualization. Auf unixoiden gibt es Jails und allgemein chroot() - kombiniere das mit AUFS oder UnionFS sowie anderen Puzzlesteinen und du hast sehr flexible Wege einem Prozeß etwas vorzugaukeln. Du kannst sogar ne MySQL-Datenbank als Backend benutzen und ein Dateisystem vorgaukeln. Wo muß die Architektur denn da komplett geändert werden?

Und selbst wenn es das auf OS-Ebene nicht gibt, kann man noch immer den Kindprozeß so kontrollieren daß man dessen Funktionen und ihre Verwendung hookt (auch auf den meisten unixoiden hat der Elternprozeß komplette Kontrolle über Kindprozesse).

Zitat von sx2008:

Da Gleiche wäre auch für den Netzwerkzugriff möglich.

Ist es. Phoenix hatte schon einen Weg grob umrissen. LSPs könnten eventuell auch eine Methode sein. Aber ich würde Treiber auch vorziehen, selbst wenn LSPs ultimativ funktionieren könnten.

Zitat von sx2008:

Anwendung "B" denkt es gäbe eine Netzwerkkarte, aber in Wirklichkeit wird diese nur von Anwendung "A" vorgespiegelt.

Und was hat das mit VPN zu tun? Erstmal garnix. Ein Gateway auf beiden Seiten reicht im einfachsten Fall. Dann noch Verschlüsselung in den Topf und schon haste ein lecker VPN.

Es wäre schlimm, wenn Anwendung B sich auf die Ebene begeben müßte, wo sie auch noch die Netzwerkkarte kennen muß welche von Anwendung A bereitgestellt wird - wenn wir mal für einen Moment diese Idee mitdenken. Der Sinn eines VPN ist ja gerade, daß alle Anwendungen transparent Zugriff darauf haben ohne sich um die Details zu kümmern.

Selbst wenn du eine beliebige netzwerkfähige Anwendung schreibst, mußt du dich in den seltensten Fällen mit den Details der Hardware auseinandersetzen ...

Zitat von sx2008:

Das wäre ähnlich wie bei einer virtuellen Maschine, nur dass hier feingranular geregelt wird,
was virtuell ist und was nicht.

Hmm, gehört nur irgendwie nicht in die Diskussion, weil VPNs wie wir sie heute verstehen etwas komplett anderes sind und auch nicht immer auf eine vorgekaukelte Netzwerkkarte angewiesen sind.

[sx2008]

Also irgendwie hast du mich missverstanden oder ich habe es nicht genau genug erklärt was ich meine.
Ich nehme als Beispiel WinSock mit den handlebasierten Funktionen (connect, listen, bind, socket, usw.).
Eine Anwendung, die diese Funktionen aufruft landet in den DLLs des Betriebssystem.
Ja klar es gibt Möglichkeiten um Hooks oder LSPs in WinSock einzuschieben, aber das ist recht aufwendig.
Jetzt stelle man sich vor, WinSock würde durch ein Interface ersetzt werden:

Delphi-Quellcode:

IWinSock2=Interface(IUnknown)
['xxxx-....xxxx']
  function connect(...);
  function listen(...);
  ....
end;

Die Anwendung bekommt schon beim Start einen Interfacezeiger übergeben.
Anstatt die WinSock-DLL zuladen, wird einfach nur dieses Interface benützt (vereinfacht, wir brauchen mehrere Interfaces).
Die Anwendung funktioniert genau gleich wie vorher, nur mit dem Unterschied, dass das Betriebssystem seine
API-Dienste anbietet anstatt dass die Anwendung festgelegte APIs aufruft.
siehe: Inversion of Control.
Jetzt kommt eine weitere Host-Anwendung, die genau das Interface implementiert und alle Aufrufe zunächst einmal 1:1 an das Interface, das sie seinerseits bekommen hat weiterreicht.
Würde nun diese Host-Anwendung eine andere Anwendung starten, dann würde sie sämtliche WinSock-Aufrufe mitbekommen.
Jetzt wäre es ein Leichtes, wenn die Host-Anwendung alle Netzwerkaufrufe tunneln würde.
Somit wurde die WinSock-API virtualisiert, weil die ursprüngliche Anwendung gar nicht merkt, dass seine Aufrufe abgefangen und verändert werden.

Dieses Prinzip könnte man auch auf viele andere APIs anwenden und so viele APIs des Betriebssystem virtualisieren.
So könnte man z.B. die API für die serielle Schnittstelle über ein Netzwerk umleiten.
Dinge, die bisher nur über Systemtreiber möglich sind, könnten so dem Anwendungsprogrammierer zugänglich werden.
Oder man denke nur an Softwaretests und die Möglichkeiten einfach so Mock-Objekte für Windows-API-Aufrufe zu erstellen.

Würde es dieses utopische Betriebssystem geben, dann wäre es einfach, alles mögliche umzuleiten und zu verändern.
Der Trend geht ganz klar in Richtung Virtualisierung und so darf ruhig ein bisschen darüber nachdenken was denn wäre, wenn alle APIs virtuell wären.
(und ohne virtuelle Pflänzchen gleich argumentativ niederzuknüppeln)

[alfold]

@RedShakal

Vielleicht bringt es Dir was?
http://www.administrator.de/index.php?content=17986

was hälts Du hier von http://www.tucows.com/preview/39056ist ein Linux vpn und für windows gibt es den clienten dazu!

Ach so, den wolltest du ja selberschreiben.
Ob das dann allerdings so funktioniert, Spiel ist bei dir auf deinem Rechner und nun müssen sich alle irgendwie auf den entferten vpnserver einklinken mh...
Bin ich echt überfragt!

alfold

[Sir Rufo]

Das Ziel ist es doch eigentlich auf "Knopfdruck" einen VPN-Tunnel herzustellen, ohne das der User - da meist sehr unbedarft - irgendwelche Konfigurationen vornehmen muss.

Somit benötigt er wohl ein Progrämmle, dass auf einem Windows-Rechner eine VPN-Verbindung bei Bedarf erzeugt und dann auch noch startet.
(So etwas hat auch die Firma LANCOM mit ihrem VPN-Client gebaut. Das ist lediglich ein Wrapper um die Einrichtung der VPN-Verbindung auf ein Minimum an Benutzer-Eingaben zu reduzieren)

Ich vermute mal nicht, dass es hier um die Entwicklung eines Treibers oder Protokolls geht sondern eher darum was Assarbad hier schon aufgezeigt hat:

Zitat von Assarbad:

Zitat von RedShakal:

Einen PPTP Server kann ich schnell aufsetzen, jedoch sind die meisten Nutzer überfordert beim einrichten (trotz Video anleitung Step by Step), daher will ich ein Programm basteln das diesen Vorgang automatisiert.

RasDial dürfte sein was du suchst. Hatte da mal vor zehn Jahren oder so einen Dialer geschrieben wo ich unter anderem diese APIs benutzt habe. Kann mal gucken ob ich da noch etwas habe.

Siehe auch http://msdn.microsoft.com/en-us/libr...(v=VS.85).aspx

Ob das mit PPTP funzt, hängt allerdings davon ab was das Spiel genau benutzt. Bei TCP-Verbindungen sollte es aber bei den meisten VPN-Lösungen kein Problem gehen. Benutzt du UDP oder so, wird's u.U. schon schwieriger.

[Assarbad]

Zitat von sx2008:

Ja klar es gibt Möglichkeiten um Hooks oder LSPs in WinSock einzuschieben, aber das ist recht aufwendig.
[...]
Die Anwendung bekommt schon beim Start einen Interfacezeiger übergeben.

... auch wenn sie nie vorhat die Funktionen zu verwenden, nehme ich mal an? Klingt wie eine von diesen Funktionen mit 33 Parametern - nur daß es hier noch mehr werden würden.

Zitat von sx2008:

Die Anwendung funktioniert genau gleich wie vorher, nur mit dem Unterschied, dass das Betriebssystem seine
API-Dienste anbietet anstatt dass die Anwendung festgelegte APIs aufruft.

Das tut das OS bereits und die API-Funktionen sind einfach nur das Format in welchem die Dienste angeboten werden.

Zitat von sx2008:

siehe: Inversion of Control.

Man nehme die guten alten Callbacks, verpacke sie in OOP und nenne das "Inversion of Control"

Hab ich es richtig verstanden?

Zitat von sx2008:

Würde nun diese Host-Anwendung eine andere Anwendung starten, dann würde sie sämtliche WinSock-Aufrufe mitbekommen.

Jupp. Könnte sie. Wäre nicht mal so doof, wenn man das bei Diensten benutzen könnte. Nur leider habe ich keine Kontrolle über die Hostanwendung von Diensten.

Zitat von sx2008:

Jetzt wäre es ein Leichtes, wenn die Host-Anwendung alle Netzwerkaufrufe tunneln würde.

Stimmt. Dumm nur, daß auf der anderen Seite des Tunnels das gleiche Prinzip herrschen müßte. Da sind mir die transparenten VPNs, wie es sie bereits gibt, schon lieber.

Zitat von sx2008:

Somit wurde die WinSock-API virtualisiert, weil die ursprüngliche Anwendung gar nicht merkt, dass seine Aufrufe abgefangen und verändert werden.

Stimmt. Und es klingt danach, daß sich die Supportabteilungen aller Softwarefirmen darauf einstellen müssen in Zukunft auch Probleme zu bearbeiten, die von amateurhaft geschriebenen "Hostanwendungen" erzeugt werden.

Zitat von sx2008:

Oder man denke nur an Softwaretests und die Möglichkeiten einfach so Mock-Objekte für Windows-API-Aufrufe zu erstellen.

... du schreibst deinen Code also vermutlich so, daß du direkt die API-Funktionen aufrufst und, sagen wir mal bei Registryfunktionen, das Ganze nicht zuvor in eine Klasse kapselst deren Schnittstellen man auch ohne Unterstützung des Betriebssystems "mocken" kann? Hab das etwas anders gelernt.

Zitat von sx2008:

Würde es dieses utopische Betriebssystem geben, dann wäre es einfach, alles mögliche umzuleiten und zu verändern.

Schonmal versucht einen Dateisystemfiltertreiber zu debuggen? Was du hier vorschlägst ist die Ausdehnung des Prinzips auf alles. Chaos pur. Bei Treibern ist man nämlich auch auf die Kooperation anderer Treiber angewiesen. Und selbst wenn ein Fehler in einem anderen Treiber im Filterstack hervorgerufen wird, kann es sein, daß dein eigener Treiber beim BSOD als Verursacher dargestellt wird (siehe "Supportabteilung" weiter oben).

Zitat von sx2008:

Der Trend geht ganz klar in Richtung Virtualisierung und so darf ruhig ein bisschen darüber nachdenken was denn wäre, wenn alle APIs virtuell wären.

Der kleine aber feine Unterschied ist, daß alle anderen Virtualisierungsansätze heutzutage darauf ausgelegt sind, daß die Anwendungen transparent die virtuelle Hardware usw. nutzen können. Bei dir klingt es nach dem genauen Gegenteil. Transparenz ist dann passé.

Zitat von sx2008:

(und ohne virtuelle Pflänzchen gleich argumentativ niederzuknüppeln)

Gern geschehen. Unsere Diskussion hat mit den VPN-Thema des Fragestellers aber noch immer nicht viel zu tun ...

Ich werf ja auch nicht überall ein: "Ach ja, Okapis sehen süß aus", nur weil jemand "API" verwendet und diese Buchstabenkombination im "Okapi" vorkommt. Ähnlich beliebig kommt mir deine Vorstellung von von Virtualisierung bei Erwähnung von "Virtual Private Network" vor.

[RedShakal]

Ich möchte mich erstmal für die ganzen Antworten bedanken. Zugegeben war ich beim lesen doch etwas überfordert

Den oben gezeigten PopTop Server habe ich schon eingerichtet das ist kein Problem. Der VPN selber funktioniert auch Problemlos. Ebenso das Spiel wenn ich über die VPN spiele. Das einzige Problem das sich auftut ist einfach nur, das die meisten Nutzer einfach überfordert sind die Verbindung einzurichten. Und die, die es hinbekommen, meckern dann das sie kein Internet mehr haben weil sie vergessen haben den haken beim default Gateway rauszunehmen.

Die Verschlüsselung muss ja auch nicht vorhanden sein - warum auch, es wird lediglich der Traffic von dem Spiel übertagen, keine sensiblen Daten oder ähnliches.

Wie ich mir das vorgestellt hatte war einfach ein kleines Programm, das geöffnet wird, sich mit den VPN nach eingabe der Logindaten verbindet, und im Programm selbst den aktuellen Status anzeigt.

Ich habe mir jetzt mal die RasDial Funktion näher angeschaut. Am Wochenende werde ich mich nochmals Intensiv damit befassen. Allerdings habe ich die befürchtung das auf Vista / 7 das ganze nicht klappen wird, wegen den Admin rechten. (Oder was mir auch oft passiert, das der Virenscanner anschlägt).

[Assarbad]

Zitat von RedShakal:

Und die, die es hinbekommen, meckern dann das sie kein Internet mehr haben weil sie vergessen haben den haken beim default Gateway rauszunehmen.

*g*

Zitat von RedShakal:

Die Verschlüsselung muss ja auch nicht vorhanden sein - warum auch, es wird lediglich der Traffic von dem Spiel übertagen, keine sensiblen Daten oder ähnliches.

Zugangsdaten für Spiele werden auch gehandelt. Aber kommt natürlich auf's Spiel an

Zitat von RedShakal:

Wie ich mir das vorgestellt hatte war einfach ein kleines Programm, das geöffnet wird, sich mit den VPN nach eingabe der Logindaten verbindet, und im Programm selbst den aktuellen Status anzeigt.

Ich habe mir jetzt mal die RasDial Funktion näher angeschaut. Am Wochenende werde ich mich nochmals Intensiv damit befassen. Allerdings habe ich die befürchtung das auf Vista / 7 das ganze nicht klappen wird, wegen den Admin rechten. (Oder was mir auch oft passiert, das der Virenscanner anschlägt).

Einfach ein Manifest rein, so daß die Anwendung den UAC-Prompt anzeigt. Wir können dir sicher helfen ... frag einfach, wenn du an einer Stelle nicht weiter weißt.