Hva et offentlig VPN-vertsnavn kan og ikke kan bevise

Vertsnavn og nasjonalflagg ser ut som fakta om en server, og ingen av delene er det. Et navn peker på adresser som kan endre seg, og ordene i det ble valgt av den som registrerte det. Protokoll, utgangsplassering og loggføringsatferd trenger hver sitt eget bevis. Begynn med det navnet faktisk løser til, og avgjør deretter hva som fortsatt er ukjent.

Navnet løser, og ingenting annet er avgjort

Et vertsnavn er en peker i DNS, og oppføringene bak det kan variere etter resolver, etter tid på dagen og etter adressefamilien klienten foretrekker. To personer som leser samme katalogoppføring, kan helt legitimt nå ulike maskiner. Navnet forteller hva du skal spørre om, ikke hva som vil svare.

Også oppslagsresultater endrer seg uten varsel, noe som betyr noe når en profil låser en adresse i stedet for navnet. En profil som har den gamle adressen hardkodet, fortsetter å feile etter at operatøren flytter tjenesten, og feilen ser ut som en blokkert port. Ta vare på de løste adressene ved siden av profilen, slik at en senere sammenligning har en basislinje. Ingenting av dette sier noe om hvem som driver den andre enden.

dig +short vpn.example.net A
dig +short vpn.example.net AAAA
dig +short vpn.example.net A @1.1.1.1

Transport og identitet er separate spørsmål

En åpen nettside på vertsnavnet tester én lytter på én port. OpenVPN, IPsec og SSTP lytter andre steder, på sine egne porter og protokoller, så en tilgjengelig webserver sier ingenting om dem.

Katalogoppføringen og profilen må være enige om transport, port og påloggingsinformasjon. Identitet verifiseres av sertifikatkjeden eller fingeravtrykket til motpartsnøkkelen klienten ble konfigurert med, ikke av stavemåten til vertsnavnet. Et navn med et kjent prosjektord beviser bare at noen registrerte det. Les sertifikatet tjenesten presenterer, og sammenlign utsteder og subjekt med det profilen forventer.

openssl s_client -connect vpn.example.net:443 -servername vpn.example.net </dev/null 2>/dev/null |
  openssl x509 -noout -subject -issuer -dates

Landsord er ikke en plasseringsrevisjon

En etikett som jp eller de i en katalog er en registrering, og IP-geolokasjonsdatabaser er uenige ofte nok til at ingen av dem bør behandles som absolutt sannhet. Delt hosting, anycast og enkel feilkonfigurering flytter alle den observerte plasseringen bort fra etiketten.

Den praktiske testen er applikasjonens egen vei: hvilken adresse den når, og hva en utgangsadressekontroll viser fra innsiden av økten. En observert utgangsadresse er en egenskap ved ruten i det øyeblikket, ikke en garanti knyttet til navnet. Frivillige kataloger legger til et nytt lag, fordi den som registrerte en oppføring, ikke trenger å være den som driver maskinen. Skriv ned hva du målte og når, i stedet for hva oppføringen lovet.

Kontroller tjenesten som tilbys, deretter operatøren

Når transport og identitet er avgjort, er det gjenværende spørsmålet operatørens atferd, og det krever dokumentasjon fremfor slutninger. En personvernerklæring, en publisert kontakt og et åpenhetsvarsel er bevis på intensjon; ingen av dem beviser praksis, og fraværet av alle tre er også informasjon.

For en offentlig eller frivillig drevet node bør du anta at utgangen er delt, og at den som driver den, kan se hva som passerer. Den antakelsen, ikke vertsnavnet, bør avgjøre hva du sender gjennom tunnelen.

curl -sSI https://vpn.example.net/ | head -n 5
whois 203.0.113.25 | grep -i -E 'orgname|netname'

Behold navnet for det det er godt for: å finne et endepunkt og koble til det. Alt utover det må testes separat, på den dagen det betyr noe.