Cinco papéis de endereço num perfil IPsec, e qual está errado

Cinco tarefas diferentes recebem um endereço numa definição de ligação típica, e não têm de concordar entre si. Os administradores ficam presos porque um instinto razoável, fazer todos os campos apontar para o mesmo anfitrião, está errado para pelo menos três deles. A saída é nomear primeiro o sintoma e depois olhar para o campo ou os dois campos que o poderiam produzir.

As cinco tarefas, pela ordem em que importam

O ponto final de transporte é onde o intercâmbio IKE é entregue. A identidade autenticada é o nome que cada lado prova, e é verificada contra a política, não contra uma tabela de encaminhamento. As sub-redes protegidas são os seletores que decidem que tráfego interno pertence ao túnel. Depois há a origem usada quando o próprio gateway inicia uma conversa e, por fim, o próximo salto da camada inferior para alcançar o par.

Etiquetas de participante como left e right são convenções para os dois lados de uma ligação, não sinónimos de local e remoto. Leia o manual da implementação que está realmente instalada antes de assumir que uma chave significa o que outro produto entendia por ela.

Decisão um: nada se estabelece

Quando não aparece qualquer intercâmbio nos registos, o ponto final é o primeiro suspeito: um endereço errado, um caminho filtrado ou uma interface onde o daemon não está à escuta. Só passe aos campos de identidade depois de o aperto de mão estar visível, porque a identidade é julgada dentro do intercâmbio, não antes. Um caminho filtrado e um endereço errado parecem idênticos do lado do cliente, por isso verifique o lado que escuta antes de editar seja o que for. Confirme que o daemon está ligado à interface que espera, porque um serviço à escuta num endereço parece exatamente um caminho bloqueado.

Um endereço público observado através de tradução não é o mesmo que a identidade que um par prova. Alterar um endereço para corresponder ao que uma captura de pacotes mostra no extremo remoto é uma correção comum e errada.

Decisão dois: o túnel está levantado e o tráfego morre

Os seletores decidem o que entra no túnel, e uma discrepância aqui produz uma ligação que negoceia com êxito enquanto a aplicação continua a falhar. O lado remoto tem de nomear o seu intervalo protegido como o seu intervalo remoto, e é exatamente aí que se infiltram valores invertidos.

Leia as duas configurações lado a lado antes de editar. O intervalo local num anfitrião é o intervalo remoto no outro, e um único par trocado explica um túnel que não transporta nada. Estreite o par antes de tocar nas chaves: uma sub-rede dentro do túnel e outra fora dizem-lhe se a culpa é do seletor ou do encaminhamento.

Decisão três: só falha o tráfego próprio do gateway

O tráfego reencaminhado para clientes pode funcionar perfeitamente enquanto um pedido iniciado pelo próprio gateway falha, porque esse fluxo não tem origem de cliente para herdar. A definição de origem preferida existe para este caso, e não é tradução de origem: escolhe um endereço de origem em vez de reescrever um.

Uma aplicação que liga explicitamente outro endereço pode sobrepor-se à preferência, por isso confirme a origem real do pacote antes de concluir que a definição é ignorada. Capture na interface própria do gateway em vez de confiar na intenção da configuração.

O próximo salto é uma instrução local

O próximo salto da camada inferior diz a este anfitrião como alcançar o par, e o lado remoto não precisa do mesmo valor. Tratá-lo como uma definição partilhada, ou codificar de forma rígida um gateway predefinido, quebra no momento em que a rota muda ou aparece um segundo caminho.

Algumas implementações oferecem valores especiais aqui. O que o manual lista para a versão instalada é a única resposta segura, e a tabela de encaminhamento local é a prova de que funcionou. Quando um par é alcançável por nome mas não por endereço, essa discrepância é o achado, não um detalhe a contornar.

Leia o perfil a partir das duas pontas

Inverter os papéis no papel é a revisão mais rápida que existe: troque os intervalos protegidos, mantenha o próximo salto próprio de cada lado e a identidade própria de cada lado. Tudo o que não sobrevive à troca está provavelmente atribuído à tarefa errada.

Depois teste um fluxo por papel: alcance entre pares, um fluxo de cliente interno e um pedido originado no gateway. Três testes dizem-lhe qual tarefa está mal atribuída sem voltar a abrir a configuração. Acrescente o resultado ao ticket ao lado do campo que alterou, porque o próximo engenheiro encontrará o mesmo perfil.