Värdnamn och nationsflaggor ser ut som fakta om en server, och ingen av dem är det. Ett namn pekar på adresser som kan ändras, och orden i det valdes av den som registrerade det. Protokoll, utplaceringsplats och loggningsbeteende behöver var sitt eget bevis. Börja med vad namnet faktiskt löser upp till, och avgör sedan vad som fortfarande är okänt.

Namnet löser upp, och inget annat är avgjort

Ett värdnamn är en pekare i DNS, och posterna bakom det kan variera efter resolver, efter tid på dagen och efter den adressfamilj klienten föredrar. Två personer som läser samma katalogpost kan helt legitimt nå olika maskiner. Namnet säger vad du ska fråga om, inte vad som kommer att svara.

Även sökresultat ändras utan förvarning, vilket spelar roll när en profil låser en adress i stället för namnet. En profil med den gamla adressen hårdkodad fortsätter att misslyckas efter att operatören flyttat tjänsten, och felet ser ut som en blockerad port. Spara de upplösta adresserna bredvid profilen så att en senare jämförelse har en baslinje. Inget av detta säger något om vem som driver den andra änden.

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

Transport och identitet är separata frågor

En öppen webbsida på värdnamnet testar en lyssnare på en port. OpenVPN, IPsec och SSTP lyssnar någon annanstans, på sina egna portar och protokoll, så en nåbar webbserver säger inget om dem.

Katalogposten och profilen måste vara överens om transport, port och inloggningsuppgifter. Identitet verifieras av certifikatkedjan eller fingeravtrycket för motpartens nyckel som klienten konfigurerades med, inte av värdnamnets stavning. Ett namn med ett känt projektord bevisar bara att någon registrerade det. Läs certifikatet som tjänsten presenterar och jämför utgivare och subjekt med det profilen förväntar sig.

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

Landsord är inte en platsrevision

En etikett som jp eller de i en katalog är en registrering, och IP-geolokaliseringsdatabaser är oense tillräckligt ofta för att ingen av dem bör behandlas som absolut sanning. Delad hosting, anycast och enkel felkonfiguration flyttar alla den observerade platsen bort från etiketten.

Det praktiska testet är applikationens egen väg: vilken adress den når, och vad en utgångsadresskontroll visar inifrån sessionen. En observerad utgångsadress är en egenskap hos rutten i det ögonblicket, inte en garanti knuten till namnet. Frivilligkataloger lägger till ytterligare ett lager, eftersom den som registrerade en post inte behöver vara den som driver maskinen. Skriv ner vad du mätte och när, i stället för vad posten lovade.

Kontrollera den erbjudna tjänsten, sedan operatören

När transport och identitet är avgjorda är den återstående frågan operatörens beteende, och det kräver dokumentation snarare än slutledningar. En integritetspolicy, en publicerad kontakt och ett transparensmeddelande är bevis på avsikt; inget av dem bevisar praktiken, och frånvaron av alla tre är också information.

För en offentlig eller frivilligdriven nod bör du anta att utgången är delad och att den som driver den kan se vad som passerar. Det antagandet, inte värdnamnet, bör avgöra vad du skickar genom tunneln.

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

Behåll namnet för det det är bra på: att hitta en slutpunkt och ansluta till den. Allt därutöver måste testas separat, den dag det spelar roll.

Relaterade artiklar