Multihop mit einem VPN Anbieter

JeGr

Nein ich bin kein Mitglied des IS. Mich interessiert nur ob man das in pfSense umsetzen kann. Bevor ich etwas von Multihop gehört habe, dachte ich das OpenVPN alleine ein 100%igen Schutz bieten würde.

100% bekommst du nirgends.

Ja das ist mein Ziel. Wenn die Verschlüsselung stark erhöht wird, dann kann man immer noch eine leistungsfähigere Hardware nehmen.

Was ist das Ziel? Starke Erhöhung der Verschlüsselung? Wofür? Welchen Anwendungsfall hast du dafür?

Wie setze ich eine Kaskade (oder verschaltete VPN) um?

Entweder ich habe mich verlesen oder etwas übersehen, aber eine Kaskade ist in meiner Nomenklatur immer noch (bspw. bei Switchen) das hintereinander hängen oder nacheinanderstapeln von Dingen. In dem Fall also ein VPN zu A und dann ein VPN von A nach B und B dann ins Internet wäre m.M.n. eine Kaskade (mit 2 Hops A und B). Ein verschachteln - also Tunnel in Tunnel - wäre dann 2x einen Tunnel aufzubauen und den 2. Tunnel durch den ersten hindurch.

Letzterer Fall macht für mich nur marginal bis gar keinen Sinn, da

a) es unnötige Komplexität mit bringt
b) man sich dadurch jegliche MTU und Packetgröße versaut und damit auch Durchsatz und Latenz
c) es fehleranfällig ist (Tunnel 1 ist aus $Gründen nicht da und Tunnel 2 baut sich jetzt plötzlich "normal" übers WAN auf statt durch Tunnel 1 durch)
d) ich den Sinn nicht sehe, was es an großem Gewinn an Verschlüsselung bringt

Gerade d) muss ich mich am Kopf kratzen. Es wäre mir nicht bekannt, dass es momentan sinnvolle Angriffsvektoren gibt gegen AES128, geschweige denn AES256 mit SHA256 oder SHA384. Mit OpenVPN 2.4 Unterstützung kommen dann noch zusätzlich neue und auch größere Cipher und Codecs mit ins Spiel. Warum baue ich also mit aller Macht ein Monster mit komplex geschachtelten Tunneln auf?

Vielleicht mag mir das ja jemand sinnvoll erläutern, dann lerne ich vielleicht auch was dazu ;)

David127

Was ist das Ziel? Starke Erhöhung der Verschlüsselung? Wofür? Welchen Anwendungsfall hast du dafür?

Ein Anwendungsfall habe ich nicht. Ich kann nur auf die Vorteile verweisen, die im ersten Postlink zu finden sind.

Hier ein kleiner Auszug der Vorteile:
1.Kein verwendeter VPN-Server verarbeitet/speichert die zur Ausforschung notwendigen Daten (Ursprung<>Ziel).
2.Eine mögliche Protokollierung/Logfile-Speicherung der VPN-Server würde dabei KEINE Hinweise auf „Nutzer <> Aktivitäten“ verraten können.
3.Selbst wenn eine gezielte längerfristige Überwachung, selbst der Server generell, stattfindet, ist damit eine Verfolgung von Benutzeraktivitäten völlig unmöglich.

Entweder ich habe mich verlesen oder etwas übersehen, aber eine Kaskade ist in meiner Nomenklatur immer noch (bspw. bei Switchen) das hintereinander hängen oder nacheinanderstapeln von Dingen.

Danke für die Erklärung JeGr.

Ich habe da wohl die Begriffe Kaskade und Verschachtelung vermischt. Wenn die Verschachtelung aus vielen Gründen keinen Sinn macht, dann würde ich gerne wissen wie man bei pfSense eine Kaskade konfiguriert.

Vielen Dank im Voraus.

viragomann

Okay, jetzt sind wir erstmal soeit, dass wir alle vom selben sprechen. Schön erklärt von Jens. :)

Das, was in deinem Link beschrieben ist, ist demnach eine VPN-Kaskade (=Multi-Hop-VPN). Das kann so aussehen:
Du >–---> A >-----> B >-----> C >-----> Internet.
Du baust eine VPN zu A auf. Knoten A kennt deine IP und Identität, an diesem musst du dich eben anmelden. Andere User melden sich ebenso an diesem Server an. A baut mit seiner externen IP eine Verbindung zu B auf. B kennt also nur die IP und Identität von A, von dem was da in der VPN durchläuft, hat er keinen Schimmer. B baut wiederum mit seiner externen IP eine VPN zu C auf. Für C gilt selbiges, nur verschoben, er kennt die IP und Identität von B, er hat aber weder eine Ahnung, dass die Datenpakete von A kommen (vermutlich kommen auch von anderen Knoten Pakete) und noch weniger, welche User daran hängen. C schickt die Pakete dann mit seiner IP auf den Zielhost im Internet, den du kontaktieren willst. Für das Ziel kommen die Pakete also vom Knoten C und genau diesem schickt er auch seine Antwort und so gehen die Antworten genau denselben Weg zurück. Nur A also schickt das Paket an dich und nur dieser kennt deine IP. (es sei an dieser Stelle angemerkt, dass gewisse Dienste im Internet, keine Anfragen von VPN-Servern beantworten, weil sie wissen wollen, wer dahinter steckt).

Nun, was hast du mit dem Ganzen zu tun??? Du baust eine VPN zu A auf. Das war's. Das weitere macht der VPN-Dienst, das habe ich oben schon erwähnt.

An diesem ganzen Mult-Hop Geheimnis ist also nicht weiter dran als ein ganz normale VPN-Client-Verbindung. Du musst dir nur den richtigen VPN-Provider dazu aussuchen, bzw. den richtigen Tarif auswählen.

Du suchst dir also einen VPN Provider, der OpenVPN unterstützt und Multi-Hop bietet, z.B. NordVPN wurde in dem Artikel erwähnt, meldest dich bei diesen an und erhältst von ihm deine Zugangsdaten, die Server-IP oder den -URL und das Zertifikat seiner Root-CA, ggf. vieleicht noch ein User-Zertifikat (ist aber eher die Ausnahme) und die nötigen Einstellungsdaten. Damit kannst du dir die VPN einrichten. Wie das im Detail geht, erklären unzählige Tutorials im Netz. Tlw. stellen die VPN-Provider ein spezielles für pfSense bereit, wie bsp. der oben erwähnte NordVPN:
https://nordvpn.com/tutorials/pfsense/pfsense-openvpn

Wenn du nun hier erfahren möchtest, wie das genau einzurichten ist, musst du zumindest einen Provider nennen.

JeGr

OK vielleicht verstehe ichs immer noch nicht, aber:

Hier ein kleiner Auszug der Vorteile:
1.Kein verwendeter VPN-Server verarbeitet/speichert die zur Ausforschung notwendigen Daten (Ursprung<>Ziel).

So ich das gelesen/verstanden habe, macht die Kaskade eh der Anbieter - ergo ist das Quatsch. Natürlich hat er die notwendigen Daten, man kommt nur umständlicher ran. Und wenn die Kaskade dann auch noch ein Anbieter alleine macht, ist es noch sinnbefreiter. So muss man eben ggf. 2 oder 3 Anbieter abklappern und von denen die Verbindungsdaten einfordern. Und wenn die einer oder mehrere nicht haben - warum dann nicht direkt nur die nutzen?

2.Eine mögliche Protokollierung/Logfile-Speicherung der VPN-Server würde dabei KEINE Hinweise auf „Nutzer <> Aktivitäten“ verraten können.

Das ist ein Trugschluss. Bei Untersuchungen werden vom Ziel mit dem du eine Verbindung aufgebaut hast - bspw. mal ein Forum o.ä. - Logfiles bereitgestellt. Dort postet AnonyUserA um 9:27 einen Beitrag. Der kommt von VPN C, der dann Daten davon hat, dass bei ihm über VPN (von B) Daten an Zielserver X rausgingen. Dito für B, der sieht Daten von A ankommen und zu C gehen in dem Zeitfenster und A schließlich kann die zu dir zeigen lassen. Der ganze angebliche Vorteil beruht allein darauf, dass man hofft, dass durch die Masse an Daten von A->B und B->C die Daten untergehen und/oder dass B und C keine Aktivitäten loggen. Nur wenn sie das nicht tun - und A auch nicht - dann muss man den ganzen Zirkus schon nicht machen.

3.Selbst wenn eine gezielte längerfristige Überwachung, selbst der Server generell, stattfindet, ist damit eine Verfolgung von Benutzeraktivitäten völlig unmöglich.

Dass das ein Trugschluß ist, sollte durch 2. klar werden. Wenn eine längere Überwachung der Server stattfindet, ist auch hier ein Muster auszumachen, dass bei untersuchter Aktivität von dir bspw. immer von C aus Daten fließen und ggf. auch von B zu C zu sehen sind. Ein Trennen der Verbindung B->C würde zudem sehen lassen, dass dann keine Aktivität mehr stattfindet.

Natürlich kann man sowas herausfinden. Es ist nur um ein vielfaches schwerer. Was wiederum den ursprünglichen Punkt, den Virago angeschnitten hatte wieder aufwirft. Also die nicht ernst gemeinte Frage ob man zum IS gehört. Der Aufriß der hier betrieben wird wäre verständlich und entsprechend zu rechtfertigen, wenn es um ein Security Bedürfnis nach Maslow (also M1-2) ging. Das bezweifle ich aber ganz stark, weshalb ich mich frage, warum man für ein M3+ (eher M4 oder M5) Ding so einen Aufwand produziert und dafür dann entsprechend auch noch Geld oder gar mehr Geld zahlt. Zumal der komplette Aufwand überflüssig wird, wenn bei einer personenspezifischen Untersuchung dein Internet Anschluß selbst auf den Prüfstand kommt. Dann ist nämlich klar, dass du eine Verbindung mit A via VPN aufbaust und man läuft statt zu C oder B direkt zu A und lässt sich die Daten geben. Ergo: Geht es um ein M1-2 Problem deiner Sicherheit(!), dann wirst du eh überwacht werden und hast ganz andere Probleme als VPN Kaskaden. Bei einem Datenschutz/Anonymitäts-"Gesuch"/Wunsch bist du im M3-5 Bereich, wodurch sich aber schon wieder - zumindest IMHO - der Aufwand und Preis nicht rechtfertigt, da würde es ein normales VPN ohne Logging auch tun.

Deshalb habe ich gefragt, was das eigentlich bezwecken sollte, denn ein M1/2 Problem wäre hier in meinen Augen anders anzugehen.

Grüße :)

viragomann

@JeGr:

So ich das gelesen/verstanden habe, macht die Kaskade eh der Anbieter

So würde ich es vermuten aufgrund des Textes und dessen, was die VPN-Anbieter auf ihren Webseiten verkünden. Andernfalls müssten ja die VPN Provider zusammenarbeiten, was ich bezweifle, nachdem jeder davon selbst zig Server über den Globus verteilt hat.

Dagegen verspricht bspw. NordVPN hoch und heilig, dass nichts geloggt wird. Ja, wenn das stimmt, ist die Sache tatsächlich nicht nachverfolgbar. Aber auch mein notorisches Misstrauen gegen IT Unternehmen lässt mich daran etwas zweifeln.

JeGr

Aber auch mein notorisches Misstrauen gegen IT Unternehmen lässt mich daran etwas zweifeln.

Nicht nur das, sondern auch die je nach Lokalität des Providers geltenden Gesetzeslagen. Und so gern man natürlich $dinge anbieten und verkaufen möchte, kaum ein Anbieter möchte sich (vorsätzlich) strafbar machen. Und wenn wie gesagt kein Logging stattfindet, dann ist wiederum der Sinn von Kaskaden (und die Zusatzkosten) nicht so wirklich gegeben.

David127

Du baust eine VPN zu A auf. Knoten A kennt deine IP und Identität, an diesem musst du dich eben anmelden. Andere User melden sich ebenso an diesem Server an.

Diese Konfiguration/Anleitung kenne ich von den meisten VPN Anbietern.

Also die Methode: Ich >–---> A >------> Internet. Die Konfiguration habe ich bereits mit dem VPN Anbieter oVPN.to, die 24h/7t die Woche läuft.

Nun, was hast du mit dem Ganzen zu tun??? Du baust eine VPN zu A auf. Das war's. Das weitere macht der VPN-Dienst, das habe ich oben schon erwähnt.

Wie soll ich mir das vorstellen? Nachdem ich eine VPN zu A aufgebaut habe, sage ich meinem VPN Anbieter bescheid welche Server und wieviele hintereinander gehängt werden sollen? Das wäre doch ein riesen Aufwand für ein VPN Anbieter, oder nicht?

Was müsste denn so ein VPN Anbieter an Funktionen bereitstellen, damit alles weitere (von A nach B) der VPN-Dienst macht?

Nur so als Beispiel, bei Perfect Privacy kann man über Linux manuell Multi-Hops aufbauen.
Link:https://www.perfect-privacy.com/german/anleitungen/kaskadierte-vpn-verbindung-ueber-mehrere-hops-unter-linux/
Deshalb habe ich mir gedacht, dass es zumindest auch mit pfSense gehen sollte.

OK vielleicht verstehe ichs immer noch nicht, aber:
Vorteile:
1.
2.
3.

Gut zu wissen das diese Vorteile Quatsch oder Trugschluss sind. Ich selbst kann es nicht beurteilen, da mir das technische Verständnis fehlt. Auf die Schnelle habe ich nur 2 VPN Anbeiter gefunden, die Multi-Hop erklären. Vielleicht wird daraus der Anwendungsfall ersichtlich.

Link1:https://www.perfect-privacy.com/german/2016/09/30/vorteile-einer-kaskadierten-vpn-verbindung/
Link2:https://www.ivpn.net/what-is-a-multihop-vpn

viragomann

Was da erklärt wird, sind VPNs durch andere VPNs, Perfect Privacy zeigt das besonders schön.
Dann hab ich das bislang falsch verstanden.

Das ist natürlich auch mit einem einzigen Provider möglich, wenn er es dir erlaubt, dich gleichzeitig bei mehreren Servern anzumelden, denn das ist das, was hier gemacht wird.
Über Sinn und Nachteile einer solchen Konstellation möchte ich nun nicht nochmals diskutieren. Jens hat die Punkte ganz ausführlich aufgezählt.

Möglich ist das vermutlich in pfSense, wenngleich ich es selbst noch nicht umgesetzt habe. Das dann so aussehen, dass du mehrere Clients konfigurierst und die hintereinander startest.
Es ist dann nur eine Frage des richtigen Routings. Es muss jeder VPN-Server auf das Gateway des zuvor aufgebauten gelegt werden. Das kann in der Client Konfiguration in der pfSense GUI so gemacht werde, dass die IP des jeweils nächsten Hops in das Feld "Remote networks" gesetzt wird (mit /32 hinten dran), zusätzlich müsste mit Ausnahme des letzten Hops "Don't pull routes" gesetzt werden.

Problem dabei ist vielleicht, dass pfSense sämtliche VPN Clients automatisch startet. Falls die Verbindungen parallel aufgebaut werden, kann es passieren, dass versucht wird, eine Verbindung zu initiieren, ehe der vorige Client die Route dafür gesetzt hat. Dann würde die Verbindung über die Standardroute gehen und nach ändern dieser wohl abbrechen. Aber damit habe ich eben keine Erfahrung.
Möglicherweise ist es eine Abhilfe, die Routen statisch zu setzen und das Watchdog Paket einzusetzen um die Clients zu überwachen und zu restarten. Voraussetzung wäre aber, dass das VPN-Gateway auf einem Server immer dasselbe ist.
Du kannst aber jederzeit in der GUI Verbindungen wieder abbrechen und die ganze Route von Hand aufbauen. Das sollte problemlos klappen.

David127

Was da erklärt wird, sind VPNs durch andere VPNs, Perfect Privacy zeigt das besonders schön.

Wäre das was JeGr erwähnt hat? Also:

"Ein verschachteln - also Tunnel in Tunnel - wäre dann 2x einen Tunnel aufzubauen und den 2. Tunnel durch den ersten hindurch"

Ich frage mich dann warum PP von einer Multihop Kaskade redet, wenn es ein Verschachteln ist.

Über Sinn und Nachteile einer solchen Konstellation möchte ich nun nicht nochmals diskutieren. Jens hat die Punkte ganz ausführlich aufgezählt.

Wenn PP auf ihrer Homepage schreibt, dass so eine Konfiguration Vorteile mit sich bringt, dann probiere sie gerne mit pfSense aus.
Ob es dann funktionieren wird, werde ich es früher oder später sehen.

Möglich ist das vermutlich in pfSense, wenngleich ich es selbst noch nicht umgesetzt habe. Das dann so aussehen, dass du mehrere Clients konfigurierst und die hintereinander startest.
Es ist dann nur eine Frage des richtigen Routings. Es muss jeder VPN-Server auf das Gateway des zuvor aufgebauten gelegt werden. Das kann in der Client Konfiguration in der pfSense GUI so gemacht werde, dass die IP des jeweils nächsten Hops in das Feld "Remote networks" gesetzt wird (mit /32 hinten dran), zusätzlich müsste mit Ausnahme des letzten Hops "Don't pull routes" gesetzt werden.

Ich versuche das nochmal zusammen zu fassen:

Ich starte Client A (mit Server host or address IP: 95.0.0.10), Client B (mit Server host or address IP: 105.0.0.20) und Client C (mit Server host or address IP: 115.0.0.30).

-Clien A bleibt unverändert. Da wir also nichts eingetragen.
-Bei Client B kommt unter:

Remote Networks: 95.0.0.10/32
"Don't pull routes" wird aktiviert

-Bei Client C kommt unter:

Remote Networks: 105.0.0.20/32
"Don't pull routes" wird aktiviert

Falls der Aufbau nicht funktionieren sollte, müsste ich die Clients einzeln nacheinader starten. Also A, dann B und dann C.
Habe ich das soweit richtig verstanden?

Alternative:

Möglicherweise ist es eine Abhilfe, die Routen statisch zu setzen und das Watchdog Paket einzusetzen um die Clients zu überwachen und zu restarten.

Das müsstest du mir genauer erklären. Wie setzt man eine Route statisch bzw. wie müsste die Konfiguration dann aussehen?

Voraussetzung wäre aber, dass das VPN-Gateway auf einem Server immer dasselbe ist.

Mein VPN Anbieter (oVPN) hat bei jedem Server eine gleiche Gateway IP.

Unter welchem Begriff läuft so eine Konfiguration in englisch? Vielleicht gab es bereits einige Versuche mit anderen VPN Anbietern.

JeGr

Wenn PP auf ihrer Homepage schreibt, dass so eine Konfiguration Vorteile mit sich bringt, dann probiere sie gerne mit pfSense aus.
Ob es dann funktionieren wird, werde ich es früher oder später sehen.

Wird aus meiner Sicht gerade nicht in pfSense funktionieren. Gerade Perfect Privacy erklärt das ja mit seinem tollen-super-duper eigenen Client für Windows der das ermöglicht. Natürlich ist da OpenVPN drunter, aber da wird eben zum Tunneln wohl viel routingtechnisch gemauschelt und gedreht, was ich nicht sehe, wie man das mit der UI von pfSense abbilden will. Da pfSense keine definierte Reihenfolge hat, in der VPN Clients gestartet werden (die starten m.W. parallel bzw. es könnte sein, dass die nach Zeit X ein Renew machen und die Reihenfolge nicht mehr gegeben ist), wäre ein Tunnel 2 durch Tunnel 1 konfiguriert nicht wirklich möglich. Auch ist das abgehende Interface zwar konfigurierbar (wenn das andere VPN als Interface angelegt wird), aber ich mutmaße dass es einen Fehler gibt, wenn Tunnel 1 nicht da ist und Tunnel 2 aufgebaut werden soll.

Wenn man sieht, was unter
https://www.perfect-privacy.com/german/anleitungen/kaskadierte-vpn-verbindung-ueber-mehrere-hops-unter-linux/
alles für Einzelschritte unter Linux auf der Console notwendig sind, halte ich es für unpraktisch / nicht sinnvoll machbar unter pfSense in der Oberfläche automatisierbar.

Wie gesagt, der Gewinn des Ganzen wird natürlich von dem der es verkauft hoch gelobt. Wer würde schon sagen, dass der Kram den er anbietet Unfug ist? ;)
Ich empfinde die Erklärung die oben unter 1: verlinkt ist ein wenig irreführend, da hier von einer Verstärkung der Sicherheit "blabla" gesprochen wird weil ja mehrere VPNs aufgebaut werden -> ja aber vom gleichen Provider. Wenn ich es auf den Traffic abgesehen habe, wie der Artikel auch spricht, dann gehe ich ggf. eh gegen den VPN Provider selbst vor, und gehe nicht undercover in irgendwelche Rechenzentren und versuche anonym irgendwelchen Traffic mitzuschneiden. :D Und bei potentieller Straftat in Verzug werden wohl am Ende doch die meisten VPN Provider einlenken und Zugang gewähren. Zwar vielleicht nicht auf Altdaten aber dann zumindest auf aktuelle Zugriffe und DIE kann ein VPN Provider sehr wohl mitschneiden - muss er ja, denn er muss deinen Account ja abgleichen, ob du bezahlt hast und das darfst was du tust. Ergo weiß er auch wenn du eine zwei drei VPN Tunnel aufbaust, denn jeder der VPN Server des Providers muss dich authentifizieren.

Grüße