Názvy hostitelů a vlajky zemí vypadají jako fakta o serveru, ale ani jedno z toho faktem není. Název odkazuje na adresy, které se mohou měnit, a slova v něm vybral ten, kdo ho zaregistroval. Protokol, místo výstupu a chování při protokolování potřebují každé vlastní důkaz. Začněte tím, na co se název skutečně překládá, a pak rozhodněte, co je stále neznámé.

Název se přeloží a nic dalšího není vyřešeno

Název hostitele je ukazatel v DNS a záznamy za ním se mohou lišit podle překladače, podle denní doby a podle rodiny adres, kterou klient upřednostňuje. Dva lidé, kteří čtou stejný záznam v katalogu, se mohou zcela legitimně dostat na různé stroje. Název vám říká, co si máte vyžádat, ne co odpoví.

Výsledky vyhledávání se také mění bez upozornění, což je důležité, když profil připíná adresu místo názvu. Profil, který má starou adresu natvrdo, dál selhává poté, co operátor službu přesune, a selhání vypadá jako zablokovaný port. Uchovávejte přeložené adresy vedle profilu, aby pozdější srovnání mělo základ. Nic z toho neříká, kdo provozuje druhý konec.

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

Transport a identita jsou oddělené otázky

Otevřená webová stránka na názvu hostitele testuje jednoho posluchače na jednom portu. OpenVPN, IPsec a SSTP poslouchají jinde, na svých portech a protokolech, takže dostupný webový server o nich neříká nic.

Záznam v katalogu a profil se musí shodnout na transportu, portu a přihlašovacích údajích. Identita se ověřuje řetězem certifikátů nebo otiskem klíče protistrany, se kterým byl klient nakonfigurován, ne pravopisem názvu hostitele. Název obsahující známé slovo projektu dokazuje jen to, že ho někdo zaregistroval. Přečtěte si certifikát, který služba předkládá, a porovnejte vydavatele a subjekt s tím, co profil očekává.

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

Slova zemí nejsou audit lokality

Štítek jp nebo de v katalogu je registrace a databáze geolokace IP se dost často rozcházejí, takže žádná z nich si nezaslouží být brána jako absolutní pravda. Sdílený hosting, anycast i obyčejná chybná konfigurace posouvají pozorované místo od štítku.

Praktický test je vlastní cesta aplikace: na kterou adresu dosáhne a co ukáže kontrola výstupní adresy zevnitř relace. Pozorovaná výstupní adresa je vlastnost trasy v daném okamžiku, ne záruka připevněná k názvu. Katalogy dobrovolníků přidávají další vrstvu, protože ten, kdo záznam zaregistroval, nemusí být ten, kdo stroj provozuje. Zapište, co jste změřili a kdy, místo toho, co záznam sliboval.

Prověřte nabízenou službu, pak operátora

Když je transport a identita vyřešena, zbývá otázka chování operátora a ta vyžaduje doložené důkazy, ne odvozování. Zásady ochrany soukromí, zveřejněný kontakt a oznámení o transparentnosti jsou důkazem záměru; žádné z nich neprokazuje praxi a nepřítomnost všech tří je také informace.

U veřejného nebo dobrovolníky provozovaného uzlu předpokládejte, že výstup je sdílený a že ten, kdo ho provozuje, může vidět, co jím prochází. Tento předpoklad, ne název hostitele, má rozhodovat o tom, co tunelem posíláte.

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

Nechte název na to, v čem je dobrý: najít koncový bod a připojit se k němu. Všechno ostatní se musí otestovat zvlášť, v den, kdy na tom záleží.

Související články