Blokkerte nettstedet VPN-adressen din? Sjekk tillatelsen først

Et nettsted som svarer med et avslag etter en VPN-endring, har fortalt deg noe om en nettverksrute og ingenting om tillatelse til å bruke tjenesten. Disse to faktaene blandes stadig sammen, og feilen går i begge retninger. Tilgjengelighet er ikke autorisasjon, og en konto i god stand er ikke en lisens til å bruke hver funksjon. Avklar hvilken av de to som egentlig er spørsmålet, før du rører en rute, en DNS-innstilling eller en klientprofil.

Start med hva som faktisk ble gitt tilgang til

Tre fakta behandles rutinemessig som ett: kontoen finnes og er i god stand, kontoen kan bruke en bestemt funksjon eller endepunkt, og verten svarer på nettverket. Bare de to første er tillatelser, og de kan trekkes tilbake uavhengig. Et utløpt abonnement, en funksjon som aldri ble aktivert, og en API-nøkkel begrenset til et annet endepunkt gir alle feil som fra klientsiden ser ut som tilkoblingsproblemer.

Les varselet du fikk, før du leser noe annet. Suspensjoner, regionsbegrensninger, hastighetsbegrensninger og trafikkblokkeringer kommer med ulik ordlyd og har ulike botemidler, og bare én av dem er en samtale om tillatelser. Hold varselet, tidsstempelet og kontoidentifikatoren sammen, fordi en støtteforespørsel uten dem starter undersøkelsen på null.

Navngi begrensningen før du endrer ruten

Noter hva serveren faktisk returnerte, ikke hva nettleseren viste. En statuskode, den oppløste adressen og tidspunktet for forsøket er nok til å skille et avslag fra en begrensning, og det tar noen sekunder å fange dem.

curl -sS -o /dev/null -w '%{http_code} %{remote_ip}\n' https://app.example.com/login
dig +short app.example.com

En 403 på ett endepunkt mens resten av nettstedet virker, peker på en autorisasjonsregel snarere enn en nettverksblokkering. En 429 med et hint om å prøve igjen er en hastighetsbegrensning, og å bytte utgangsadresser for å omgå den er nettopp den atferden grensen finnes for å stoppe. Et avslag som følger hver forespørsel uansett adresse, peker igjen et annet sted, og ingen av disse repareres ved å legge til et hopp.

Hold vilkår og datamaskininnbruddsrett atskilt

Under ordet "tillatt" ligger to atskilte spørsmål. Det første er kontraktsmessig: hva tjenestens vilkår tillater, og hvilke botemidler de beskriver ved brudd. Å klikke seg gjennom en side eller fortsette å bruke et nettsted er ikke i seg selv en fullstendig juridisk vurdering av om en klausul binder noen, og det er heller ikke et teknisk faktum. Det andre spørsmålet er om atferd krysser en datamaskininnbruddsforbrytelse, som har sine egne elementer og sine egne myndigheter.

I USA dekker 18 USC 1030 tilgang uten autorisasjon og overskridelse av autorisert tilgang, med forbehold om ytterligere vilkår i paragrafen. Høyesteretts avgjørelse fra 2021 i Van Buren-saken innsnevret den andre formuleringen til å skaffe informasjon fra områder av en datamaskin som en person ikke har rett til å nå, snarere enn til feil bruk av informasjon som personen hadde rett til å skaffe. Den uttalelsen lot det også stå åpent, i en fotnote, om grensene som definerer slike områder må være teknologiske og ikke kontraktsmessige.

Det som følger av dette, er beskjedent og praktisk. En uenighet om et nettsteds policy er ikke automatisk en forbrytelse, og spørsmålet om forbrytelse avgjøres heller ikke av en endring på klientsiden. Ingenting i den argumentasjonen tillater å unndra seg en suspensjon eller å beseire en teknisk kontroll, og én jurisdiksjons rettspraksis besvarer ikke spørsmålet for hver tjeneste eller land.

Be om en støttet rute i stedet for en annen rute

Når tilgang betyr noe, er det produktive trekket å spørre tjenesten hvilken rute den støtter: gjenopprettet kontotilgang, et tillatt adresseområde for en bedriftsutgang, en API-rettighet eller en dokumentert unntaksprosess. Arbeidskontoer bør gå gjennom administratoren som eier relasjonen, fordi nettstedets krav og organisasjonens utgangspolicy begge må oppfylles samtidig.

Et godkjent unntak trenger også en eier og en utløpsdato. Ellers blir en midlertidig tillatelseslisteoppføring den permanente arkitekturen, og neste gjennomgang kan ikke se om den noen gang ble gitt.

Skriv ned svaret før du handler

Skriv ned hva som endret seg, hvem som godkjente det, og hva tjenesten sa, og kjør deretter den samme forespørselen du fanget i starten, på nytt. En vellykket forespørsel etter en godkjent endring er en annen hendelse enn en vellykket forespørsel etter en omvei, og bare den første har en registrering bak seg.

Hvis tjenesten avslår og saken er vesentlig, søk råd med dokumentene som allerede er samlet inn, i stedet for å eksperimentere videre. Å kunne nå en vert er en uttalelse om ruting. Tillatelsen til å bruke ressursen gis av tjenesten eller gjeldende regler, og ingen mengde ruteingeniørkunst leverer den.