Duas /24 adjacentes se fundem ordenadamente em uma /23, e essa aritmética arrumada convence as pessoas de que a mudança é cosmética. É aritmética sobre endereços, e o túnel se importa com seletores, que são uma oferta de negociação e não uma descrição de rede. A linha mais curta pode deixar o mesmo tráfego protegido, proteger mais do que o pretendido, ou não cobrir metade dele, dependendo do que os dois pares estão dispostos a aceitar. Ler o resultado instalado é a única forma de saber qual dos três aconteceu.

Três fatos que as pessoas fundem em um

O conjunto de endereços diz quais hosts devem ser protegidos. O agrupamento diz como esses endereços são oferecidos: um seletor ou vários, em uma associação ou mais. O resultado negociado diz o que os dois pares realmente instalaram, e pode ser mais estreito do que qualquer um dos dois primeiros.

Escreva-os separadamente no registro da mudança. Uma única linha de configuração costuma esconder três respostas diferentes. Um revisor que não consegue separá-las também não consegue aprovar a mudança.

O que o respondente pode fazer com o seu agregado

Um respondente IKEv2 pode estreitar um par de seletores oferecido para um subconjunto que esteja disposto a aceitar, e pode recusar a oferta de imediato se nada aceitável existir. Também pode indicar que tráfego adicional precisa de outra associação em vez de caber nesta.

Um respondente que não aceita nada devolve um erro, o que ao menos diz que a oferta foi rejeitada e não silenciosamente estreitada.

Isso significa que uma troca bem-sucedida prova que os pares concordaram em algo, não que concordaram em tudo o que você listou. A mensagem inicial de sucesso é um ponto de partida para ler o resultado, nunca uma conclusão. O subconjunto aceito pode ser menor que uma única /24, o que faz o conjunto instalado não se parecer em nada com a oferta.

Onde um resumo apaga silenciosamente uma fronteira

Duas /24 podem ter regras de serviço diferentes: uma pode permitir apenas um protocolo de gerenciamento, a outra uma aplicação geral. Um seletor que cobre os dois endereços na camada IP não preserva essas regras, e o resumo move a fronteira para qualquer filtragem que exista atrás do túnel. Liste as regras de serviço por sub-rede antes de agregar, ou essa comparação nunca acontece.

Valores de protocolo e porta fazem parte de um seletor, não são um extra opcional. Se a política original os restringia, o agregado precisa carregar a mesma restrição, ou a mudança é uma mudança de permissão vestida de roteamento. Se a restrição era o ponto da política original, mantenha-a explícita após o resumo e diga isso no registro.

Ler o resultado por prefixo

Depois da mudança, olhe para o que foi instalado em vez do que foi configurado. Em seguida, gere um fluxo a partir de cada prefixo em cada direção, e verifique os contadores que pertencem à associação que o trata. Dois prefixos que produzem tráfego em uma associação estão bem; dois prefixos em que um não produz nada são o achado.

Faça isso com a mesma aplicação que os usuários executam. Uma sonda originada no gateway testa um caminho diferente do de um cliente atrás dele, e a diferença é exatamente onde os bugs de seletor se escondem. Um contador estável em um prefixo que deveria estar ocupado é evidência mais forte do que qualquer linha de log, porque mede a ausência.

Tornar a mudança reversível

Mantenha a política original na configuração até a nova ter sido exercitada a partir de cada combinação de prefixos, e anote em qual associação cada fluxo caiu. Se um par substitui associações quando a oferta muda, o rollback precisa restaurar a oferta antiga e não apenas os endereços antigos.

Coordene com o dono da outra ponta antes de abrir a janela. Um resumo que um lado considera óbvio pode ser um agrupamento inaceitável no outro, e descobrir isso durante a mudança é caro. Combine o agrupamento oferecido por escrito, depois compare-o com o que a troca instala. Guarde esse acordo no ticket de mudança, não em uma conversa que desaparece na semana seguinte.

Artigos relacionados