Zum Inhalt springen
IP-Intelligence

Wie VPN- und Proxy-Erkennung wirklich funktioniert, Signal für Signal

Wie VPN-Erkennung in der Praxis funktioniert: die Signale hinter moderner VPN- und Proxy-Erkennung, von Anbieterlisten und ASN-Analyse bis zum Protokoll-Probing.

VonGeoIPHub-TeamVeröffentlichtLesezeit9 Min. Lesezeit
Leuchtender Tunnel aus Ringen, den Prüfstrahlen von außen berühren, als Sinnbild dafür, wie VPN- und Proxy-Erkennung funktioniert

Jedes Betrugs-, Missbrauchs- und Compliance-Team stellt irgendwann dieselbe Frage: Verbirgt diese IP-Adresse etwas? (Wenn Sie zuerst die Grundlagen möchten, beginnen Sie mit was ein VPN ist und wie man VPN-Datenverkehr erkennt. Dieser Beitrag geht tief in die Mechanik.) Die ehrliche Antwort lautet: Keine einzelne Prüfung kann es Ihnen sagen. Ein kommerzielles VPN, ein SOCKS-Proxy im Rechenzentrum, ein von einem Botnetz gemieteter Residential Proxy und ein Tor-Exit-Node sehen auf der Leitung alle unterschiedlich aus (die Übersicht der Proxy-Typen behandelt jede Familie), und jeder davon schlägt eine andere naive Erkennungsmethode.

Dieser Leitfaden geht die Signale durch, auf die produktionsreife Erkennungssysteme zurückgreifen, darunter zwei (Latenzprüfungen und Verhaltensmodellierung), die GeoIPHub nicht verwendet. GeoIPHub bildet seine Urteile aus sieben eigenen Familien von Verifizierungsmethoden, die dasselbe Terrain abdecken. Für jede Ebene sehen Sie, was sie erkennen kann und was nicht, und wie die Ergebnisse in die Antwortfelder zusammengeführt werden, die Sie tatsächlich nutzen: is_vpn, is_proxy, is_residential_proxy und is_tor.

Schlanke Lichtstrahlen treffen auf eine Kugel, einige werden zurückgeworfen, als Sinnbild für Protokoll-Handshake-Probes
Ein Handshake, der antwortet, ist ein Beleg; ein Listeneintrag ist eine Behauptung.

Serverlisten der Anbieter

Der verlässlichste Beleg ist der direkteste: VPN-Anbieter veröffentlichen ihre Serverinfrastruktur. Apps brauchen Endpunktlisten, um sich zu verbinden, und viele Anbieter stellen offizielle APIs oder Konfigurationspakete bereit, die jeden Server-Hostnamen und jede IP auflisten.

Erkennungssysteme crawlen diese Quellen fortlaufend. Taucht eine IP in der veröffentlichten Serverliste von NordVPN oder Mullvad auf, benennt der Treffer den Anbieter, allerdings nur, wenn genau diese IP auf einer unserer Listen steht. Ein Server, der auf den Listen fehlt, kann trotzdem von den unten beschriebenen Signalen erfasst werden und bleibt dann unbenannt. Deshalb kann eine gute API nicht nur is_vpn: true zurückgeben, sondern den Namen des Anbieters selbst, und deshalb liefert sie für einen markierten Server manchmal keinen Namen.

Die Grenze ist die Abdeckung. Veröffentlichte Listen erfassen nur Anbieter, die veröffentlichen. Diese Ebene ist also am stärksten bei den großen kommerziellen VPNs, auf die der Großteil des VPN-Datenverkehrs von Endnutzern entfällt, und am schwächsten bei privaten oder selbst gehosteten VPNs.

ASN und Hosting-Infrastruktur

Jede IP gehört zu einem Autonomen System (AS), dem Netzwerk, das sie im Internet ankündigt. Die ASN sagt Ihnen, wer das Netzwerk betreibt, und das ist eine starke A-priori-Annahme:

  • Eine IP, die von AS396982 (Google Cloud) angekündigt wird, ist mit ziemlicher Sicherheit ein Server und kein Mensch auf dem Sofa.
  • Eine IP, die von einem Privatkunden-ISP (Comcast, Deutsche Telekom, Jio) angekündigt wird, ist wahrscheinlich ein Endkundenanschluss.
  • Eine etablierte Hosting- oder Colocation-ASN mit einer Historie von VPN-Endpunkten erhöht die A-priori-Wahrscheinlichkeit für jede IP in ihren Bereichen.

Rechenzentrumserkennung allein erfasst einen großen Teil der VPNs und Proxys, weil die meiste Anonymisierungsinfrastruktur Cloud-Server mietet. Sie kann aber einen VPN-Endpunkt nicht von einem gewöhnlichen Webserver unterscheiden. Dafür braucht es die nächste Ebene.

Aktives Protokoll-Probing

Dies ist die Ebene, die die meisten Lookup-Datenbanken auslassen, und sie macht den Unterschied zwischen Raten und Verifizieren. Ein VPN-Server muss VPN-Protokoll-Handshakes beantworten; das ist seine Aufgabe. Ein Erkennungssystem kann also an die Tür klopfen und schauen, wer öffnet:

  • OpenVPN antwortet auf seinem Port auf einen charakteristischen TLS- oder UDP-Handshake.
  • IKEv2/IPsec antwortet auf UDP 500/4500 mit identifizierbaren Payloads.
  • PPTP und L2TP beantworten Anfragen auf ihrem Steuerkanal.
  • SOCKS5- und HTTP-Proxys schließen ihre jeweiligen Begrüßungssequenzen ab.

WireGuard ist die Ausnahme: Ein Server bleibt stumm, solange die erste Nachricht nicht von einem Schlüssel stammt, den er bereits kennt, sodass keine Prüfung von außen ihn bestätigen kann. GeoIPHubs Methode wireguard_open stammt aus der veröffentlichten Serverliste des Anbieters, die diesen Server als WireGuard ausweist, nicht aus einem Handshake.

Wenn eine IP einen OpenVPN-Handshake abschließt, läuft auf ihr OpenVPN. Keine statistische Schlussfolgerung nötig. GeoIPHub prüft 8 Protokolle und hält genau fest, welcher Handshake erfolgreich war, sodass der Beleg hinter is_vpn benannt und nachprüfbar ist.

GeoIPHub API
curl -H "x-api-key: YOUR_API_KEY" \ https://api.geoiphub.com/v1/lookup/102.129.235.17
GeoIPHub API
{ "ip": "102.129.235.17", "asn": { "asn": 834, "org": "IPXO - IPXO LLC", "asn_type": "vpn", "connection_type": "datacenter" }, "detection": { "is_vpn": true, "is_proxy": false, "is_tor": false, "is_anonymous": true, "vpn_provider": "none", "vpn_confidence": 100 }, "scoring": { "fraud_score": 92, "recommended_action": "block", "detection_methods": ["known_vpn_server", "openvpn_open", "ipsec_open"] } }

Hier halten openvpn_open und ipsec_open in detection_methods fest, dass diese Adresse auf OpenVPN- und IPsec-Probes geantwortet hat, zusätzlich zu einem Treffer in bekannten VPN-Serverdaten. vpn_provider ist hier "none", es wird also keine Marke zugeordnet; das Urteil stützt sich auf benannte Protokollbelege statt auf ein Anbieterlabel.

Aktives Probing hat einen Preis: Es kostet Infrastruktur und Zeit, weshalb es fortlaufend im Hintergrund läuft und nicht pro Anfrage. Die Probe-Ergebnisse werden zwischengespeichert und aktualisiert, damit die API in Millisekunden antworten kann.

Port- und Dienst-Fingerprints

Selbst wenn kein vollständiger Handshake möglich ist, verrät die Form der offenen Dienste einer IP viel. Ein Privatanschluss zeigt typischerweise gar nichts. Ein VPN-Endpunkt zeigt eine kleine, charakteristische Menge an Ports. Eine Proxy-Farm zeigt Verwaltungsoberflächen, SSH und Proxy-Ports über ganze Subnetze hinweg.

Dienst-Fingerprinting erfasst auch falsch konfigurierte oder markenlose Anonymisierer: Ein Server, der auf TCP 1080 mit einem SOCKS-Banner antwortet, ist ein Proxy, egal ob eine Liste das sagt oder nicht.

Latenz und Standortkonsistenz

Geografie hinterlässt physikalische Spuren. Wenn eine IP (laut Registrierungsdaten) in São Paulo sein will, ihre Round-Trip-Zeiten von weltweiten Messpunkten aber auf Amsterdam triangulieren, leitet etwas den Datenverkehr weiter. Latenzbasierte Prüfungen sind besonders nützlich gegen:

  • VPN-Server mit gefälschtem Standort: Anbieter vermarkten „Brasilien“-Server, die physisch in Miami stehen.
  • GRE-/Tunnel-Relays, die Datenverkehr an einen verborgenen tatsächlichen Standort weiterleiten.

Diese Ebene schlägt selten allein an, ist aber in Kombination mit Hosting-Signalen eine starke Bestätigung.

Verhalten von Residential Proxys

Residential Proxys sind die schwierigste Klasse, weil die Exit-IP tatsächlich einem Privatkunden-ISP gehört. Listenprüfungen bestehen. ASN-Prüfungen bestehen. Probing findet nichts, was lauscht, denn der „Server“ ist ein SDK, das in der kostenlosen Mobil-App von irgendjemandem steckt.

Die Erkennung verlagert sich deshalb von der Infrastruktur auf das Verhalten über die Zeit:

  • Dieselbe Privatkunden-IP erscheint als Exit auf bekannten Proxy-Marktplätzen.
  • Unwahrscheinliche Sitzungsvielfalt: Eine einzelne Haushalts-IP präsentiert Dutzende Geräte-Fingerprints pro Stunde.
  • Wechselmuster, die eher zur Rotation eines Proxy-Netzwerks passen als zur DHCP-Erneuerung.
  • Widerspruch beim ISP-Typ: IPs von Mobilfunkanbietern erzeugen dauerhaft Anfragevolumen wie aus dem Rechenzentrum (der Leitfaden zum Erkennen mobiler Proxys erklärt, warum Mobilfunk-IPs ein Sonderfall sind).

Deshalb bekommen Residential Exits ein eigenes Feld neben is_proxy: Die Beweisklasse ist eine andere, und damit auch die angemessene Reaktion. Seien Sie sich im Klaren darüber, was eine IP-Abfrage hier sehen kann. GeoIPHubs is_residential_proxy ist eine grobe, ASN-basierte Schlussfolgerung und keine direkte Beobachtung der Zugehörigkeit zu einem Proxy-Netzwerk; behandeln Sie es also als Hinweis und nicht als Beweis. Wenn Datenverkehr von Privatkunden-ISPs in Ihren Logs plötzlich verdächtig aussieht, erklärt warum Residential Proxys immer wieder in Ihrem Datenverkehr auftauchen die üblichen Ursachen. Ein Residential-Proxy-Treffer in einem Checkout-Flow ist ein deutlich stärkeres Betrugssignal als ein Treffer auf ein Consumer-VPN.

Tor-Verzeichnisdaten

Tor ist der einfache Fall, und zwar mit Absicht. Das Tor-Netzwerk veröffentlicht seinen Konsens über Relays und Exit-Nodes und aktualisiert ihn fortlaufend. Der Abgleich mit der öffentlichen Exit-Liste liefert eine nahezu perfekte is_tor-Genauigkeit mit einer Einschränkung: dem Timing. Exit-Nodes kommen und gehen, daher muss das Verzeichnis in kurzen Abständen neu eingelesen werden, nicht wöchentlich.

Datenschutz-Relays sind der umgekehrte Fall. Apple veröffentlicht jede Egress-Adresse von iCloud Private Relay, sodass sich auch ein solches Relay exakt zuordnen lässt; für sich allein gehört ein Relay aber in allow und nicht auf eine Sperrliste. Beide Relays, und warum Cloudflare keine WARP-Egress-Liste veröffentlicht, behandeln wir in Erkennung von iCloud Private Relay und Cloudflare WARP.

Signalübergreifende Konfidenz

Die letzte Ebene ist die Zusammenführung. Jede vorherige Ebene liefert Belege mit einem anderen Zuverlässigkeitsprofil:

SignalebeneErfasstKonfidenz, wenn sie anschlägtBlinder Fleck
AnbieterlistenKommerzielle VPNsSehr hoch (zugeordnet)Private VPNs
ASN / HostingAnonymisierer im RechenzentrumMittel (A-priori-Annahme, kein Beweis)Residential Exits
Aktives ProbingLaufende VPN-/Proxy-DiensteSehr hoch (verifiziert)SDK-basierte Proxys
Port-FingerprintsMarkenlose ProxysHochDurch Firewall geschützte Endpunkte
LatenzprüfungenRelays mit gefälschtem StandortMittelNahe gelegene Relays
VerhaltensmodelleResidential ProxysMittel bis hochBrandneue IPs
Tor-VerzeichnisExit-NodesNahezu sicherBridges

Ein belastbares Urteil gewichtet diese gemeinsam. Ein einzelnes Signal mittlerer Konfidenz sollte keinen Booleschen Wert umschalten; zwei unabhängige Signale hoher Konfidenz sollten es. Von einer Erkennungs-API wollen Sie deshalb drei Dinge: die Booleschen Werte für Routing-Entscheidungen, die benannten Erkennungsmethoden für die Nachprüfbarkeit und einen Risikoscore, der ausdrückt, wie stark sich die Signale gegenseitig bestätigen. Die benannten Methoden sind auch das, was ein fälschlich markierter Nutzer braucht: Unsere Anleitung dazu, warum eine IP als VPN oder Proxy markiert wird, liest sie an echten Adressen aus.

VPN-Erkennung in der Praxis: nach Kombinationen routen

Drei praktische Erkenntnisse:

  1. Behandeln Sie is_vpn nicht für sich allein als Sperrliste. Viele zahlende Kunden nutzen Consumer-VPNs (siehe wie Sie anonymisierten Datenverkehr markieren, ohne echte Kunden abzuweisen). Routen Sie nach Kombinationen: VPN + Rechenzentrum + Missbrauchshistorie ist eine ganz andere Lage als VPN allein.
  2. Gewichten Sie Residential-Proxy-Signale stark, im Wissen, dass sie erschlossen sind. Niemand mietet Residential Exits aus Datenschutzgründen; der Anteil legitimer Nutzung ist im Vergleich zu VPNs winzig. Ein Residential-Flag auf IP-Ebene ist allerdings eine grobe Schlussfolgerung, kombinieren Sie es also mit Ihren eigenen Sitzungssignalen.
  3. Bevorzugen Sie verifizierte Erkennung gegenüber statischen Listen. Fragen Sie jeden Anbieter, woher er weiß, dass eine IP ein VPN ist. Lautet die Antwort „eine Datenbank, die wir lizenzieren“, veralten die Daten bereits. Aktives Probing und fortlaufend gecrawlte Anbieterlisten halten mit dem Wandel der Infrastruktur Schritt.

Sie können die Ausgabe jeder Ebene selbst sehen: Prüfen Sie eine beliebige IP mit dem kostenlosen IP-Lookup-Tool oder testen Sie Ihre eigene VPN-Verbindung, ganz ohne Registrierung.

Häufig gestellte Fragen

Kann VPN-Erkennung jemals zu 100 % genau sein?

Nein. Erkennung ist probabilistisch. Kommerzielle VPNs mit veröffentlichter Infrastruktur werden mit sehr hoher Sicherheit erkannt, kleine private VPNs auf frischen Cloud-IPs sind schwieriger. Deshalb liefern gute APIs pro Signal die Belege und ein Konfidenzniveau statt eines bloßen Booleschen Werts.

Was ist auf Erkennungsebene der Unterschied zwischen einem Proxy und einem VPN?

Ein VPN tunnelt den gesamten Datenverkehr auf der Netzwerkschicht und beantwortet auf seinem Server in der Regel bestimmte Protokoll-Handshakes (OpenVPN, WireGuard, IKEv2). Ein Proxy leitet Datenverkehr auf Anwendungsebene weiter (HTTP, SOCKS) und zeigt andere Ports und Fingerprints. Erkennungssysteme prüfen beide Familien getrennt.

Warum sind Residential Proxys so schwer zu erkennen?

Weil die Exit-IP tatsächlich einem Privatkunden-ISP gehört, bestehen listen- und ASN-basierte Prüfungen. Die Erkennung stützt sich stattdessen auf Verhaltensbelege: dieselbe IP taucht in Proxy-Netzwerken auf, es gibt auffällige Wiederverwendungsmuster und Widersprüche zwischen ISP-Typ und beobachtetem Datenverkehr.

Ist es für die Betrugsprävention sinnvoll, jeden VPN-Nutzer zu blockieren?

Meist nicht. Viele legitime Nutzer surfen aus Datenschutzgründen über VPNs. Besser ist es, VPN-Nutzung als einen gewichteten Eingangswert eines Risikoscores zu behandeln und nur dann zu eskalieren, wenn sie zusammen mit anderen Signalen auftritt, etwa Rechenzentrums-Hosting, Missbrauchshistorie oder unmöglichen Reisen.

Wie aktuell müssen VPN-Erkennungsdaten sein?

Sehr aktuell. VPN-Anbieter tauschen täglich Server aus, und Proxy-Netzwerke wechseln IPs im Stundentakt. Erkennung, die auf kontinuierlichem erneutem Probing und neu gecrawlten Anbieterlisten beruht, bleibt genau; statische Datensätze veralten innerhalb von Wochen.

Verfasst von

GeoIPHub-Team

Das Team hinter der GeoIPHub-API

Verfasst vom GeoIPHub-Team, den Menschen, die die GeoIPHub-API für IP-Intelligence und ihren Scanner entwickeln. Entwürfe entstehen mit KI-Unterstützung und werden vom Team redigiert; API-Beispiele sind echte Abfragen gegen die Live-API, sofern nicht als illustrativ gekennzeichnet.

Artikel teilen
Weitere Artikel

Verwandte Beiträge