Quando dois assinantes de uma VPN abrem a mesma página, o site pode ver os pedidos a chegar a partir de um único endereço IP público. Isso não significa que o servidor VPN os confunda: para encaminhar as respostas, associa cada troca a uma correspondência temporária e a um túnel para o dispositivo em causa.
Esta distinção esclarece duas questões que muitas vezes se confundem. Um endereço IP partilhado pode ocultar dos sites visitados o endereço público de origem. Mas o funcionamento da rede exige, ainda assim, que o servidor VPN guarde, pelo menos durante as trocas, informação suficiente para saber para onde reenviar os pacotes. Esta memória de ligação não é, por si só, um histórico de navegação.
Um endereço visível, várias ligações
Um endereço IP serve para encaminhar pacotes entre redes. No caso clássico do IPv4, vários dispositivos da mesma rede doméstica já podem partilhar o endereço público atribuído ao router. Dentro de casa, têm endereços privados; à saída, o router substitui esses endereços pelo seu. No regresso, efetua a tradução inversa.
Um servidor VPN pode desempenhar um papel semelhante para o tráfego que o atravessa. O dispositivo do assinante envia os seus dados num túnel cifrado até ao servidor VPN. Dentro da rede VPN, o servidor pode identificar o cliente através do respetivo endereço interno e das informações associadas ao túnel. Em seguida, para transmitir o tráfego para a Internet, utiliza o seu endereço IP público.
O site remoto vê esse endereço público, e não o endereço público da rede a partir da qual o assinante se ligou à VPN. Por isso, se vários clientes saírem pelo mesmo endereço VPN, este não basta para os distinguir. O servidor também tem de acompanhar as próprias ligações.
A porta completa o endereço
Numa ligação TCP ou UDP, os cabeçalhos dos pacotes incluem números de porta, além dos endereços IP. Uma porta identifica um ponto de comunicação associado a uma troca. Para aceder a um site através de HTTPS, o tráfego é geralmente dirigido à porta 443 do servidor. O navegador também utiliza uma porta do lado do cliente, chamada porta de origem.
Imaginemos, a título didático, dois clientes cujos pedidos saem pelo mesmo endereço VPN em direção ao mesmo servidor web. A VPN pode atribuir portas de origem distintas, no seu endereço público, às respetivas trocas. O servidor web responde ao endereço e à porta associados a cada pedido. A VPN consulta então a sua tabela de correspondência para encontrar o endereço e a porta internos do cliente em causa e, em seguida, reencaminha-lhe os dados pelo respetivo túnel.
Esta tradução do endereço e da porta chama-se NAPT, de «Network Address and Port Translation». A RFC 3022 da Internet Engineering Task Force descreve este mecanismo para redes IPv4: vários endereços internos e as respetivas portas podem ser associados a um único endereço externo e a portas distintas. A associação tem em conta o protocolo utilizado, nomeadamente TCP ou UDP.
A porta não é, portanto, uma etiqueta permanente de um utilizador da Internet. Serve para distinguir trocas em curso. Uma tabela de estado conserva as correspondências necessárias para o envio e o retorno; quando a ligação termina ou fica inativa, estas informações podem expirar. Sem este estado, o servidor não saberia a que cliente entregar uma resposta recebida num endereço comum.
Do servidor VPN ao túnel certo
A tradução do endereço público é apenas uma parte do percurso. Quando a resposta regressa ao servidor VPN, este ainda tem de a transmitir ao dispositivo certo através do túnel correspondente. Para isso, recorre às informações da rede interna e ao funcionamento do protocolo VPN.
No WireGuard, por exemplo, os endereços autorizados nos túneis estão associados às chaves públicas dos clientes. Isto contribui para a escolha da sessão criptográfica utilizada para transmitir os pacotes. Os pormenores variam consoante os protocolos e as arquiteturas: o princípio de partilha de um endereço de saída não significa que todas as VPN realizem cada etapa exatamente da mesma forma, nem que todas as configurações tenham de utilizar uma tradução de endereços idêntica.
A regra útil é mais geral: uma resposta tem de regressar através do dispositivo capaz de encontrar a troca a que pertence. A RFC 3022 sublinha esta condição para o NAT tradicional: o tráfego de uma sessão tem de passar pelo router que detém o seu estado de tradução, ou por um dispositivo que partilhe as informações necessárias. Se esse percurso ou esse estado desaparecer, uma ligação em curso pode falhar, mesmo que o endereço público continue disponível.
Memória técnica não significa registo de navegação
É preciso distinguir dois tipos de informação. A tabela de correspondência serve para o encaminhamento: liga temporariamente uma troca externa a uma ligação interna. Um registo de navegação, no sentido corrente, documenta a atividade de um utilizador, por exemplo, os sites visitados ou os momentos de ligação. A necessidade de manter o estado das ligações não demonstra, por si só, que o fornecedor conserva este segundo tipo de dados.
Esta distinção não permite, ainda assim, tirar conclusões sobre a política de um fornecedor específico. O período de conservação, os dados registados para outros fins e as práticas de gestão dependem da sua configuração e dos seus compromissos, que devem ser analisados separadamente. A mecânica da rede explica o que é necessário acompanhar para encaminhar o tráfego; não certifica as práticas da empresa.
Por fim, um IP partilhado não equivale a anonimato. Um site pode reconhecer uma pessoa porque esta inicia sessão na sua conta, graças a cookies ou a outros elementos associados ao seu navegador. A VPN altera o endereço IP público visível para o site, mas não elimina estes outros meios de reconhecimento. Responde, portanto, a uma questão específica, a do endereço utilizado para aceder à Internet, sem apagar a identidade associada às contas ou aos rastos guardados no navegador.
Referências
- RFC 3022, «Traditional IP Network Address Translator»
- Clubic, «Milhares de utilizadores da Internet, um único IP VPN»
Um comutador Ethernet. Fotografia ilustrativa das trocas entre equipamentos de rede.
Crédito: Raysonho @ Open Grid Scheduler / Grid Engine — Wikimedia Commons — CC0 1.0.
