VPN-markering op het apparaat of exitadres: welke bewijst wat?
Een op het apparaat gelezen netwerkmarkering en een door een server waargenomen adres zijn verschillende bewijzen. Bepaal welke uw vraag nodig heeft.
De telefoonapp en de externe server beginnen met verschillende feiten, en geen van beide kan die van de ander lenen. De app kan het besturingssysteem vragen naar het netwerk dat hij gebruikt, terwijl de server alleen weet wat er over de verbinding binnenkomt. Je eigen eindpunt draaien herschrijft het tweede en laat het eerste ongemoeid. Welke van de twee uw vraag beantwoordt, hangt van de vraag zelf af.
Twee observatiepunten, twee soorten bewijs
Lokaal bewijs beschrijft het apparaat. Het omvat de interface die verkeer draagt, het transport dat het platform meldt, en wat de aanroepende app mag opvragen. Extern bewijs beschrijft de verbinding: bronadres, protocol, timing en alles wat de app besluit te versturen. Geen observatiepunt is een superset van het andere.
De twee mengen levert beweringen op die exact klinken en niet te controleren zijn. Een markering bewijst iets over een netwerkobject op het apparaat, niet over hoe een externe dienst het verzoek classificeert.
Schrijf voordat u over detectie discussieert op welk punt de vraag betrekking heeft. Gaat het erom of een bepaalde app kan zien dat een tunnel actief is, of of een dienst kan afleiden waar het verzoek vandaan kwam? Dat zijn afzonderlijke onderzoeken, en een antwoord op het ene zegt niets over het andere.
Wat een lokale platforminterface kan melden
Android biedt een specifieke markering. Het object NetworkCapabilities kan TRANSPORT_VPN melden, en hasTransport test of dat transport aanwezig is op het object. De app haalt het object bij de connectiviteitsdienst en leest het, onder voorbehoud van netwerkstatusmachtiging.
Het resultaat is lokale platforminformatie, geen opzoeking in de adresbereiken van een provider. Het beschrijft het netwerk dat de aanroepende app gebruikt.
Twee grenzen zijn belangrijk. Een split-tunnelregel die een app uitsluit, kan op dezelfde telefoon een ander antwoord geven dan een collega ziet, omdat de app elders gebonden kan zijn. De markering bestaat ook omdat het besturingssysteem VPN-interfaces modelleert, niet omdat een bepaalde app hem verzamelt. Of een app het veld leest, doorstuurt of negeert, is een eigenschap van die app. Het manifest en de documentatie zijn de enige betrouwbare bronnen voor die vraag.
adb shell dumpsys connectivity | grep -i -m5 vpnWat een externe dienst kan zien
Een server ziet het bronadres van de verbinding, het transport en de timing, en kan het adres verrijken met register- of routeringsgegevens. Hij kan ook alles ontvangen wat de app stuurt, inclusief locatie wanneer de app daarom vraagt en de gebruiker instemt. Die kanalen zijn gescheiden, en slechts één lijkt op een adresopzoeking.
Een adres dat bij een hostingprovider is geregistreerd, suggereert een tunnel, terwijl een adres dat op een woonnetwerk is geregistreerd, een thuisverbinding suggereert. Beide zijn statistische aanwijzingen, geen feiten over het apparaat.
Een woonadres plaatst de persoon niet op dat adres, en een hostingadres noemt niet de operator of het land. Een dienst die de gevolgtrekking als zekerheid behandelt, zal zich soms vergissen zonder dat te kunnen vaststellen. Als de eis betrouwbaarheid is en niet een heuristiek, kunnen adresgegevens die niet leveren, en een ontwerp dat dat zegt is eerlijker dan een dat de gok verbergt.
| Bewijs | Waar het antwoord op geeft | Wat het niet kan tonen |
|---|---|---|
| Lokale transportmarkering | Of dit netwerkobject een VPN is | Wie de exit beheert of waar het apparaat is |
| Extern bronadres | Welk adres de dienst bereikte | Of het apparaat ook een tunnel draagt |
| Applicatielading | Wat de app koos te versturen | Alles wat de app niet verstuurde |
Waarom een zelfgehoste exit maar één kant verandert
Je eigen eindpunt draaien verandert het bronadres dat een externe dienst ziet, wat het buiten de bereiken kan schuiven die die dienst met commerciële providers associeert. Het verandert niets in het lokale netwerkmodel, omdat de tunnel een tunnel blijft en het besturingssysteem hem nog steeds meldt.
De ene kant van het bewijs beweegt, de andere blijft vast. De kloof daartussen is waar verwachtingen breken.
Een browser is een derde geval met eigen interfaces en beperkingen. Webinhoud kan geen native capaciteitenobject lezen, en een functie van een mobiel besturingssysteem behandelen als beschikbaar voor een webpagina is een categoriefout. Als de vraag over een website gaat, onderzoek dan wat een website werkelijk kan verkrijgen in plaats van een platform-API te translitereren.
Beslis met de vraag die u stelt
Als de vraag is of een bepaalde app de tunnelstatus kan observeren, is de platforminterface de juiste plek om te kijken, en het antwoord ligt in de code en machtigingen van die app. Als de vraag is wat een dienst kan afleiden, zijn verbindingsmetadata het bewijs. Een juridische of contractuele vraag wordt door geen van beide beslecht.
Benoem de vraag in één zin voordat u iets verzamelt. Die zin bepaalt welk observatiepunt telt en houdt het onderzoek ervan af om naar een ander debat af te drijven.
Label elke observatie naar herkomst wanneer u erover rapporteert, want een ongelabelde bewering kan niet worden herzien. Een lokale markering en een adresafleiding zijn beide nuttig en geen van beide is beslissend, daarom is het een fout ze tot één oordeel te versmelten.
Wanneer een dienst een geautoriseerde verbinding weigert, gebruik dan zijn ondersteunde herzieningsroute in plaats van een lokale instelling te wijzigen om een signaal te verbergen. Het verwijderen van één observatie bewijst nooit dat de andere zijn verdwenen.