Extensão do site VPN: siga a rota de retorno além do gateway

O tráfego de uma filial termina num gateway cuja LAN não contém a aplicação a que lhe pediram para chegar. O servidor fica num segundo data center, além de uma ligação interna que a VPN nunca configurou. Acrescentar outro prefixo ao gateway próximo não faz nada para esse caso, porque o gateway remoto é um ponto final de cifra e não o último router. O caminho precisa de uma rota em frente, de uma admissão na fronteira de segurança remota e de uma decisão de retorno na própria rede do destino.

O gateway remoto é um ponto final de cifra

O IPsec entre gateways protege o tráfego entre dois dispositivos de segurança, e os endereços internos viajam cifrados por esse segmento. Para além do gateway remoto, assume o encaminhamento comum, incluindo qualquer política que exista entre data centers. O segmento protegido cobre, portanto, parte da viagem e não o resto. Assumir o contrário é como um projeto acaba com um túnel saudável e uma aplicação inalcançável.

Desenhe o caminho em três partes: filial para gateway próximo, próximo para remoto, remoto para a aplicação. Cada parte tem o seu dono e o seu modo de falha.

Leia as duas direções da política do túnel

Uma política de túnel costuma ser escrita na perspetiva do lado local, e é desse hábito que vêm as configurações parciais. Ambos os pares têm de listar a origem da filial e o destino tal como aparecerão dentro do túnel, incluindo qualquer tradução que o projeto pretenda. Atualizar apenas a extremidade próxima produz um desalinhamento de fase dois que parece uma falha de encaminhamento. Compare os dois conjuntos de políticas antes de tocar em qualquer rota.

Escreva origem e destino como endereços em vez de nomes de site. A ambiguidade aqui reaparece mais tarde como uma assimetria desconcertante.

Acrescente a rota em frente e confirme a admissão

O gateway remoto precisa de uma rota para a sub-rede da aplicação, e cada router entre eles tem de admitir a origem da filial. Verifique o que o gateway remoto tem realmente em vez do que o diagrama afirma.

ip route get 10.30.5.10 from 10.10.1.50
traceroute -n -s 10.10.1.50 10.30.5.10

O primeiro comando indica a interface de saída e o próximo salto que o gateway remoto escolheria para essa origem, uma pergunta a que uma tabela de encaminhamento comum não consegue responder. O traçado mostra onde os pacotes param, e uma quebra depois do gateway remoto aponta para trânsito interno e não para o túnel. Quando a rota existe e o tráfego continua a desaparecer, capture no gateway remoto e leia o endereço de origem que chega, porque um endereço inesperado significa que há tradução a acontecer em algum lugar não planeado. Todos os endereços aqui são marcadores, por isso substitua pelas sub-redes reais de filial, trânsito e aplicação.

Teste a partir da filial e depois volte a testar o caminho antigo

A aceitação precisa de uma origem real e não de uma sonda a partir do gateway remoto. Execute a verificação a partir de um anfitrião da filial e mantenha os destinos que já funcionavam no mesmo teste.

curl -sS -m 5 http://10.30.5.10:8080/health
ping -c 3 10.20.1.1

Uma resposta da aplicação prova o caminho de ida e o de volta em conjunto, enquanto o ping ao destino antigo prova que a alteração não quebrou o que já funcionava. Registe o endereço de origem que a aplicação registra, porque as suas regras de acesso e qualquer rota de retorno têm de corresponder a esse valor. Onde a filial traduz antes do túnel, o endereço da política e o endereço que a aplicação vê diferem por conceção, por isso registe ambos. Repita o teste após uma renovação de chave ou uma alteração de encaminhamento, porque estes caminhos costumam ser validados uma vez e depois esquecidos.

Atribua um dono a cada um dos três segmentos e à rota de retorno dentro da rede de destino. Um caminho com quatro donos falha nas lacunas entre eles.