A verificação de origem/destino é um portão, não todo o caminho VPN
Uma instância de encaminhamento precisa de permissão da AWS, além de rotas Linux e regras de firewall. Verifique a validação de origem/destino na instância que encaminha.
A VPN termina numa instância EC2, você consegue alcançar o endereço de túnel dessa instância, e o tráfego que deveria passar por ela até outro host privado desaparece. São dois testes diferentes, e misturá-los desperdiça horas. O primeiro pergunta se você consegue alcançar a instância; o segundo exige que ela encaminhe tráfego para um destino que não é o seu, o que requer encaminhamento Linux, uma política de firewall, uma rota do outro lado e uma permissão a nível da AWS que não tem nada a ver com o sistema operacional convidado. Nada no console chama a atenção para essa diferença. O sintoma parece uma falha de roteamento, e normalmente não é.
Separe os dois testes antes de mudar qualquer coisa
Alcançar o gateway prova o túnel, a rota até o endereço dele e o grupo de segurança que permite a troca. O encaminhamento para outro host não prova nada disso: usa um endereço de origem diferente, um destino diferente e uma instância num papel para o qual não foi necessariamente construída. Escreva os dois testes separadamente e anote qual falha, porque a correção de cada um está num console diferente. Uma instância de gateway construída apenas para terminar túneis não tem motivo para encaminhar mais nada, e os valores predefinidos refletem isso. Por isso o segundo teste precisa da própria configuração, e não de um pequeno ajuste no primeiro.
Um ping que funciona até o gateway e um ping que falha até o host além dele não são um problema intermitente. É o comportamento esperado de uma instância à qual não foi dito que pode encaminhar.
Escreva o caminho antes de tocar numa definição
Anote o prefixo do cliente, a instância ou interface de rede de encaminhamento, a sub-rede de destino e a rota de resposta. Uma entrada na tabela de rotas da VPC que aponta para uma instância não configura o sistema operacional da instância para encaminhar, e um kernel convidado com encaminhamento ativo não cria uma rota da VPC. As duas pontas dessa relação têm de existir, e são editadas em locais diferentes por pessoas com acessos diferentes.
Depois examine a definição da verificação de origem/destino no componente de encaminhamento real, não em cada instância da VPC. A AWS documenta por que uma instância que encaminha tráfego por outros precisa dessa verificação desativada, e também por que a definição é uma decisão por instância e não um padrão para toda a VPC.
Quatro fronteiras, e a verificação é apenas uma delas
Trate o caminho como quatro perguntas e responda em ordem. A primeira resposta que falha é onde está o trabalho, e nenhuma das outras a compensará.
| Boundary | Question it answers |
|---|---|
| VPC route tables | Do the destinations and replies select the intended gateway? |
| Forwarding instance | Do the AWS check and the guest OS both permit forwarding? |
| Access policy | Do security groups, ACLs and host rules allow the exchange? |
| Destination | Can the service accept that source and return a reply? |
A ordem importa porque verificar é barato: as rotas são visíveis numa página, a verificação é um único atributo, e a opinião do destino costuma ser a última coisa que alguém pergunta.
A tradução muda qual origem o destino vê
Um desenho encaminhado preserva o endereço de origem do cliente, por isso o destino precisa de uma rota de retorno para o prefixo do cliente. Um desenho traduzido apresenta em vez disso o endereço do gateway, o que elimina esse requisito e o substitui por uma tabela de estados no gateway. Decida conforme a arquitetura que pretende, em vez de acrescentar tradução porque um exemplo não relacionado a usou e pareceu funcionar.
Se traduzir, limite a regra ao prefixo do cliente e ao destino pretendido. Se preservar, confirme que o outro lado conhece mesmo a rota, em vez de presumir que aprenderá uma.
Teste a partir do cliente original e depois mantenha a alteração
Um pedido gerado no gateway pode ter sucesso enquanto um pedido encaminhado falha, porque é outra origem e outro caso de encaminhamento. Depois de uma correção dirigida, repita o teste exato de cliente para recurso que falhou, a partir do mesmo cliente, e confirme que a resposta volta e não apenas que o pedido chegou.
Por fim, coloque a definição na configuração gerida do gateway para que uma instância de substituição a receba. Um teste bem-sucedido que depende de uma exceção manual é um teste que expira na próxima reconstrução, e a pessoa que o descobriu não estará lá para se lembrar por quê.