Escolha uma fonte de registro estável para os membros de GET VPN

Alguém aponta o registro do membro do grupo para um endereço loopback e declara resolvida a instabilidade do GET VPN. Às vezes é verdade. Muitas vezes o loopback só é alcançável pela própria tabela de rotas do membro e de nenhum outro lugar, então o registro volta a quebrar na próxima vez que o uplink que o carregava oscilar. O endereço de registro é uma identidade no plano de controle, e só ajuda quando existe um caminho real nos dois sentidos. Escolhê-lo de propósito vale a pena, e é uma mudança menor do que sugere a crença popular.

O que o endereço de registro identifica

Numa implantação GDOI o membro do grupo registra-se no servidor de chaves e recebe dele a política de grupo. O endereço que o servidor de chaves anota é a identidade do membro para essa conversa.

Essa identidade cobre a conversa de controle: registro, renovação de chaves e download da política. Ele não se torna a origem do tráfego dos clientes, e não muda quais interfaces protegem quais fluxos.

Manter os dois separados é o primeiro passo, porque a maior parte da confusão sobre esta configuração vem da expectativa de que uma mudança no plano de controle corrija um sintoma no plano de dados.

Um loopback vale tanto quanto a sua rota

Um loopback dá ao membro um endereço lógico que não desaparece quando um uplink físico falha. É uma vantagem real num roteador com vários caminhos até o servidor de chaves.

Mas também é só um endereço. Se o servidor de chaves não tiver rota de volta, o registro falha exatamente como antes. Se a tabela de rotas do membro só chega ao servidor de chaves por um uplink, o loopback é estável e o caminho não.

Verifique a alcançabilidade nos dois sentidos por cada uplink que você quer que sobreviva. Um loopback que permanece administrativamente ativo não prova nada sobre encaminhamento, e a falha aparece como servidor de chaves inalcançável e não como problema de interface. Escreva a verificação como comando por uplink, não como suposição. Assim a próxima janela de mudança começa por evidências e não por um diagrama.

Mantenha o controle e o tráfego protegido separados

O guia de desvio do GDOI da Cisco documenta a interface de registro e a relação entre o registro e o tratamento do desvio. Leia o comportamento da versão que você realmente executa em vez de tratar uma frase como comando universal.

Revise a filtragem e a tradução no caminho de controle, e confirme que o tráfego de gestão de chaves não é arrastado por acidente para uma política de proteção que depende justamente da política de grupo que ele tenta obter. Essa dependência circular é uma forma clássica de fazer uma implantação funcional falhar após uma mudança de política.

A política do plano de dados é um desenho separado. Mudar a origem do registro deixa os fluxos protegidos, os seletores e as regras de desvio exatamente onde estavam.

Verifique a identidade durante a transição

Antes da mudança, anote o grupo, o endereço de registro escolhido, o destino do servidor de chaves, o contexto de roteamento e o caminho de controle permitido. Depois de uma mudança de uplink aprovada, inspecione novamente a visão de membros registrados no servidor de chaves e o estado de controle do membro.

O que você quer ver é o ponto final lógico pretendido ainda alcançável e ainda representado como você projetou. O que você não quer é um segundo registro a partir de um endereço que não pretendia, porque é assim que as entradas duplicadas de membro aparecem.

Depois teste o tráfego de aplicação protegido separadamente. Uma transferência pode ter sucesso enquanto a próxima renovação de chaves não tem para onde ir, e um registro bem-sucedido não diz nada sobre se um fluxo específico está bem selecionado e roteado.

O que uma fonte estável não corrige

Não remove as entradas duplicadas de membro criadas por uma configuração errada anterior. Não repara uma falha de renovação de chaves causada por divergência de política entre o membro e o servidor de chaves. Não sobrevive a uma falha do caminho físico que removeu a única rota até o servidor de chaves.

O que ele faz é remover uma variável: a identidade deixa de mudar quando um endereço de uplink muda. Isso vale a pena ter, e é uma linha num desenho e não o desenho inteiro.

Ordem do trabalho: nomear o caminho de controle, escolher um endereço com rota nos dois sentidos, confirmar a visão do servidor de chaves e depois testar o tráfego protegido separadamente. Se o registro ainda falhar, o loopback nunca foi o problema.