Einfache VPN Verbindung

[RedShakal]

Hallo, ich benutze Delphi XE Starter. Ich bin auf der suche nach einer möglichkeit, einen simplen Client VPN zu schreiben ohne dabei auf Windows oder OpenVPN zurückgreifen zu müssen. Die Server-Software spielt eigentlich keine Rolle. Ich besitze einen Linux Root Server. Sie sollte nur kostenfrei sein.

Ich möchte jetzt aus meinen Programm heraus eine Verbindung zu diesem VPN Server herstellen, ohne dabei auf externe Programme zurückgreifen zu müssen. Eine Verschlüsselung spielt hierbei keine Rolle. Die VPN Verbindung dient nur dazu, ein bestimmtes Spiel Netzwerkfähig zu machen. (Ich weiß das es genug alternativen gibt, aber mit Hamachi haben wir des öfteren Probleme und Tunngle finden die Spieler nicht so toll.

Gibt es da eine möglichkeit? Freigaben und Internet Traffic sollen dabei nicht übertragen werden, lediglich der Traffic für Netzwerk Spiele.

[mkinzler]

Warum nicht nur ein Rad sondern ein ganzes Auto neu erfinden?
VPN ohne Verschlüsselung?

[Phoenix]

Möglichkeiten gibt es da schon. Aber nicht mit Delphi. Du musst dafür letztlich ein virtuelles Netzwerk-Gerät erstellen, und das geht nur mit einem Treiber. Und Treiber kann man in Delphi nicht wirklich sinnvoll schreiben (erst recht keine für 64bit Systeme). Und dann kommt da noch der ganze Quark von Netzwerk-Know-How an sich dazu, weil Du ja den Traffic dynamisch woanders hin routen musst. Das ist ein Projekt das Jahre an Zeit verschlingen wird.

[RedShakal]

Gibt es da nicht irgentwie eine möglichkeit das über PPTP zu machen, aber eben ohne das eine Verbindung vom Benutzer erstellt werden muss?

[rollstuhlfahrer]

Dann noch ein Hinweis von meiner Seite: Du spielst da dann an der Kernel-Routing-Tabelle rum, sodass der komplette Traffic, der sonst über eth0/wlan0 (die Netzwerkkarte eben) Richtung Router und dann ab ins Internet geht, über dein Programm laufen muss. Gleichzeitig darf sich dein Programm aber nicht an eben diese Tabelle halten, denn sonst käme nirgendwo was an. (Für den erstgenannten Vorgang brauchst du Admin-Rechte).

Was du jetzt machen kannst (das sollte relativ einfach sein) ist: Du kannst eine Windows-VPN-Verbindung von deinem Programm automatisch anlegen lassen und dann diese zur Verbindung bringen (k.A. welche Schwierigkeiten dir MS da auf den Weg legen wird). So musst du nicht an deiner virtuellen Netzwerkkarte tüfteln und hättest trotzdem das Ziel erfüllt.

Bernhard

PS: Für die API müsstest du dann jetzt die Suche verwenden.

[alfold]

Zitat:

Zitat von RedShakal (Beitrag 1092802)

...Die VPN Verbindung dient nur dazu, ein bestimmtes Spiel Netzwerkfähig zu machen. .....

Setzt vorraus das das spiel Netzwerkfähig ist!
Wenn ja und es gibt die Files auch für Linux dann knall das Spiel da drauf! Wenn nicht hat sich dies ja meistens schon erledigt!

Warum, wenn das Spiel nur läuft, wenn es ein user startet(selber spieler ist) und dann jemanden einladen muss, kannst du nichts machen! Dann ist es also nicht selbst lauffähig, wo man sich mal schnell einklingt um zu Spielen! Ala COD4 ET WOW usw.
Alles andere währe viel zu aufwendig! finde ich.

alfold

[RedShakal]

Das Spiel ist Netzwerklauffähig, hat aber eben keinen Stand Alone Server. Wir haben das bisher immer über Hamachi gemacht. Leider gab es vermehrt Probleme.

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.

[Assarbad]

Zitat:

Zitat von RedShakal (Beitrag 1093005)

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.

[alfold]

Zitat:

Zitat von RedShakal (Beitrag 1093005)

Das Spiel ist Netzwerklauffähig, hat aber eben keinen Stand Alone Server....

Netzwerkfähig schon, aber ebend nicht als Server.
Und da das Spiel dummerweise ein Windowspiel ist gehts auch damit nicht

Zitat:

Zitat von RedShakal (Beitrag 1092802)

...Ich besitze einen Linux Root Server....

wenn ich es richtig verstanden habe!

mh... ob Du da nun was aufwendiges selber schreibst, damit es deine Feunde autmomatisch einrichten/einloggen können. Wird nicht einfach!:gruebel: um HAMACHI nachzubauen.

alfold

[sx2008]

"Einfach" und "VPN Verbindung" ist ein Widerspruch in sich.
Ein VPN ist sehr schwierig zu implementieren.
Wenn es einfach werden soll bräuchte man eine völlig neue Architektur von Betriebssystem.
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.
So könnte z.B. eine Anwendung "A" eine Anwendung "B" starten und ihr ein Filesystem vorgaukeln,
dass es physikalisch gar nicht gibt.
Da Gleiche wäre auch für den Netzwerkzugriff möglich.
Anwendung "B" denkt es gäbe eine Netzwerkkarte, aber in Wirklichkeit wird diese nur von Anwendung "A" vorgespiegelt.
Das wäre ähnlich wie bei einer virtuellen Maschine, nur dass hier feingranular geregelt wird,
was virtuell ist und was nicht.

[Assarbad]

Zitat:

Zitat von sx2008 (Beitrag 1093042)

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

:shock: Bitte?

Zitat:

Zitat von sx2008 (Beitrag 1093042)

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:

Zitat von sx2008 (Beitrag 1093042)

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:

Zitat von sx2008 (Beitrag 1093042)

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:

Zitat von sx2008 (Beitrag 1093042)

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:

Zitat von sx2008 (Beitrag 1093042)

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. :roll:

[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:

Zitat von Assarbad (Beitrag 1093009)

Zitat:

Zitat von RedShakal (Beitrag 1093005)

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:

Zitat von sx2008 (Beitrag 1093051)

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:

Zitat von sx2008 (Beitrag 1093051)

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:

Zitat von sx2008 (Beitrag 1093051)

siehe: Inversion of Control.

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

Hab ich es richtig verstanden?

Zitat:

Zitat von sx2008 (Beitrag 1093051)

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:

Zitat von sx2008 (Beitrag 1093051)

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:

Zitat von sx2008 (Beitrag 1093051)

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:

Zitat von sx2008 (Beitrag 1093051)

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:

Zitat von sx2008 (Beitrag 1093051)

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:

Zitat von sx2008 (Beitrag 1093051)

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:

Zitat von sx2008 (Beitrag 1093051)

(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 :zwinker: ...

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:-D

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:

Zitat von RedShakal (Beitrag 1093494)

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:

Zitat von RedShakal (Beitrag 1093494)

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:

Zitat von RedShakal (Beitrag 1093494)

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.