AWS Site-to-Site VPN: exterior, interior e o prefixo LAN

A maioria dos erros no AWS Site-to-Site VPN são erros de endereço, e são cometidos antes de qualquer pacote se mover. Os endereços externos do túnel alcançam os pares IPsec, os internos formam a ligação de roteamento entre eles, e os prefixos protegidos são aquilo para que essa ligação serve. Copie um papel no outro e o túnel sobe enquanto nada é roteado. Esta é a sequência leia-verifique-configure que uso num gateway de cliente BGP, com os valores tirados da configuração do dispositivo descarregada, não da memória.

Três papéis de endereço, um túnel

Os endereços externos são públicos e pertencem aos pares IPsec: um por túnel do lado da AWS, e a identidade alcançável do gateway de cliente do seu lado, ajustada à disposição de NAT que realmente tem. Os endereços internos são privados e pertencem à ligação lógica, que a AWS documenta como um /30 retirado de 169.254.0.0/16. Os prefixos protegidos são as redes VPC, locais ou de trânsito que encaminha e anuncia por essa ligação.

Atribuir um prefixo LAN como endereço da interface do túnel é a versão clássica deste erro. A interface parece configurada, a LAN não é anunciada, e o lado oposto não tem rota para ela. O túnel pode até passar o seu próprio ping interno enquanto todos os nomes de aplicação expiram. A referência de opções do túnel lista as restrições do CIDR interno, incluindo o intervalo de endereços de onde tem de vir.

Leia os valores na configuração descarregada

Descarregue a configuração para o seu modelo de dispositivo concreto a partir da ligação e depois trate a sua tabela de endereços como fonte de verdade. A consola mostra os mesmos valores por túnel: IP externo, CIDR interno e o endereço do par BGP do lado da AWS. Os dois túneis são objetos separados com pontos finais externos separados e /30 internos separados, embora ambos transportem as mesmas redes protegidas.

aws ec2 describe-vpn-connections --vpn-connection-ids vpn-0123456789abcdef0 \
  --query 'VpnConnections[0].Options.TunnelOptions[].[OutsideIpAddress,TunnelInsideCidr]'
aws ec2 describe-customer-gateways --customer-gateway-ids cgw-0123456789abcdef0 \
  --query 'CustomerGateways[0].[IpAddress,BgpAsn]'

Se o ficheiro descarregado e a consola em direto não coincidirem, o ficheiro está desatualizado. Descarregue de novo em vez de editar endereços à mão, porque uma discrepância entre o par interno e o vizinho configurado do par é uma falha silenciosa de BGP.

Construa a ligação com o endereço correto

Num gateway Linux o túnel é uma interface VTI ou XFRM, e o /30 interno vai nessa interface. Dois túneis significam duas interfaces e dois vizinhos BGP, um por ponto final da AWS. A convenção que a AWS imprime na configuração do dispositivo descarregada coloca o gateway privado virtual no primeiro endereço de cada /30 interno e o seu gateway de cliente no segundo, pelo que toma o endereço mais alto e faz peering com o mais baixo. Nada aqui precisa de um endereço LAN.

ip tunnel add tun0 mode vti local 203.0.113.10 remote 18.230.1.1 key 42
ip addr add 169.254.10.2/30 dev tun0
ip link set tun0 up mtu 1400
ip tunnel add tun1 mode vti local 203.0.113.10 remote 18.230.2.1 key 43
ip addr add 169.254.10.6/30 dev tun1
ip link set tun1 up mtu 1400

Se o ficheiro do seu modelo de dispositivo imprimir o emparelhamento oposto, use os números dele e mantenha a regra: o endereço na interface é seu, o endereço do par pertence à AWS. Fazer o contrário produz um túnel que nunca chega a Established, porque o vizinho que configurou é o endereço que a sua própria interface já tem.

Mantenha a marca e a chave VTI alinhadas com o que o daemon IKE usa para ligar uma SA filha à interface, ou o tráfego chega ao túnel sem interface onde aterrar. Verifique a MTU contra o caminho e contra as próprias definições do daemon IKE em vez de copiar um número de outro sítio.

Verifique o BGP antes de verificar as rotas

O facto de o IPsec subir prova que os pares concordam numa associação de segurança e nada mais. A sessão BGP é uma negociação à parte sobre a ligação interna, por isso leia o estado do vizinho e os contadores de prefixos e compare-os com o que pretendia anunciar.

ip -s addr show dev tun0
vtysh -c 'show bgp summary'
vtysh -c 'show bgp neighbors 169.254.10.1'
vtysh -c 'show ip bgp neighbors 169.254.10.1 advertised-routes'

O estado Established com zero prefixos recebidos é um problema de política ou de anúncio, não do túnel. Repita toda a verificação no segundo túnel; um primeiro túnel a funcionar diz-lhe que os endereços são plausíveis, não que o segundo túnel esteja configurado.

Siga um pacote encaminhado e depois pare

Assim que a sessão transporta os prefixos, teste a rota nos dois sentidos a partir do gateway: endereço de origem, próximo salto e a política de segurança que permite o tráfego. Uma sessão BGP pode estar ativa enquanto o prefixo concreto de que a sua aplicação precisa está filtrado, resumido ou a apontar para a interface errada.

O Reachability Analyzer é a ferramenta do lado da AWS que recebe uma origem, um destino e um caminho, e relata que componente numa configuração suportada o bloqueou. Use-a para testar o caminho da VPC até ao endereço do seu gateway de cliente, não a partir de um host de aplicação. Analisa configuração e não envia um pacote através de uma firewall local, por isso mantenha o veredicto separado dos seus próprios contadores de interface e capturas de pacotes.

Registe o par externo, o /30 interno e os prefixos anunciados de cada túnel numa única tabela. É essa tabela que torna a alteração seguinte revisível.