O que um nome de host VPN público pode e não pode provar

Nomes de host e bandeiras de países parecem factos sobre um servidor, e nenhum dos dois é. Um nome aponta para endereços que podem mudar, e as palavras dentro dele foram escolhidas por quem o registou. O protocolo, a localização de saída e o comportamento de registo precisam cada um da sua própria prova. Comece pelo que o nome realmente resolve, e depois decida o que ainda é desconhecido.

O nome resolve, e nada mais está definido

Um nome de host é um ponteiro no DNS, e os registos por trás dele podem variar conforme o resolvedor, conforme a hora do dia e conforme a família de endereços que o cliente prefere. Duas pessoas que leem a mesma entrada de diretório podem chegar legitimamente a máquinas diferentes. O nome diz o que pedir, não o que vai responder.

Os resultados de consulta também mudam sem aviso, o que importa quando um perfil fixa um endereço em vez do nome. Um perfil que embute o endereço antigo continua a falhar depois de o operador mudar o serviço, e a falha parece uma porta bloqueada. Guarde os endereços resolvidos ao lado do perfil para que uma comparação posterior tenha uma base. Nada disso diz quem administra o outro lado.

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

Transporte e identidade são perguntas separadas

Uma página web aberta no nome de host testa um único ouvinte numa única porta. OpenVPN, IPsec e SSTP escutam noutros lugares, nas suas próprias portas e protocolos, portanto um servidor web acessível não diz nada sobre eles.

A entrada do diretório e o perfil têm de concordar quanto a transporte, porta e credenciais. A identidade é verificada pela cadeia de certificados ou pela impressão digital da chave do par com que o cliente foi configurado, não pela grafia do nome do host. Um nome que contém uma palavra de projeto conhecida prova apenas que alguém o registou. Leia o certificado que o serviço apresenta e compare emissor e assunto com o que o perfil espera.

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

As palavras de país não são uma auditoria de localização

Um rótulo jp ou de num diretório é um registo, e as bases de geolocalização de IP divergem com frequência suficiente para que nenhuma mereça ser tratada como verdade absoluta. Alojamento partilhado, anycast e uma simples configuração errada afastam todos a localização observada do rótulo.

O teste prático é o caminho próprio da aplicação: a que endereço chega e o que uma verificação de endereço de saída mostra de dentro da sessão. Um endereço de saída observado é uma propriedade da rota naquele momento, não uma garantia ligada ao nome. Os diretórios de voluntários acrescentam outra camada, porque quem registou uma ficha não tem de ser quem opera a máquina. Anote o que mediu e quando, em vez do que a ficha prometia.

Verifique o serviço oferecido, depois o operador

Uma vez resolvidos o transporte e a identidade, a pergunta que resta é o comportamento do operador, e isso exige provas documentais em vez de inferências. Uma política de privacidade, um contacto publicado e um aviso de transparência são provas de intenção; nenhuma demonstra a prática, e a ausência das três também é informação.

Para um nó público ou gerido por voluntários, assuma que a saída é partilhada e que quem o gere pode ver o que passa por ela. Essa suposição, e não o nome de host, deve decidir o que envia pelo túnel.

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

Guarde o nome para aquilo em que é bom: encontrar um ponto de extremidade e ligar-se a ele. Tudo o resto tem de ser testado em separado, no dia em que importar.