Dous portátiles no mesmo router da casa poden chegar a internet por saídas VPN distintas, e a Wi-Fi compartida non ten nada que dicir ao respecto. O que decide o resultado é onde se executa o túnel e que política escolle a ruta de cada petición. A crenza contraria é igual de común e igual de errónea: dous dispositivos con perfís separados non producen automaticamente dous enderezos públicos. Ambos os erros veñen de tratar un enderezo como se fosen tres.

Tres enderezos, e só un deles sae

Un portátil ten un enderezo na LAN da casa que o identifica no segmento local, e tamén pode ter un enderezo de túnel asignado dentro da VPN. Ningún dos dous é visible para un servizo remoto. O que ese servizo rexistra é o enderezo de saída pública do dispositivo que finalmente envía o paquete, tras calquera tradución polo camiño.

A RFC 3022 traza a distinción que explica a maior parte da confusión aquí. O NAT tradicional asigna enderezos internos a enderezos públicos, mentres que a tradución de portos permite que moitos enderezos internos compartan un único enderezo público ao mesmo tempo. Un fogar cun enderezo público e varios dispositivos é o segundo caso, e é o valor por defecto case en todas partes.

Conta os enderezos públicos, non os perfís. Dous clientes con enderezos de túnel distintos e a mesma política de saída producen un enderezo observado, e un único cliente cunha saída encamiñada doutro xeito pode producir outro. Esa única comparación é toda a proba. Todo o demais é unha suposición sobre o extremo remoto.

Que fai que dúas saídas sexan realmente distintas

Unha saída é distinta cando o último dispositivo antes de internet usa un enderezo público diferente para ese tráfico. Iso pode ocorrer porque a VPN remata noutro lugar, porque o conxunto de saídas asigna outro enderezo ou porque o provedor encamiña a petición por outra saída. As tres son decisións de política tomadas no extremo remoto, e ningunha é visible desde o router da casa.

Dous dispositivos que executan cada un o seu cliente co mesmo perfil adoitan caer no mesmo conxunto e a miúdo reciben a mesma saída para unha sesión dada. Non é un fallo, é o comportamento normal dun conxunto compartido. Conseguir saídas distintas normalmente significa pedirlle ao servizo asignacións distintas en lugar de configurar o cliente dúas veces.

Le as condicións do servizo sobre conexións simultáneas antes de deseñar arredor dunha garantía. Un segundo inicio de sesión é permiso para conectarse, non unha promesa de enderezo exclusivo. Se as condicións calan, pregunta ao provedor en lugar de supoñer. A resposta cambia o deseño máis que calquera axuste do cliente.

Por que os perfís separados non son saídas separadas

Un perfil describe como chegar á VPN e como autenticarse, e case non di nada sobre o que ocorre despois. A saída escolle a o extremo remoto, onde viven o encamiñamento, os conxuntos de enderezos e a política de tradución. Duplicar un perfil nunha segunda máquina duplica a configuración do cliente, non a decisión do servidor.

O contrario tamén se cumpre. Un servidor VPN pode presentar máis dunha saída pública cando o seu encamiñamento e a súa política de tradución están construídos así, mentres que servidores separados poden alimentar unha única saída descendente. Así que o número de nomes de servidor na túa configuración non di nada sobre o número de enderezos. Por iso a configuración é o lugar equivocado para buscar esta resposta.

A única resposta fiable vén dunha petición feita a través do arranxo que pensas usar. Todo o demais é inferencia.

Onde pór a separación

Un túnel no router cobre todo o fogar, o que é cómodo e produce exactamente unha saída compartida para cada dispositivo detrás. Un cliente en cada dispositivo dálle control por dispositivo, pero require que cada dispositivo estea aprovisionado e siga estándoo. Un router con capacidade de políticas sitúase no medio e escolle unha ruta por dispositivo, e só funciona se pode identificar os dispositivos de forma fiable entre reconexións e cambios de DHCP.

Crear outra concesión DHCP privada no router non é o mesmo que crear outro enderezo público. Cambia a vista local e deixa a saída intacta. A separación vive na política de saída, tanto se esa política está no router coma no servizo de VPN.

Sexa cal sexa a forma que escollas, anota a propiedade: quen aprovisiona un dispositivo, quen rota a súa credencial e quen nota cando deixa de usar a ruta prevista.

Comproba a saída que realmente obtiveches

Fai a comprobación desde a aplicación que importa e compara a mesma familia de enderezos nos dous dispositivos. Un resultado IPv4 dun e un resultado IPv6 do outro non demostran nada de ningún. Despois repite a comprobación tras unha reconexión, porque a asignación do conxunto pode cambiar entre sesións.

Execútao desde un terminal dentro da política do túnel, non desde un dispositivo que a evite. O host equivocado produce unha resposta equivocada e confiada.

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 amosan o mesmo enderezo IPv4, comparten unha saída independentemente de cantos túneles estean activos. Despois decide que ocorre cando o túnel falla: un cliente que volve á ruta directa devolve ambos os dispositivos ao enderezo da casa, e a separación desaparece sen un erro. Confirma ese comportamento de retorno antes de describir o arranxo como dúas saídas, e lembra que enderezos distintos son un resultado de rede e non dúas identidades anónimas.

Artigos relacionados