O IP de saída de uma VPN não prova um túnel: o que os servidores veem

Alguém pede um serviço que apenas usuários de VPN conseguem alcançar, e a implementação óbvia é permitir uma lista de endereços de saída. A lista faz algo real: restringe quem pode se conectar. Ela não estabelece que um túnel foi usado, porque o endereço pertence a quem opera a saída e esse operador pode encaminhar o tráfego de qualquer pessoa. A diferença entre essas afirmações é todo o problema de design.

O servidor vê um endereço por conexão

Uma conexão chega com um endereço de origem e uma porta de destino, e isso é tudo o que a camada de rede relata. Quando um cliente usa um túnel, os pacotes que chegam ao seu listener vêm da saída ou da tradução à frente dela. O endereço do próprio cliente, normalmente privado, nunca aparece. Uma regra de firewall escrita para a faixa da LAN do cliente, portanto, não faz absolutamente nada.

Tudo depois desse endereço de origem são dados de aplicação, e a aplicação só pode confiar neles na medida em que os autentica.

Teste como é a sua saída

Olhe o caminho dos dois lados antes de escrever uma regra. A visão do cliente sobre a sua saída e a visão do servidor sobre a conexão são os dois fatos que importam.

curl -sS https://api.ipify.org; echo
ss -tn state established '( sport = :443 )' | head

O primeiro comando relata o endereço público com que o cliente aparece, e esse é o valor que qualquer lista de permissões deve conter. O segundo mostra as conexões estabelecidas no servidor com os endereços dos seus pares, e é com isso que a regra realmente vai coincidir. Se os dois não concordarem com o seu modelo mental, corrija o modelo antes de editar a política. Um firewall de banco de dados na nuvem, uma lista de permissões de aplicação e um balanceador de carga podem cada um ver uma camada de tradução diferente.

Apenas um dos dois conjuntos de saída pode ser listado

Um caso é verificável no momento do pedido e o outro não, o que produz garantias muito diferentes.

curl -sS https://check.torproject.org/torbulkexitlist | wc -l

A lista publicada de saídas do Tor pode ser obtida e comparada, sujeita à idade da lista e à política própria de cada saída, então uma regra de recusa contra saídas conhecidas é aplicável e revisável. Não existe um registro equivalente para VPNs comerciais. Os endereços rodam, muitos provedores não publicam nada, e um túnel pode rodar num endereço de nuvem alugado que nunca pertenceu a uma VPN. A lista que você compila é uma fotografia de endereços observados, e ampliá-la para faixas de hospedagem acrescenta cargas não relacionadas sem acrescentar provas.

Use endereços como entrada de política, não como prova

Decida para que serve a regra. Uma restrição de rede deve permanecer estreita, registrar o endereço observado com a data e o motivo, e dar aos usuários legítimos um caminho de recuperação quando a sua saída mudar. O controle de acesso precisa de uma conta autenticada ou de um token assinado, porque só estes vinculam um pedido a uma identidade. A pontuação de risco pode usar o endereço como um único sinal pouco fiável, aceitando os seus falsos positivos e os seus pontos cegos. Escrever a regra como decisão de produto é honesto; escrevê-la como verificação de que existe um túnel não é.

O pedido espelhado, recuperar o endereço real do usuário atrás de uma VPN, falha pelo mesmo motivo: uma conexão carrega um endereço, e uma mudança entre sessões é compatível com várias explicações. Trate o valor anterior como histórico, não como verdade.