Proton Produkte

Simeria

New Member
Hi,

ich bin mit PP, bis auf einige "Maken" die wir alle hier kennen, relativ zufrieden. Vertrauen sollte die Basis im VPN-Geschäft sein.
Aktuell teste ich Proton. Mir fehlen bei PP einige Server-Länder um Länderspezifisches Content zu erhalten usw.
Habt ihr irgendwelche Erfahrung mit Proton gemacht? Ich weis, die Foren sind voll mit Berichten, aber evtl. ist hier der ein oder andere der
sich outen will ;)
 
Nope, nicht fremd gegangen. Und du weißt ja, 2 verschiedene VPNs verringern sogar die Sicherheit. Selbst wenn VPN1 am PC und VPN2 in der VM/am Router ist.

Und das die Konkurrenz die Versprechen nicht einhält/mit Strafverfolgern und sonstwem Kooperiert/eventuell deine Daten weiter gibt oder so... ist ebenfalls Möglich.
Es gibt nur 1-2, die man überhaupt anschauen könnte.
 
verringern sogar die Sicherheit. Selbst wenn VPN1 am PC und VPN2 in der VM/am Router ist.
Hm... warum? Angenommen wir haben VPN X auf dem Host und VPN Y in einer virtuellen Maschine. Dann sieht VPN X nur den verschlüsselten Datenverkehr, der über VPN Y gesendet / empfangen wird. VPN Y dagegen sieht nur die IP von VPN X. Sind Bezahldaten mit Nutzerdaten verknüpfbar, obwohl das beide abstreiten, aber trotzdem machen (könnten), so würde sich dieses Risiko verdoppeln.
Aber wir gehen jetzt einfach mal hypothetisch davon aus, dass beide VPNs anonym bezahlt werden können. Inwiefern erhöht diese Konstellation nun das Risiko, als wenn man nur eines von beiden verwenden würde?
 
...Inwiefern erhöht diese Konstellation nun das Risiko, als wenn man nur eines von beiden verwenden würde?
Lies mal den Punkt "WARNUNG: Verschachtelte VPN-Verbindungen sind keine „Kaskaden“"


Dort wird das erklärt.
 
Lies mal den Punkt "WARNUNG: Verschachtelte VPN-Verbindungen sind keine „Kaskaden“"


Dort wird das erklärt.
Und wie verhält es sich wenn auf dem Host VPN1 mit Multihop genutzt wird + auf der VM VPN2 auch mit Multihop? Wäre interessant, vielleicht kann @PP Christian auch was dazu sagen.
 
vielleicht kann @PP Christian auch was dazu sagen
Ich habe mich zur Sicherheit noch mal mit Lars abgesprochen. Bei PP ist es kein Problem die Verbindungen zu verschachteln, da durch das Firewalling nichts nach außen dringen kann, wenn eine der Verbindungen abbricht. Wir können aber nur für unser VPN die Hand ins Feuer legen. Wenn man also einen anderen Anbieter hinzuzieht und mit PP kombiniert haben wir das natürlich nicht in unserer Hand. Dies empfehlen wir daher nicht.
 
Ich habe mich zur Sicherheit noch mal mit Lars abgesprochen. Bei PP ist es kein Problem die Verbindungen zu verschachteln, da durch das Firewalling nichts nach außen dringen kann, wenn eine der Verbindungen abbricht. Wir können aber nur für unser VPN die Hand ins Feuer legen. Wenn man also einen anderen Anbieter hinzuzieht und mit PP kombiniert haben wir das natürlich nicht in unserer Hand. Dies empfehlen wir daher nicht.
Auch wenn man PP als Host VPN nutzt? Dann dürfte doch normalerweise auch nichts leaken wenn ein anderer Anbieter auf der VM ist und auf der Host Verbindung basiert oder übersehe ich da etwas?
 
Lies mal den Punkt "WARNUNG: Verschachtelte VPN-Verbindungen sind keine „Kaskaden“"


Dort wird das erklärt.
Was da steht gilt für User, die sich nicht gut auskennen. Wer weiß, was er tut, hat mit dem beschriebenen Szenario keine Probleme.
Bei mir enthalten im Kaskadenfall die routing-Tabellen nur die PP-private IPs und bei nicht laufendem Tunnel 127.0.0.1.
Da kann der innere Tunnel noch so oft versuchen, sich zu verbinden.
Das läßt sich bei openvpn leicht mit dem route-up und dem plugin command machen
 
Wieso nicht einfach den VPN Anbieter den man nicht Vertraut weglassen?

Man kann ja nur auf die Idee kommen seinen 1. VPN Anbieter nochmal mit einem 2. zu Tunneln weil man kein 100% Vertrauen in den 1. hat. Etwas anderes macht überhaupt keinen sinn ...
 
Was da steht gilt für User, die sich nicht gut auskennen. Wer weiß, was er tut, hat mit dem beschriebenen Szenario keine Probleme.
Bei mir enthalten im Kaskadenfall die routing-Tabellen nur die PP-private IPs und bei nicht laufendem Tunnel 127.0.0.1.
Da kann der innere Tunnel noch so oft versuchen, sich zu verbinden.
Das läßt sich bei openvpn leicht mit dem route-up und dem plugin command machen
Damit kein Leak entsteht, werden doch die Firewallregeln erstellt (der PP-Client tut dies ja). Verstehe nicht, weshalb es zu einem Leak kommen sollte, nur weil VPN Y sich jetzt neu verbinden will. Was soll das für einen Einfluss auf VPN X (in dem Fall dann PP) haben?
 
Damit kein Leak entsteht, werden doch die Firewallregeln erstellt (der PP-Client tut dies ja). Verstehe nicht, weshalb es zu einem Leak kommen sollte, nur weil VPN Y sich jetzt neu verbinden will. Was soll das für einen Einfluss auf VPN X (in dem Fall dann PP) haben?

Ich glaube du unterschätzt da etwas die Komplexität, wenn du mehrere VPN Anbieter auf EINEM Rechner laufen lassen willst. Da kann gewaltig viel schief gehen! Netzwerktechnik ist unglaublich komplex. Ich kann nur davon abraten, insbesondere den leihen.
 
Wieso nicht einfach den VPN Anbieter den man nicht Vertraut weglassen?

Man kann ja nur auf die Idee kommen seinen 1. VPN Anbieter nochmal mit einem 2. zu Tunneln weil man kein 100% Vertrauen in den 1. hat. Etwas anderes macht überhaupt keinen sinn ...
Ich vertraue keinem VPN Anbieter 100%, das wäre absolut fahrlässig.
 
Was da steht gilt für User, die sich nicht gut auskennen. Wer weiß, was er tut, hat mit dem beschriebenen Szenario keine Probleme.
Bei mir enthalten im Kaskadenfall die routing-Tabellen nur die PP-private IPs und bei nicht laufendem Tunnel 127.0.0.1.
Da kann der innere Tunnel noch so oft versuchen, sich zu verbinden.
Das läßt sich bei openvpn leicht mit dem route-up und dem plugin command machen
Hättest du da einen Leitfaden dazu? Ich nutze standardmäßig den Killswitch von PP auf permanent aber habe keine weiteren routen eingerichtet.
 
Ich vertraue keinem VPN Anbieter 100%, das wäre absolut fahrlässig.
Also, ich sage es mal so. Ich will niemandem was Unterstellen/Suggerieren/sonstwas... Ich mache nichts illegales, ich weiß nur das es Leute gibt, die hinter mir her sind (erst heute wieder 2 Telefonate geführt...). Aus Erfahrung (ich habe denen noch gesagt, holt einen Anwalt dazu) weiß ich, das Polizei/Staatsanwalt nicht Vertrauensfähig sind. Und das könnte ich jedem Richter erklären das er danach sagt "Ja, da haben Sie recht."
Aber ich bin so unwichtig, das keiner sich die Mühe machen sollte, die VPN-Verbindung zu knacken (die waren, glaube ich, schon seit über 1 Jahr nicht mehr in meiner Wohnung während meiner Abwesenheit und haben die Internetkameras vorher deaktiviert).

Aber wenn jemand was illegales machen will, gibt es keine 100% Garantie; die finden den PP-VPN nicht, aber der VPN der danach läuft, dort haben Sie deine Bankdaten (schonmal daran gedacht das man dich über unzählige Sachen identifizieren kann? VPN ist das allereinfachste im Thema "Privatsphäre". Der Rest wird immer schwerer. Selbst Youtube tutorials sind nicht geeignet für so was).
Wieso du so einen Sicherheit brauchst weiß ich nicht, aber wechsle den Aluhut von Zeit zu Zeit mal und ja, selbst erfahrene Profis laufen Gefahr, geschnappt zu werden. Dann überleg dir mal, wie du als Laie das besser kannst.
 
Hättest du da einen Leitfaden dazu? Ich nutze standardmäßig den Killswitch von PP auf permanent aber habe keine weiteren routen eingerichtet.
Das ist schwierig und sehr situationsbezogen.
Mein script, welches nach dem Tunnelaufbau läuft ist inzwischen 33k lang.
Der vpn-client läuft auf einer dedizierten VM, über die jeder traffic geht. Nur so kannst Du genau steuern, was wie 'raus soll.
Das Wichtigste ist, daß man die Firewallregeln versteht und im Griff hat. Zur Sicherheit kontrolliert m,an mit tcpdump, ob wirklich alles so geroutet ist, wie man es haben will und nichts durchschlüpft. Auch die Firewall-logs sind wichtig. Ich lasse jedes reject loggen und gucke ab und zu mal drüber...
 
Schau Dir linux advanced routing an, und wie man zusätzliche routing-rules und tables anlegt.
Hier nur ein knapper Ausschnitt aus meinen scripten:
function null_route () { # before restarting, null route the respective routes # thus if tunnel setup is unsuccessful the routes will not leak # todo: make sure a rule exists for null routing to work #ipV4: echo "nullrouting $proxy" # first pp_table add_tun_route "-4" "default" "lo" "$pp_table" debecho "ip -4 route change default dev lo table $pp_table" 3 ip -4 route change default dev lo table $pp_table >/dev/null 2>&1 if [ $? -ne 0 ] ; then # change failed, because there was no default # echo "ip -4 route add default dev lo table $pp_table" ip -4 route add default dev lo table $pp_table fi echo "ip -4 route flush cache table $pp_table" ip -4 route flush cache table $pp_table #ipV6: ... function add_tun_route { if [ $# -eq 5 ] ; then local IPVersion=$1 local Lroute=$2 local Linterface=$3 local Lsource=$4 local Ltable=$5 echo "ip ${IPVersion} route change ${Lroute} dev ${Linterface} src ${Lsource} table ${Ltable}" ip ${IPVersion} route change ${Lroute} dev ${Linterface} src ${Lsource} table ${Ltable} >/dev/null 2>&1 # ip ${IPVersion} route change ${Lroute} dev ${Linterface} src ${Lsource} table ${Ltable} 2>&1 if [ $? -ne 0 ] ; then # change failed, because there was no route, add instead echo "ip ${IPVersion} route add ${Lroute} dev ${Linterface} src ${Lsource} table ${Ltable}" ip ${IPVersion} route add ${Lroute} dev ${Linterface} src ${Lsource} table ${Ltable} >/dev/null 2>&1 # ip ${IPVersion} route add ${Lroute} dev ${Linterface} src ${Lsource} table ${Ltable} 2>&1 fi else ...
 
Back
Top