AWS Site-to-Site VPN: enderezos externos, internos e o prefixo LAN

A maioría dos erros de AWS Site-to-Site VPN son erros de enderezos, e cométense antes de que se mova ningún paquete. Os enderezos externos do túnel chegan aos pares IPsec, os internos forman a ligazón de encamiñamento entre eles, e os prefixos protexidos son para o que serve esa ligazón. Copie un rol noutro e o túnel érguense mentres non se encamiña nada. Esta é a secuencia le-comproba-configura que uso nunha pasarela de cliente BGP, cos valores tomados da configuración do dispositivo descargada, non da memoria.

Tres roles de enderezo, un túnel

Os enderezos externos son públicos e pertencen aos pares IPsec: un por túnel no lado de AWS, e a identidade alcanzable da pasarela de cliente no seu lado, axustada á disposición de NAT que realmente teña. Os enderezos internos son privados e pertencen á ligazón lóxica, que AWS documenta como un /30 extraído de 169.254.0.0/16. Os prefixos protexidos son as redes VPC, locais ou de tránsito que encamiña e anuncia por esa ligazón.

Asignar un prefixo LAN como enderezo da interface do túnel é a versión clásica deste erro. A interface parece configurada, a LAN non se anuncia e o lado oposto non ten ruta cara a ela. O túnel pode mesmo pasar o seu propio ping interno mentres cada nome de aplicación esgota o tempo. A referencia de opcións do túnel enumera as restricións do CIDR interno, incluído o rango de enderezos do que debe provir.

Lea os valores da configuración descargada

Descargue a configuración do seu modelo de dispositivo concreto desde a conexión e logo trate a súa táboa de enderezos como fonte de verdade. A consola mostra os mesmos valores por túnel: IP externa, CIDR interno e o enderezo do par BGP no lado de AWS. Os dous túneles son obxectos separados con extremos externos separados e /30 internos separados, aínda que ambos transportan as mesmas redes protexidas.

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 descargado e a consola en vivo non coinciden, o ficheiro está desactualizado. Volva descargalo en lugar de editar enderezos a man, porque unha discrepancia entre o par interno e o veciño configurado do par é un fallo silencioso de BGP.

Constrúa a ligazón co enderezo correcto

Nunha pasarela Linux o túnel é unha interface VTI ou XFRM, e o /30 interno vai nesa interface. Dous túneles significan dúas interfaces e dous veciños BGP, un por punto de enlace de AWS. A convención que AWS imprime na configuración do dispositivo descargada pon a pasarela privada virtual no primeiro enderezo de cada /30 interno e a súa pasarela de cliente no segundo, así que toma o enderezo máis alto e fai peering co máis baixo. Nada aquí necesita un enderezo 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 imprime o emparellamento oposto, use os seus números e manteña a regra: o enderezo da interface é seu, o enderezo do par pertence a AWS. Facelo ao revés produce un túnel que nunca alcanza Established, porque o veciño que configurou é o enderezo que a súa propia interface xa ten.

Manteña a marca e a clave VTI aliñadas co que usa o demo IKE para ligar unha SA filla á interface, ou o tráfico chega ao túnel sen unha interface onde aterrar. Comprobe a MTU contra a ruta e contra os propios axustes do demo IKE en lugar de copiar un número doutro sitio.

Verifique BGP antes de verificar as rutas

Que IPsec se levante demostra que os pares acordan unha asociación de seguridade e nada máis. A sesión BGP é unha negociación aparte sobre a ligazón interna, así que lea o estado do veciño e os contadores de prefixos, e logo compáreos co que pretendía 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 con cero prefixos recibidos é un problema de política ou de anuncio, non do túnel. Repita toda a comprobación no segundo túnel; un primeiro túnel que funciona dille que os enderezos son plausibles, non que o segundo túnel estea configurado.

Siga un paquete encamiñado e logo detéñase

Unha vez que a sesión transporta os prefixos, probe a ruta en ambos os sentidos desde a pasarela: enderezo de orixe, seguinte salto e a política de seguridade que permite o tráfico. Unha sesión BGP pode estar activa mentres o prefixo concreto que necesita a súa aplicación está filtrado, resumido ou apuntando á interface equivocada.

Reachability Analyzer é a ferramenta do lado de AWS que toma unha orixe, un destino e unha ruta, e informa que compoñente dunha configuración compatible o bloqueou. Úsea para probar a ruta da VPC ao enderezo da súa pasarela de cliente, non desde un host de aplicación. Analiza configuración e non envía un paquete por un cortalumes local, así que manteña o seu veredicto separado dos seus propios contadores de interface e capturas de paquetes.

Rexistre o par externo, o /30 interno e os prefixos anunciados de cada túnel nunha soa táboa. Esa táboa é o que fai revisable o seguinte cambio.