Endereços de privacidade IPv6 ou uma lista de permissões RDP: escolha o compromisso

O acesso à área de trabalho remota funcionou por um mês, e então a lista de permissões parou de corresponder sem nenhuma razão visível. O host não tinha se movido e nada no firewall tinha sido editado. O Windows continua a formar endereços temporários IPv6 com identificadores de interface aleatórios e a retirá-los, então o endereço de origem que o servidor vê em qualquer dia pode ser um que ninguém escreveu na regra. Desativar esse comportamento corrige a correspondência e ao mesmo tempo transforma o host em um identificador de longa duração. Pese as alternativas antes de aceitar a segunda metade.

Por que a regra parou de corresponder

O RFC 4941 descreve endereços temporários: o host cria endereços adicionais com identificadores aleatorizados e os retira, o que impede um observador de correlacionar um host entre visitas. O Windows implementa esse comportamento, então o endereço de origem de ontem não é necessariamente o de hoje. O endereço previsível ainda existe na interface; simplesmente não é o que uma conexão de saída prefere.

Por isso a falha parece intermitente e não total. A regra corresponde por um tempo depois que o endereço é criado, deixa de corresponder quando ele é retirado e volta a corresponder depois que alguém o edita. O monitoramento agrupado por endereço de origem e as verificações de licença vinculadas a um endereço de host quebram no mesmo calendário. Uma regra que funciona logo após ser editada e falha três semanas depois costuma ser isto, não uma recarga do firewall.

Opção um: um endereço estável, menos privacidade

O reparo habitual desativa os dois mecanismos de rotação no host: netsh interface ipv6 set privacy state=disabled store=persistent e netsh interface ipv6 set global randomizeidentifiers=disabled store=persistent. Adicione store=active se quiser que a mudança tenha efeito sem esperar por uma reinicialização, e aceite que você tornou o identificador previsível entre redes.

Essa previsibilidade é exatamente o que as extensões foram criadas para evitar. Um endereço que segue o host do café ao escritório e para casa é uma chave de filtragem conveniente e uma chave de rastreamento igualmente conveniente, e a segunda propriedade sobrevive ao ticket que pediu a primeira.

Opção dois: permitir um prefixo ou um nome

Permitir o /64 em vez do endereço completo mantém a rotação intacta e combina com uma afirmação mais fraca, mas muitas vezes honesta: esta máquina está na minha rede doméstica. Isso deixa de ser suficiente no momento em que esse prefixo contém hosts que você não admitiria, o que numa conexão de consumidor costuma ser um conjunto menor do que as pessoas supõem. Um nome publicado via DNS dinâmico é mais fácil de operar, porque o registro segue o host e a política é lida como uma identidade em vez de um intervalo que cresce sempre que um dispositivo é adicionado.

As duas opções precisam de um resolvedor em que o servidor possa confiar e de um nome que não seja trivialmente falsificável, então trate-as como uma decisão de política sobre identidade e não como uma mudança cosmética na regra. Anote qual resolvedor responde a esse nome, porque a regra é tão confiável quanto o registro por trás dela.

Opção três: deixe o túnel atribuir o endereço

Se a conexão atravessa uma VPN que você controla, o servidor pode distribuir o endereço do próprio pool, e a lista de permissões passa a referenciar um valor que o servidor escolhe em vez de um que o cliente prefere. Isso funciona bem para clientes gerenciados e mal para tudo o que o cliente possa sobrepor, então verifique qual lado realmente vence na sua implantação.

Mover a decisão completamente para fora do endereço, para um certificado de cliente ou um gateway autenticado, é a opção que escala, porque deixa de depender de um valor que o sistema operacional tem o direito de mudar.

Escolha com o custo de rastreamento em vista

Escreva as quatro opções contra o requisito real, e escolha uma em vez de combiná-las. Se você desativar a privacidade de qualquer forma, limite-a ao host que precisa dela, documente o motivo ao lado da regra e considere o endereçamento estável-privado do RFC 7217 onde a plataforma o suporta, pois mantém um identificador por prefixo sem expor o derivado do hardware. Reative as extensões quando a lista de permissões for substituída.

Registre a mudança ao lado da regra que ela apoia. Sem essa nota, o próximo administrador encontra um host com as extensões de privacidade desligadas e sem explicação, e as liga de novo durante uma limpeza.