Überprüfung geoblockter Inhalte für Streaming und Compliance

Die meisten Streaming-Dienste und compliance-sensitiven Plattformen setzen Geo-Restriktionen bei 60–80 % der Residential-IPs nicht korrekt durch, so interne Audits bei drei großen CDNs. Die Ursache liegt nicht in schlechten IP-Datenbanken – sondern in einem Test-Workflow, der niemals die Grenzfälle durchspielt, die Geo-Fencing tatsächlich brechen. Entwickler, die Geo-Blocking als einfache IP-zu-Land-Abfrage behandeln, bauen ein Sieb, keine Barriere.

Warum naive IP-Abfragen im großen Maßstab scheitern

Der Standardansatz – Abfrage von MaxMind oder einer ähnlichen GeoIP-Datenbank nach der country_code – funktioniert für Rechenzentrums-IPs und große ISP-Blöcke. Er scheitert katastrophal bei Mobilfunk-IPs, die über ein zentrales Gateway in einem anderen Land geroutet werden, bei Satelliten-ISPs mit Bodenstationen in mehreren Jurisdiktionen und bei IPs, die vor der heutigen geopolitischen Grenzziehung vergeben wurden. RFC 8805 definiert ein Geolokalisierungs-Feed-Format, aber die meisten Anbieter liefern weiterhin veraltete oder aggregierte Daten. Eine Studie aus dem Jahr 2023 ergab, dass 34 % der IPs in der RIPE-NCC-Datenbank einen Ländercode hatten, der nicht mit der registrierten Adresse des Inhabers übereinstimmte. Das Testen gegen eine einzelne Datenbank ist kein Test – es ist Wunschdenken.

VPN- und Proxy-Erkennung: Der Umgehungsweg, den Sie nicht testen

Streaming-Dienste investieren stark in VPN-Blocklisten, aber diese Blocklisten sind nur so gut wie die Testumgebung, die sie validiert. Der häufige Fehler besteht darin, von einem bekannten VPN-Endpunkt (z. B. dem Exit-Node eines kommerziellen Anbieters) zu testen und es als erledigt zu betrachten. Echte Angreifer rotieren IPs alle 60 Sekunden, nutzen Residential-Proxy-Netzwerke oder tunneln durch die Egress-IP eines Cloud-Anbieters, die noch nicht markiert ist. Ein ordnungsgemäßer Verifikations-Workflow muss ein Skript enthalten, das eine Liste bekannter offener Proxys, VPN-Exit-Nodes und Tor-Relays aus öffentlichen Feeds abruft (z. B. https://check.torproject.org/exit-addresses), dann eine Anfrage an den geo-restringierten Endpunkt Ihres Dienstes sendet und den Antwortstatus prüft. Hier ist eine minimale Testschleife mit curl und jq:

#!/bin/bash
# Test geo-restricted endpoint against a list of suspicious IPs
ENDPOINT="https://api.example.com/geo/check"
while IFS= read -r ip; do
  result=$(curl -s -o /dev/null -w "%{http_code}" --resolve "api.example.com:443:$ip" "$ENDPOINT")
  if [[ "$result" != "403" ]]; then
    echo "FAIL: $ip returned $result (expected 403)"
  fi
done < /tmp/suspicious_ips.txt

Dieses Skript verwendet --resolve, um die Verbindung über eine bestimmte IP zu erzwingen, während der ursprüngliche Host-Header erhalten bleibt – eine Technik, die die meisten CDN-seitigen Geo-Prüfungen umgeht. Wenn Ihr Dienst für eine dieser IPs einen 200er oder 302er zurückgibt, ist Ihr Geo-Fencing defekt.

IPv6-Geolokalisierungslücken und Mobilfunk-IPs, die Ländergrenzen überspannen

Die Genauigkeit der IPv6-Geolokalisierung liegt in vielen Regionen unter 50 %, insbesondere in Europa und Asien, wo Betreiber ein einziges /32-Präfix für mehrere Länder verwenden. Ein Mobiltelefon in Straßburg, Frankreich, kann scheinbar aus dem Kernnetz eines deutschen Betreibers stammen, wenn der Betreiber einen einzigen Ankerpunkt verwendet. Der X-Forwarded-For-Header enthält oft die IPv4-Adresse des NAT-Gateways des Betreibers, nicht die IPv6-Adresse des Benutzers. Um dies zu testen, senden Sie Anfragen von einem Testgerät, das mit einem Mobilfunknetz in einer Grenzregion verbunden ist (z. B. Basel, Schweiz; El Paso, Texas), und vergleichen Sie das Geolokalisierungsergebnis Ihres Dienstes mit den tatsächlichen GPS-Koordinaten des Geräts. Wenn die Abweichung 100 km überschreitet, hat Ihr Compliance-Team ein Problem – die DSGVO verlangt, dass die Datenverarbeitung an den tatsächlichen Standort des Benutzers gebunden ist, nicht an den des Betreibers.

Regulatorische Compliance-Tests jenseits der IP-Prüfung

DSGVO und COPPA interessieren sich nicht für Ihren IP-Datenbank-Anbieter. Sie interessieren sich dafür, ob einem Benutzer in der EU EU-konforme Inhalte ausgeliefert werden und ob einem Benutzer unter 13 Jahren in den USA die Erhebung personenbezogener Daten untersagt wird. Das Testen von Geo-Restriktionen für Compliance bedeutet, dass Sie überprüfen müssen, ob sich die Antwort Ihres Dienstes – nicht nur der HTTP-Statuscode – basierend auf dem erkannten Standort korrekt ändert. Beispielsweise muss ein Streaming-Dienst, der verschiedene Kataloge pro Land ausliefert, sicherstellen, dass ein Benutzer im Vereinigten Königreich den UK-Katalog sieht, ein Benutzer in Frankreich den französischen Katalog und ein Benutzer in einem nicht lizenzierten Gebiet eine „nicht verfügbar“-Seite sieht. Der Test sollte die Überprüfung des Antwortkörpers auf regionsspezifische Zeichenfolgen, Cookies und Weiterleitungsziele umfassen. Ein einzelner curl mit --header "CF-IPCountry: GB" (falls Sie Cloudflare verwenden) ist ein schneller Smoke-Test, testet aber nur die CDN-Ebene, nicht Ihre Anwendungslogik. Bauen Sie eine Testsuite auf, die den X-Forwarded-For-Header mit IPs aus jedem Zielland fälscht, und parsen Sie dann die Antwort auf eine bekannte eindeutige Kennung (z. B. ein JSON-Feld "catalog": "uk").

Aufbau einer wiederholbaren QA-Pipeline

Hören Sie auf, Geo-Restriktionstests manuell durchzuführen. Integrieren Sie die Verifikation in Ihre CI/CD-Pipeline mit einem Tool wie geoiplookup aus dem geoip-bin-Paket, kombiniert mit einer Liste von IPs, von denen bekannt ist, dass sie in Ihrer primären Datenbank falsch lokalisiert sind. Führen Sie den Test jedes Mal aus, wenn Sie eine neue Geo-Fencing-Regel bereitstellen. Verwenden Sie einen Multi-Quellen-Ansatz: Fragen Sie MaxMind, IP2Location und eine kostenlose RIPE-NCC-API für jede Test-IP ab, und lassen Sie den Build fehlschlagen, wenn die Mehrheit der Quellen nicht mit der Antwort Ihres Dienstes übereinstimmt. Der folgende Befehl vergleicht die Entscheidung Ihres Dienstes mit drei Datenbanken:

#!/bin/bash
IP="1.2.3.4"
RESPONSE=$(curl -s "https://api.example.com/geo/check?ip=$IP" | jq -r '.country')
MAXMIND=$(geoiplookup "$IP" | awk '{print $4}')
IP2LOC=$(curl -s "https://api.ip2location.com/?ip=$IP&key=test" | jq -r '.country_code')
if [[ "$RESPONSE" != "$MAXMIND" && "$RESPONSE" != "$IP2LOC" ]]; then
  echo "WARNING: Geo response differs from majority of databases"
fi

Keine einzelne Datenbank ist autoritativ. Der einzige Weg, die Fehlerrate von 60–80 % zu erfassen, ist das Testen mit realen Grenzfällen: Mobilfunk-IPs, IPv6-Präfixe und Residential-Proxys. Alles andere ist ein Compliance-Vorfall, der nur darauf wartet, einzutreten.