Split Tunneling

[JackCarver]

Du willst Erklärungen warum etwas unsauber funktioniert, kannst aber selbst nicht erklären, dass es definitiv sauber funktioniert. Das ist etwas einseitig und unsauberes diskutieren. Sie's drum, ich versuch dir nochmal das Problem anhand von Linux zu erklären, denn dort kommt man deinem Wunsch mit Bordmitteln sehr nahe. Es wird unter Windows nicht anders sein, ich vermute eher sogar schwerer als unter Linux.

Zur Technik des Routings am VPN vorbei:
Es gibt hier die Möglichkeit zb spezifischere Routen zu definieren, genau das macht übrigens OpenVPN, dass der Traffic komplett über VPN geht. Wenn ich also ein Teilnetz im Internet kenne, das an VPN vorbei soll, dann kann ich eine spezifischere Route in dieses Netz über den Standardadapter definieren, die die Route durch das VPN überstimmt. Der Traffic geht also am VPN vorbei.

Jetzt kommen die ersten Hürden an deinem Wunsch:
Man hat jetzt eine App, zb den Webbrowser A. Dessen Traffic soll komplett am VPN vorbei. Obige Lösung kann hier nicht mehr funktionieren, weil ich kein spezielles Netz kenne, das ich als spezifischere Route definieren könnte. Was ich jetzt brauche sind mehrere Routing Tabellen, die nebenher existieren. Ob das unter Win überhaupt geht, zumindest unter einer nicht Server-Version ist bereits äusserst fraglich...
Hab ich diese zweite Routing Tabelle, so muss ich dort wiederum Routen anlegen, für unseren Fall einfach ne default Route ins Internet über den Standard Adapter, also am VPN vorbei.
Das allein langt aber nicht, ich brauch auch ne Regel, welche Pakete genau diese Routing Tabelle verwenden sollen, nämlich ausschließlich die Pakete, die von Webbrowser A kommen.
Das nennt man unter Linux policy based Routing, auch hier ist zweifelhaft ob es das unter ner Zocker-Win Version überhaupt gibt, oder erst ab ner Serverversion, die wiederum nicht zum Zocken taugt...

Zuletzt brauch ich noch etwas, das diese Pakete auch entsprechend markieren kann, unter Linux machen das die iptables.

Nun ne weitere Hürde:
Wie markiere ich nun Pakete, die von Webbrowser A kommen? Programmnamen oder Pfade dazu verwenden ist viel zu unsicher, da sich das mal schnell ändern kann. Also brauch ich was anderes. Linux geht den Weg der Prozess-ID, da alle Prozesse auf einem System eindeutige IDs haben. Aber auch das ist aus folgendem Grund umstritten:

Ein Prozess kann Kindprozesse erzeugen, wiederum mit anderer PID, die aber im weiteren Sinne zu diesem Prozess gehören. Pakete davon würden bereits wieder nicht markiert und gingen durch VPN hindurch, also auch sehr schwammig das ganze. Es funktioniert im weiteren Sinne aber es ist nicht gesagt, dass es zu 100% funktioniert und das ist unsauber!
Ebenso halte ich nicht viel von Application Firewalls. Ne saubere Firewall blockt portbasiert oder IP basiert, aber nicht applicationbasiert.

Wenn du nun noch etwas zu deinem NDIS Treiber lesen möchtest, dann guck einfach mal hier nach:

https://de.wikipedia.org/wiki/Network_Driver_Interface_Specification

Dort siehst du für was dieser eigentlich verwendet wird unter Win und das ist meilenweit von dem entfernt, was du eigentlich möchtest.

Sorry aber du diskutierst hier was alles machbar ist und umgesetzt werden muss, hast aber m.E, nicht allzuviel Hintergrundwissen dazu um das überhaupt einschätzen zu können.

 

[theoth]

Nachtrag - die elegantere Methode dürften Network-namespaces sein. Damit kann man jedem Prozess seinen eigenen Namespace verpassen und ihn isolieren.
http://unix.stackexchange.com/questions/68956/block-network-access-of-a-process/69017#
Also noch weniger Virtualisierung als z.B. Docker.
Vielleicht kommt das ja auch mal bei Windows. sshd und docker haben sie ja auch schnell nachgezogen, weil alle Welt danach gerufen hat.

Windows hat momentan was viel komplexeres (bei MS ist merkwürdigerweise alles immer viel komplexer, als woanders...) nämlich die WFP https://msdn.microsoft.com/en-us/library/windows/desktop/aa366510(v=vs.85).aspx
Ich denke daran kann man sich zu Tode programmieren, denn dort klinken sich alle möglichen tools ein und behelligen sich gegenseitig. Dort gibt es allerdings auch eine Filterung auf höherer Ebene (also über layer 3/4).
Vielleicht gibt es ja käufliche Software für diesen Zweck.

 

[Headcool]

Bitte nicht immer alles tot diskutieren. Du hast eine Antwort bekommen, auch wenn die dir nicht unbedingt gefällt und dann sollte doch gut sein: Sorry, das wir nicht jeden Wunsch erfüllen können oder auch wollen.

Ich bin völlig einverstanden mit der Entscheidung. Wie gesagt, es ist eine wirtschaftliche Frage, es wäre euer Risiko sowas zu implementieren entsprechend ist es auch euer Bier da eine Entscheidung zu treffen.
Was mir nicht passt sind die völlig anhaltslosen Behauptung "nicht sauber implementierbar" und wenn man nachfragt kommen keine Argumente sondern nur herumgedruckse. Wenn du Argumente hast, wieso meine vorgeschlagene Lösung nicht sauber wäre, dann poste sie. Wenn nicht, dann verstehe ich nicht wieso du so eine Behauptung überhaupt aufstellst.

Du willst Erklärungen warum etwas unsauber funktioniert, kannst aber selbst nicht erklären, dass es definitiv sauber funktioniert. Das ist etwas einseitig und unsauberes diskutieren. Sie's drum, ich versuch dir nochmal das Problem anhand von Linux zu erklären, denn dort kommt man deinem Wunsch mit Bordmitteln sehr nahe. Es wird unter Windows nicht anders sein, ich vermute eher sogar schwerer als unter Linux.

Ich behaupte man könne es sauber implementieren da ich nichts sehe, was dem widerspricht. Du scheinst Probleme zu sehen, dann bringe sie vor. Vielleicht hast du ja Recht und kannst mich überzeugen. Aber bitte stelle keine Behauptung auf ohne Argumente die diese stützen.

Zur Technik des Routings am VPN vorbei:
Es gibt hier die Möglichkeit zb spezifischere Routen zu definieren, genau das macht übrigens OpenVPN, dass der Traffic komplett über VPN geht. Wenn ich also ein Teilnetz im Internet kenne, das an VPN vorbei soll, dann kann ich eine spezifischere Route in dieses Netz über den Standardadapter definieren, die die Route durch das VPN überstimmt. Der Traffic geht also am VPN vorbei.

Jop, das ist normales Split Tunneling. Gibt aber auch andere Möglichkeiten in dem man bspw. direkt auf den Netzwerkadapter zugreift. Oder man weist einem Paket einen anderen Adapter zu.

Jetzt kommen die ersten Hürden an deinem Wunsch:
Man hat jetzt eine App, zb den Webbrowser A. Dessen Traffic soll komplett am VPN vorbei. Obige Lösung kann hier nicht mehr funktionieren, weil ich kein spezielles Netz kenne, das ich als spezifischere Route definieren könnte.

Man kann per-App-Split-Tunneling nicht über normales Split Tunneling implementieren. War mir immer schon klar.

Was ich jetzt brauche sind mehrere Routing Tabellen, die nebenher existieren. Ob das unter Win überhaupt geht, zumindest unter einer nicht Server-Version ist bereits äusserst fraglich...
Hab ich diese zweite Routing Tabelle, so muss ich dort wiederum Routen anlegen, für unseren Fall einfach ne default Route ins Internet über den Standard Adapter, also am VPN vorbei.
Das allein langt aber nicht, ich brauch auch ne Regel, welche Pakete genau diese Routing Tabelle verwenden sollen, nämlich ausschließlich die Pakete, die von Webbrowser A kommen.
Das nennt man unter Linux policy based Routing, auch hier ist zweifelhaft ob es das unter ner Zocker-Win Version überhaupt gibt, oder erst ab ner Serverversion, die wiederum nicht zum Zocken taugt...

Zuletzt brauch ich noch etwas, das diese Pakete auch entsprechend markieren kann, unter Linux machen das die iptables.

Mag alles schön und gut sein, aber ich würde das komplett anderst machen. Man muss ja nicht alles anhand von statischen Adressen routen. Man muss das Paket auf einer Ebene im Netzwerk-Stack abfangen auf der man die Prozessinformationen noch hat und dann an den entsprechenden Adapter senden.

Nun ne weitere Hürde:
Wie markiere ich nun Pakete, die von Webbrowser A kommen? Programmnamen oder Pfade dazu verwenden ist viel zu unsicher, da sich das mal schnell ändern kann. Also brauch ich was anderes. Linux geht den Weg der Prozess-ID, da alle Prozesse auf einem System eindeutige IDs haben. Aber auch das ist aus folgendem Grund umstritten:

Ein Prozess kann Kindprozesse erzeugen, wiederum mit anderer PID, die aber im weiteren Sinne zu diesem Prozess gehören. Pakete davon würden bereits wieder nicht markiert und gingen durch VPN hindurch, also auch sehr schwammig das ganze. Es funktioniert im weiteren Sinne aber es ist nicht gesagt, dass es zu 100% funktioniert und das ist unsauber!

Naja da kenne ich prinzipiell unter Linux 3 unter Windows 2 Möglichkeiten - zwei einfache und eine schwierige. Die einfache die nur unter Linux funktioniert beruht auf der Tatsache, dass unter Linux die Prozessstruktur auch nach beenden eines Threads intakt bleibt. D.h. wenn wir einen Prozess mit der PID 1234 haben der einen Kindprozess mit der PID 5679 erzeugt und dann ausläuft oder sonst irgendwie beendet wird, bleibt er in der Prozessstruktur bestehen. D.h. ich kann in jedem Fall nachprüfen ob ein Prozess mit der PID x ein Kindprozess von PID y ist, auch wenn PID y nicht mehr läuft. Unter Windows geht das nicht so einfach, da beendete Prozess entfernt werden und die Kindprozesse in der Prozessstruktur nach oben rücken.
Die andere einfache Möglichkeit ist nicht auf die Instanz des Programmes zu gehen, sondern auf den Pfad. Wenn ein Prozess forkt ist der neue Prozess automatisch auch vom VPN exkludiert da er den gleichen Pfad besitzt. Wird dagegen ein anderes Programm mittels exec aufgerufen, wird dieses nur exkludiert, wenn es auch so konfiguriert wurde. Für Fälle in denen ein Programm eine eigene executable erzeugt kann man Wildcards in Pfaden benützen.
Die schwierige, aber sicherlich perfekteste Möglichkeit wäre eine Sandbox wie bspw. Sandboxie mittels der man alle Vorgänge bezüglich erstellen von Kindprozessen komplett monitoren könnte.

Ebenso halte ich nicht viel von Application Firewalls. Ne saubere Firewall blockt portbasiert oder IP basiert, aber nicht applicationbasiert.

Wenn man sich von außen schützen will sicher. Wenn du willst, dass Program xy nicht nach Hause telefoniert wird dir das nicht viel nützen. Du kannst nämlich nicht zwangsläufig herausfinden zu welch allen IPs sich das Programm verbinden will und als Ursprungsport kann es einen zufälligen auswählen. Wenn der Server an vielen hunderten Ports Verbindungen aufnimmt, kannst das Programm auch den Zielport aus vielen Möglichkeiten wählen.
Und wenn es sich bei diesem Programm um eine Art Keylogger handelt, dann darf da nicht ein Paket durchkommen.

 

[Headcool]

Wenn du nun noch etwas zu deinem NDIS Treiber lesen möchtest, dann guck einfach mal hier nach:

https://de.wikipedia.org/wiki/Network_Driver_Interface_Specification

Dort siehst du für was dieser eigentlich verwendet wird unter Win und das ist meilenweit von dem entfernt, was du eigentlich möchtest.

Der NDIS Treiber macht genau das, was jeder andere Treiber auch macht. Er standartisiert ein Interface, im Falle von NDIS ein Interface um mit vielen verschiedenen Netzwerkkarten zu kommunizieren. Mit anderen Worten der NDIS-Treiber spricht Englisch. Netzwerkkarte A spricht Chinesisch, Netzwerkkarte B spricht Japanisch, Netzwerkkarte C spricht koreanisch. Programm A,B und C sprechen Deutsch, Französisch und Italienisch. Ohne NDIS Treiber müsste jedes Programm mit jeder Netzwerkkarte klarkommen, das wären in diesem Fall 9 Mögliche Kombinationen. Aufgrund der standartisierten Interfaces des NDIS Treibers müssen aber nur 6 Kombinationen abgedeckt werden. Also n+m statt n*m. Bei den Millionen Programmen und den tausenden Netzwerkkarten die es gibt, ist das eine ganz schöne Erleichterung.

NDIS Treiber werden für ziemlich viele Netzwerkgeschichten verwendet. Dazu gehören Firewalls, Paket-Monitore, Load Balancer, VPN-Adapter und alle anderen möglich Arten von virtuellen Adapter wie sie zb. bei Virtualisierungslösungen eingesetzt werden.

Beim durchstöbern der NDIS Dokumentation ist mir die NdisSend Funktion aufgefallen. Interessant ist das zweite Argument. Hierbei handelt es sich um die Netzwerkkarte oder den virtuellen Adapter des nächsten Treibers. Bei Paketen die um das VPN herum geschleust werden müsste man hier die Netzwerkkarte direkt auswählen. Bei allen anderen Paketen müsste man den OpenVPN Adapter auswählen.

Sorry aber du diskutierst hier was alles machbar ist und umgesetzt werden muss, hast aber m.E, nicht allzuviel Hintergrundwissen dazu um das überhaupt einschätzen zu können.

Meines Erfassens nach kennst du dich zwar gut mit IT und Netzwerkadministration aus, aber von Programmieren scheinst du nur oberflächliche Kenntnisse zu haben.


Abgesehen davon ist mir selbst ein Workaround eingefallen. Der ist zwar nicht perfekt und auch nicht ganz einfach, aber ich denke er lässt sich durchführen.
Ich habe ja die Idee mit SOCKS abgelehnt, da ich dafür ja hunderte Programme konfigurieren müsste und es bei einigen auch nicht möglich wäre. Der umgekehrte Ansatz könnte allerdings funktionieren. Prinzipiell müsste ich einen SOCKS Proxy im LAN aufstellen (am besten in einer VM). Dessen IP konfiguriere ich in den Programmen die ich am VPN vorbeitunneln will. Dazu exkludiere ich diese Route vom VPN mittels normalen Split Tunneling. Entsprechend werden diese Programme ihren Traffic an den lokalen Proxy senden und dieser wird diesen an den Zielort schicken.
Aus den Zeiten als ich noch DNS Tunneling verwenden musste um Trafficlimits und Zensur zu umgehen weiß ich noch, dass es Programme gibt mit denen man eine SOCKS-Konfiguration erzwingen kann, sogenannte "socksifier". Ich denke sowas kann ich dann benützen, wenn ein Programm sich nicht entsprechend konfigurieren lässt.