Hetzelfde IP-adres kan bij verschillende controletools tegengestelde conclusies krijgen. Dit artikel legt uit hoe databasedekking en updatefrequentie verschillen veroorzaken, hoe je meerdere bronnen kruiselings controleert en wat je onderzoekt wanneer tests normaal lijken maar het echte gebruik toch problemen geeft.
Je koopt een proxy, rondt de configuratie af, de verbinding wordt als geslaagd weergegeven en toch ontstaan er problemen met het account. De eerste reactie van veel mensen is één keer het IP-adres controleren. Als de locatie klopt en er geen proxylabel staat, wordt al snel aangenomen dat de omgeving in orde is en zoekt men de oorzaak ergens anders.
Het probleem is dat één enkele query maar weinig kan beantwoorden en dat zelfs die conclusie niet per se betrouwbaar is.
Hetzelfde IP-adres, verschillende antwoorden van verschillende tools
Tools die als IP-controletool worden gebruikt, beantwoorden in werkelijkheid vaak verschillende vragen.
Eén categorie controleert geolocatie en toewijzing en toont land, stad, provider, ASN en tijdzone. Een andere controleert proxykenmerken en risico en beoordeelt of het om een residentieel of datacenter-IP gaat, of er proxykenmerken zijn en welke fraudescore wordt toegekend. Een derde categorie zoekt naar lekken en controleert of WebRTC of DNS het echte IP-adres blootlegt. Deze drie soorten informatie zijn niet onderling vervangbaar: een IP-adres kan op de juiste locatie staan en geen proxylabel hebben, terwijl de browser het echte IP toch via WebRTC lekt. Een geolocatietool zal dat nooit melden.
Zelfs tools binnen dezelfde categorie komen vaak niet overeen. Daar zijn meerdere redenen voor: ze gebruiken andere gegevensbronnen, zoals registratiegegevens van providers, actieve metingen en honeypotnetwerken of meldingen van gebruikers; hun dekking verschilt, zodat de ene database een IP kent en de andere niet; de updatefrequentie verschilt, waardoor een achterlopende database na een wijziging nog de oude eigenaar kan tonen; en ook de beoordelingsdrempels verschillen, omdat elke aanbieder zelf bepaalt hoeveel verdenking als hoog risico geldt.
Door al die verschillen kan één tool een IP rood markeren en een andere groen. Trek daarom niet te snel een conclusie. Zie tools als verschillende informatiebronnen, niet als verschillende scheidsrechters.
Zo voer je kruisvalidatie uit
De eerste laag is vergelijking van meerdere bronnen. Controleer hetzelfde IP-adres met minstens twee tools die verschillende dekkingslogica gebruiken. Het doel is niet vaststellen welke tool gelijk heeft, maar zien waar het verschil zit. Grote afwijkingen in geolocatie wijzen op onbetrouwbare toewijzingsgegevens; grote afwijkingen in risicobeoordeling wijzen erop dat het IP zelf in een grijs gebied zit en voorzichtiger moet worden behandeld.
De tweede laag is toewijzings- en providerinformatie samen bekijken. Alleen een juiste stad is niet genoeg; kijk ook naar wie het ASN bezit. Een ASN van een residentiële provider en een ASN van een cloudprovider zijn voor een platform twee heel verschillende zaken: de eerste lijkt op een echte gebruiker, de tweede op een server. Als een IP de doelstad toont maar het ASN naar een datacenter verwijst, maakt de juiste locatie het IP niet betrouwbaarder.
De derde laag is het gedrag in de praktijk. Het land waaraan een IP is toegewezen en de vraag of je gebruik daarmee logisch overeenkomt, zijn twee verschillende zaken. Een IP kan de Verenigde Staten tonen terwijl de browser een Aziatische tijdzone gebruikt, de interface Chinees is en de inhoudsvoorkeuren ook niet passen. Zulke tegenstrijdigheden zijn vaak makkelijker te herkennen dan het IP zelf. Tijdzone, taal, valutaweergave en gebruikelijke zoekgewoonten moeten als geheel bij de IP-locatie passen. Deze laag kun je niet met een databasequery controleren; je moet het doelplatform daadwerkelijk bezoeken en in de praktijk testen.
Alle controles slagen, maar het account heeft nog steeds problemen
Bij verdere diagnose is de volgorde belangrijker dan de tool.
Controleer eerst of de proxy echt actief is. Doe dit onafhankelijk en kijk specifiek naar de twee lekpunten WebRTC en DNS; die staan los van de vraag of het IP zelf schoon is. Veel IP-adressen die schoon lijken, hebben hier juist een probleem.
Controleer daarna of apparaatidentiteit en netwerkidentiteit bij elkaar passen. Als parameters zoals IP, tijdzone, taal en resolutie elkaar tegenspreken, geven algemene controletools meestal geen fout, maar het risicosysteem van het platform kan de inconsistentie wel als afwijkend signaal registreren.
Kijk vervolgens naar signalen aan de accountkant. Test een kleine groep configuraties op het doelplatform en let op een hogere CAPTCHA-frequentie, meldingen over ongebruikelijke aanmeldingen of een daling in bereik en aanbevelingen. Zulke veranderingen verschijnen vaak voordat formele beperkingen of blokkeringen optreden. Een algemene controle doorstaan betekent niet dat het platform de omgeving accepteert; deze stap mag dus niet worden overgeslagen.
Bekijk tot slot opnieuw de toestand van het IP zelf. IP-reputatie verandert: een adres dat vandaag schoon is, hoeft dat volgende week niet te zijn. Gedeelde IP-adressen zijn hier extra gevoelig voor, omdat gedrag van een vorige gebruiker het adres op een grijze lijst kan brengen; ook residentiële IP-adressen kunnen ten onrechte worden gemarkeerd. Als testresultaten en werkelijk gedrag niet overeenkomen, is dit een richting die opnieuw moet worden onderzocht.
In scenario's met een hoog risico is een vast hertestschema nodig in plaats van alleen controleren wanneer er al een probleem is. Noteer bij elke test de belangrijkste waarden, zodat je bij een storing een basislijn hebt om mee te vergelijken. Anders kun je alleen op gevoel beoordelen of het slechter is geworden of altijd al zo was.
De laag buiten de IP-controle
Zelfs met een schoon IP en zonder lekken kan een account problemen krijgen, omdat risicocontroles naar de totale consistentie kijken. Netwerkidentiteit, apparaatidentiteit en accountidentiteit verhouden zich zo tot elkaar: de eerste twee moeten intern consistent zijn en accounts moeten onafhankelijk van elkaar blijven.
Een mismatch in één van de drie kan al een afwijkend signaal veroorzaken. Op het niveau van apparaatidentiteit is het gebruikelijk om voor elk account een aparte browseromgeving te configureren en IP, tijdzone en taal als één geheel op elkaar af te stemmen, zodat netwerk- en apparaatlaag overeenkomen. PurpleMark biedt omgevingsisolatie op deze laag; elke omgeving draait onafhankelijk en de parameters kunnen worden ingesteld op basis van de IP-locatie.
Geen enkele tool kan volledig en altijd nauwkeurig zijn; het herkennen van hoogwaardige residentiële proxies is op zichzelf al moeilijk. Een werkbare aanpak is een vaste combinatie van tools te gebruiken, periodiek opnieuw te testen, de resultaten vast te leggen en het uiteindelijke oordeel te combineren met kleinschalige praktijktests op het echte platform.
Dit is alleen een uitleg van technische methoden en soorten tools en vormt geen aanbeveling voor een tool of dienst.
