Dois dispositivos, um Wi-Fi, saídas VPN diferentes: o que decide

Dois portáteis no mesmo router de casa podem chegar à internet por saídas VPN diferentes, e o Wi-Fi partilhado não tem nada a dizer sobre isso. O que decide o resultado é onde corre o túnel e que política escolhe o caminho de cada pedido. A crença contrária é igualmente comum e igualmente errada: dois dispositivos com perfis separados não produzem automaticamente dois endereços públicos. Ambos os erros vêm de tratar um endereço como se fossem três.

Três endereços, e só um deles sai

Um portátil tem um endereço na LAN de casa que o identifica no segmento local, e pode também ter um endereço de túnel atribuído dentro da VPN. Nenhum dos dois é visível para um serviço remoto. O que esse serviço registra é o endereço de saída público do dispositivo que acaba por enviar o pacote, após qualquer tradução pelo caminho.

A RFC 3022 traça a distinção que explica a maior parte da confusão aqui. O NAT tradicional mapeia endereços internos em endereços públicos, enquanto a tradução de portas permite que muitos endereços internos partilhem um único endereço público ao mesmo tempo. Um agregado com um endereço público e vários dispositivos é o segundo caso, e é o padrão em quase todo o lado.

Conte os endereços públicos, não os perfis. Dois clientes com endereços de túnel diferentes e a mesma política de saída produzem um endereço observado, e um único cliente com uma saída encaminhada de outra forma pode produzir outro. Essa única comparação é todo o teste. Tudo o resto é uma suposição sobre o extremo remoto.

O que torna duas saídas realmente diferentes

Uma saída é diferente quando o último dispositivo antes da internet usa um endereço público diferente para esse tráfego. Isso pode acontecer porque a VPN termina noutro local, porque o conjunto de saídas atribui outro endereço, ou porque o fornecedor encaminha o pedido por outra saída. As três são decisões de política tomadas no extremo remoto, e nenhuma é visível a partir do router de casa.

Dois dispositivos que executam cada um o seu cliente com o mesmo perfil ficam normalmente no mesmo conjunto e recebem muitas vezes a mesma saída para uma dada sessão. Isso não é um defeito, é o comportamento normal de um conjunto partilhado. Obter saídas distintas significa normalmente pedir ao serviço atribuições distintas em vez de configurar o cliente duas vezes.

Leia os termos do serviço sobre ligações simultâneas antes de desenhar em torno de uma garantia. Um segundo início de sessão é uma autorização para ligar, não uma promessa de endereço exclusivo. Se os termos forem omissos, pergunte ao fornecedor em vez de presumir. A resposta muda o desenho mais do que qualquer definição do cliente.

Porque perfis separados não são saídas separadas

Um perfil descreve como chegar à VPN e como autenticar, e quase nada diz sobre o que acontece depois. A saída é escolhida pelo extremo remoto, onde vivem o encaminhamento, os conjuntos de endereços e a política de tradução. Duplicar um perfil numa segunda máquina duplica a configuração do cliente, não a decisão do servidor.

O contrário também é verdade. Um servidor VPN pode apresentar mais do que uma saída pública quando o seu encaminhamento e a sua política de tradução são construídos assim, enquanto servidores separados podem alimentar uma única saída a jusante. Por isso o número de nomes de servidor na sua configuração não diz nada sobre o número de endereços. É por isso que a configuração é o local errado para procurar esta resposta.

A única resposta fiável vem de um pedido feito através do arranjo que pretende usar. Tudo o resto é inferência.

Onde colocar a separação

Um túnel no router cobre todo o agregado, o que é prático e produz exatamente uma saída partilhada para cada dispositivo atrás dele. Um cliente em cada dispositivo dá-lhe controlo por dispositivo, mas exige que cada dispositivo seja aprovisionado e continue aprovisionado. Um router com capacidade de políticas fica entre os dois, escolhe um caminho por dispositivo, e só funciona se conseguir identificar dispositivos de forma fiável entre reconexões e alterações de DHCP.

Criar outra concessão DHCP privada no router não é o mesmo que criar outro endereço público. Altera a vista local e deixa a saída intacta. A separação vive na política de saída, quer essa política esteja no router ou no serviço de VPN.

Seja qual for a forma que escolher, anote a propriedade: quem aprovisiona um dispositivo, quem roda as suas credenciais e quem repara quando ele deixa de usar o caminho previsto.

Verifique a saída que realmente obteve

Faça a verificação a partir da aplicação que importa, e compare a mesma família de endereços nos dois dispositivos. Um resultado IPv4 de um e um resultado IPv6 do outro não provam nada sobre nenhum deles. Depois repita a verificação após uma reconexão, porque a atribuição do conjunto pode mudar entre sessões.

Execute-o a partir de um terminal dentro da política do túnel, não a partir de um dispositivo que a contorne. O anfitrião errado produz uma resposta errada e confiante.

curl -4 -sS https://api.ipify.org; echo
curl -6 -sS https://api64.ipify.org; echo
ip route get 1.1.1.1

Se ambos os dispositivos mostram o mesmo endereço IPv4, partilham uma saída independentemente de quantos túneis estão ativos. Depois decida o que acontece quando o túnel falha: um cliente que recua para o caminho direto coloca ambos os dispositivos de volta no endereço de casa, e a separação desaparece sem erro. Confirme esse comportamento de recuo antes de descrever o arranjo como duas saídas, e lembre-se de que endereços diferentes são um resultado de rede e não duas identidades anónimas.