LinkSnappy - Paysafecard Nutzung mit VPN nicht möglich

Hallo Leute,

Ich würde gerne LinkSnappy nutzen, mich jedoch so anonym wie mir möglich ist anmelden. Ich habe hier im Forum gelesen, dass LinkSnappy die Möglichkeit bietet mit Paysafecard zu zahlen. Daraufhin habe ich mich über den Tor Browser angemeldet. Allerdings konnte ich dann die Option mit Paysafecard zu zahlen nicht finden. Im Service Chat hat mir der Mitarbeiten von LinkSnappy erklärt, dass die Option bei Nutzung eines VPN nicht möglich ist.

Daher habe ich folgende Fragen an die Erfahrenen unter euch.

Woher weiß LinkSnappy, dass ich einen VPN nutze?
Habt ihr eine Idee wie man das System entsprechend austricksen kann?

Danke und Gruß
cowcircuseffect

@cowcircuseffect

Davon mal abgesehen, dass der TOR-Browser mal so rein gar nichts mit einem VPN-Dienst zu schaffen hat, da beide Techniken völlig unterschiedlich arbeiten, können aber beide Dienste durch Dritte (LinkSnappy) erkannt werden!

Die einfachste Art der Erkennung passiert schon, wenn du z.B. mit einer amerikanischen IP (egal, ob durch einen Exit-Node oder einen USA VPN-Server) bei einem Dienstleister mit Euro bezahlen möchtest…da kann es passieren, dass nach Eingabe des PSC-Codes einfach die Zahlung verweigert würde!

Rein technisch gesehen, sind die Gründe, warum z.B. ein LinkSnappy-Server erkennt, dass du mit einem VPN unterwegs bist, recht einfach. Dazu muß man aber wissen, wie eine Kommunikation zwischen zwei Punkten über das Internet tatsächlich funktioniert.
Einfach gesagt:
Es wird nicht nur eine blöde IP übertragen, sondern ganze Massen von Daten, die über einen sogenannten Frame (Rahmen) zu Paketen zusammengefasst werden. Der Austausch dieser Pakete in beide Richtungen zwischen den beiden Endpunkten ergeben eine Verhandlung über die gewünschte Verbindung, die im Ergebnis positiv oder auch negativ ausfallen kann !!
Die Inhalte dieser Datenpakete sind sehr vielschichtig und geben natürlich einiges an Informationen mit - da VPN-Server über spezielle Protokolle und Ports mit der Aussenwelt kommunizieren, werden diese Infos in den Paketen mitgeschickt. Ein sauber konfigurierter Server auf der Gegenseite, an den die Verbindungsanfrage gestellt wird, erhällt natürlich diese Infos vom Absender und wertet die aus.
Wenn dann bei der Auswertung z.B. ein typisches VPN-Protokoll dabei ist, erkennt der Empfänger das entsprechend und leitet dann die vorab konfigurierten Massnahmen ein - bei LinkSnappy dann halt eine Ablehnung bzw. Einschränkung der gewünschten Verbindung!

Hier nochmal eine relativ verständliche, technische Beschreibung des Vorgangs:

Die obige generische Darstellung des IPSec VPN Packetes funktioniert für eine allgemeine Überprüfung, aber es gibt Details in den Kopfzeilen, die um Prüfungsfragen betteln und die aufgeschlüsselt und im Gedächtnis gespeichert werden müssen, wenn man nach ihnen gefragt wird.

AH (Authentication Header) = Sicherheit, Datenursprungs-Authentifizierung (bietet auch einen Anti-Reply-Schutz)
ESP (Encapsulating Security Payload) = Verfahren zur Authentisierung / Sicherung / Verschlüsselung der Datennutzlast
IKE (Internet Key Exchange) - Das Protokoll zum Aushandeln von Sicherheitsparametern und Authentifizierungsschlüsseln zur Bildung einer SA (Security Association)
Wenn Sie von oben nach unten gehen, können Sie jeden Pakettyp in der Liste oben vom oberen Rand der Seite aus überprüfen:

Generischer Frame = Ethernet-Kopf | IP-Kopf | Protokoll-Kopf | Nutzlast

  1. Ethernet-Header = kapselt Ethernet-Frame

  2. IP-Header = Quell-IP-Adresse

  3. TCP/UDP Header = Port-Informationen, für einen kurzen, aber prägnanten Vergleich von TCP vs. UDP Headern, bei denen der Link Gold ist

  4. Daten / Nutzlast = „Blah blah blah blah“
    Verwendet von GRE, was meist in Bezug auf mGRE für DMVPN Funktionalität erwähnt wird, kann es auch so konfiguriert werden, dass es für INSIDE IPSec VPN-Tunnel gekapselt wird, da es keine Einschränkungen hat, die IPSec VPN’s haben, welche wie folgt sind

  5. IPSec-Tunnel können Unicast-Informationen sichern und verschlüsseln, nicht aber Multicast- oder Broadcast-Verkehr, der zwischen den Standorten benötigt wird.

  6. GRE-Tunnel senden Unicast-Pakete, die Multicast- und Broadcast-Verkehr einkapseln können, der dann als Unicast-Paket in ein neues IPSec-Paket gelegt werden kann, so dass Multicast- und Broadcast-Verkehr VPN-Tunnel durchlaufen kann!
    Es wird ein separates Labor für GRE / IPSec geben, das dieses Konzept demonstrieren wird, da es wichtig ist, sowohl für das Labor als auch für die Praxis zu wissen, da wir immer mehr Tools für die Arbeit benötigen!

Tunnelmodi für VPN-Typen im Detail erklärt

Zuerst werden die beiden Transport Modi besprochen, da sie ein Feld switcheroo in den Paketfeldern verstecken, die man auf den ersten Blick übersehen würde:

  1. Der Tunnel-Modus verschlüsselt das Paket und fügt es in ein neues Paket ein, das dann auf vereinbarten IP-Adressen zwischen den Tunnel-Endpunkten weitergeleitet wird.
  2. Der Transportmodus verschlüsselt die Nutzlast der IP-Pakete, aber der IPSec-Header wird hinter dem IP-Header eingefügt, wodurch die Quelladresse der Daten offengelegt wird, und sichert nur die Daten von der Transportschicht aufwärts wirklich ab, da die Quell-IP verwendet wird
    Wenn Sie sich also nicht noch einmal die obere Abbildung ansehen und sagen „Oh, das habe ich nicht gesehen, gut zu wissen“, dann wissen Sie entweder schon Bescheid oder haben nicht verstanden, was Sie gerade gelesen haben

Vielleicht erklärt dir das ja deine Fragen !?! :wink:

1 „Gefällt mir“