Como registar e verificar o endereço de saída VPN que utilizou

Pergunte a um cliente VPN de ambiente de trabalho que servidores utilizou e a resposta honesta costuma ser um nome de localização. Esse nome é o ponto de entrada que marcou, e o endereço por onde o seu tráfego saiu pode ser uma máquina completamente diferente. Nada na app foi concebido para guardar o segundo número, por isso o registo tem de ser construído no momento da utilização. Existem duas abordagens, e só uma sobrevive a um caso de apoio.

Dois registos, e só um deles existe

A vista do próprio cliente é, na melhor das hipóteses, uma lista de localizações escolhidas com marcas temporais. É uma decisão de conceção e não um descuido: os endereços são detalhe operacional, rodam entre atribuições, e expor a correspondência torna o apoio e o tratamento de abusos mais difíceis. Os fornecedores colocam instâncias na nuvem à frente das suas redes precisamente para que o ponto final possa mudar sem avisar ninguém. O que a app lhe mostra é a escolha que fez, não a rota que seguiu.

O registo que pode construir é um ficheiro local com um endereço público e uma marca temporal UTC por linha. É mais pequeno, mais feio e muito mais útil, porque descreve exatamente aquilo que um observador externo também consegue ver.

Opção A: capturar o endereço de saída

Um serviço de eco devolve o endereço de origem de onde o pedido chegou, que é, por definição, o endereço de saída. Execute a captura depois de o túnel indicar ligado, porque um cliente que diz ligado antes de as rotas e o DNS assentarem registará o endereço anterior ao túnel e envenenará o registo logo na primeira linha.

#!/bin/sh
umask 077
log="$HOME/vpn-exit.log"
printf '%s %s\n' "$(date -u +%Y-%m-%dT%H:%M:%SZ)" "$(curl -fsS https://api.ipify.org)" >> "$log"

Dois detalhes tornam esse trecho utilizável em vez de decorativo. A marca temporal e o endereço partilham uma linha, pelo que uma análise posterior não tem de emparelhar registos, e umask 077 mantém o ficheiro privado desde o momento em que é criado. Execute-o uma vez por ligação em vez de uma vez por arranque, e mantenha um ficheiro por dispositivo.

O registo anota quando utilizou um túnel e de que rede apareceu, o que está mais perto de um histórico de navegação do que de um contador. Escolha um período de retenção que consiga defender, mantenha o ficheiro fora de pastas de sincronização partilhadas e apague-o de propósito.

Opção B: pedir um histórico ao fornecedor

Alguns fornecedores guardam registos de ligação e responderão a uma pergunta de apoio com uma marca temporal e um nome de servidor. Esse registo descreve a infraestrutura deles e não o seu tráfego, e vale apenas o que valem a janela de retenção e a vontade de olhar. Descreve também uma sessão, não um pedido. A janela costuma ser curta, e é medida do lado do fornecedor do túnel.

Os fornecedores que anunciam não registar não conseguem produzir isto a pedido, e uma lista de localizações recentes do lado do cliente não é a mesma coisa. Pedir um endereço de saída a um fornecedor sem registos costuma terminar com uma explicação de porque é que esses dados não existem.

O que cada registo pode provar num caso de apoio

Os dois registos respondem a perguntas diferentes, e é na tabela que a comparação deixa de ser académica.

Só a primeira coluna está sob o seu controlo. Um registo do fornecedor pode confirmar que uma conta estava ligada numa dada altura, mas não pode confirmar que pedidos usaram o túnel, e não nomeará um endereço que o fornecedor trata como detalhe operacional. Nenhum dos dois registos identifica uma pessoa, porque um endereço de saída partilhado pode transportar muitos clientes no mesmo minuto.

Compare ambos com uma referência antes de confiar em qualquer um

Um endereço por si só não prova nada. Capture o endereço direto antes de ligar, o endereço em túnel depois, e compare-os. Valores idênticos significam que o túnel não transporta esse pedido, quer por um túnel dividido, quer por um proxy preponderante ou por um cliente que recaiu numa rota direta.

curl -fsS https://api.ipify.org; echo
curl -fsS https://api64.ipify.org; echo
dig +short TXT o-o.myaddr.l.google.com @1.1.1.1

Repita a comparação para DNS e para IPv6, porque um eco de endereço prova o caminho de um único pedido HTTP e nada sobre que resolvedor respondeu. Um dispositivo que vaza num dos dois pode parecer perfeitamente saudável no outro.