De meeste streamingdiensten en compliance-gevoelige platforms slagen er niet in om geo-restricties correct af te dwingen op 60-80% van de residentiële IP's, volgens interne audits bij drie grote CDN's. De oorzaak ligt niet bij slechte IP-databases – het is een testworkflow die nooit de edge cases oefent die geo-fencing daadwerkelijk breken. Ingenieurs die geo-blokkering behandelen als een simpele IP-naar-land lookup bouwen een zeef, geen barrière.
Waarom naïeve IP-lookups op schaal falen
De standaardaanpak – het opvragen van MaxMind of een vergelijkbare GeoIP-database voor de country_code – werkt voor datacenter-IP's en grote ISP-blokken. Het faalt catastrofaal voor mobiele carrier-IP's die via een centrale gateway in een ander land routeren, voor satelliet-ISP's met grondstations in meerdere rechtsgebieden, en voor elk IP dat is toegewezen vóór de huidige geopolitieke grenzen werden getrokken. RFC 8805 definieert een geolocatie-feedformaat, maar de meeste aanbieders leveren nog steeds verouderde of geaggregeerde gegevens. Een onderzoek uit 2023 wees uit dat 34% van de IP's in de RIPE NCC-database een landcode had die niet overeenkwam met het geregistreerde adres van de houder. Testen tegen één enkele database is geen testen – het is wensdenken.
VPN- en proxy-detectie: de omzeiling die u niet test
Streamingdiensten investeren zwaar in VPN-blokkeerlijsten, maar die blokkeerlijsten zijn slechts zo goed als de testomgeving die ze valideert. De veelgemaakte fout is om te testen vanaf een bekend VPN-eindpunt (bijv. een exitnode van een commerciële aanbieder) en het daarbij te laten. Echte aanvallers roteren IP's elke 60 seconden, gebruiken residentiële proxy-netwerken of tunnelen via een egress-IP van een cloudprovider dat nog niet is gemarkeerd. Een goede verificatieworkflow moet een script bevatten dat een lijst met bekende open proxy's, VPN-exitnodes en Tor-relays uit openbare feeds haalt (bijv. https://check.torproject.org/exit-addresses), vervolgens een verzoek naar het geo-beperkte eindpunt van uw dienst stuurt en de responsstatus controleert. Hier is een minimale testlus met curl en 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.txtDit script gebruikt --resolve om de verbinding via een specifiek IP te forceren terwijl de oorspronkelijke host-header behouden blijft – een techniek die de meeste geo-controles op CDN-niveau omzeilt. Als uw dienst een 200 of 302 retourneert voor een van die IP's, is uw geo-fencing kapot.
IPv6-geolocatiehiaten en mobiele carrier-IP's die landsgrenzen overspannen
De nauwkeurigheid van IPv6-geolocatie ligt voor veel regio's onder de 50%, vooral in Europa en Azië waar carriers een enkel /32-prefix voor meerdere landen gebruiken. Een mobiele telefoon in Straatsburg, Frankrijk, kan lijken afkomstig te zijn van het kernnetwerk van een Duitse carrier als de operator één enkel ankerpunt gebruikt. De X-Forwarded-For-header bevat vaak het IPv4-adres van de NAT-gateway van de carrier, niet het IPv6-adres van de gebruiker. Om dit te testen, stuurt u verzoeken vanaf een testapparaat dat is verbonden met een mobiel netwerk in een grensregio (bijv. Bazel, Zwitserland; El Paso, Texas) en vergelijkt u het geolocatieresultaat van uw dienst met de werkelijke GPS-coördinaten van het apparaat. Als de afwijking groter is dan 100 km, heeft uw complianceteam een probleem – de AVG vereist dat gegevensverwerking wordt gekoppeld aan de werkelijke locatie van de gebruiker, niet aan die van de carrier.
Testen van wettelijke naleving voorbij de IP-check
De AVG en COPPA geven niets om uw IP-databaseleverancier. Ze geven erom of een gebruiker in de EU EU-conforme content krijgt en of een gebruiker onder de 13 in de VS wordt geblokkeerd om persoonlijke gegevens te verzamelen. Het testen van geo-restricties voor compliance betekent dat u moet verifiëren dat de respons van uw dienst – niet alleen de HTTP-statuscode – correct verandert op basis van de gedetecteerde locatie. Een streamingdienst die bijvoorbeeld per land verschillende catalogi aanbiedt, moet ervoor zorgen dat een gebruiker in het VK de VK-catalogus ziet, een gebruiker in Frankrijk de Franse catalogus, en een gebruiker in een niet-gelicentieerd gebied een 'niet beschikbaar'-pagina ziet. De test moet het controleren van de responsbody op regiospecifieke strings, cookies en redirect-doelen omvatten. Een enkele curl met --header "CF-IPCountry: GB" (als u Cloudflare gebruikt) is een snelle smoke test, maar test alleen de CDN-laag, niet uw applicatielogica. Bouw een testsuite die de X-Forwarded-For-header vervalst met IP's uit elk doelland en parseer vervolgens de respons op een bekende unieke identificatie (bijv. een JSON-veld "catalog": "uk").
Een herhaalbare QA-pijplijn opzetten
Stop met het handmatig uitvoeren van geo-restrictietests. Integreer de verificatie in uw CI/CD-pijplijn met een tool zoals geoiplookup uit het geoip-bin-pakket, gecombineerd met een lijst met IP's waarvan bekend is dat ze in uw primaire database verkeerd zijn gelokaliseerd. Voer de test uit elke keer dat u een nieuwe geo-fencingregel implementeert. Gebruik een multi-source aanpak: raadpleeg MaxMind, IP2Location en een gratis RIPE NCC API voor elk test-IP, en laat de build mislukken als de meerderheid van de bronnen het oneens is met de respons van uw dienst. De onderstaande opdracht vergelijkt de beslissing van uw dienst met drie databases:
#!/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"
fiGeen enkele database is gezaghebbend. De enige manier om de 60-80% foutmarge te vangen, is door te testen met realistische edge cases: mobiele carrier-IP's, IPv6-prefixen en residentiële proxy's. Alles minder is een compliance-incident dat staat te gebeuren.