AWS Site-to-Site VPN: esterno, interno e il prefisso LAN

La maggior parte degli errori su AWS Site-to-Site VPN sono errori di indirizzo, e si commettono prima che si muova un solo pacchetto. Gli indirizzi esterni del tunnel raggiungono i peer IPsec, gli indirizzi interni formano il collegamento di routing tra loro, e i prefissi protetti sono lo scopo di quel collegamento. Copiate un ruolo nell’altro e il tunnel sale mentre nulla viene instradato. Ecco la sequenza leggi-verifica-configura che uso su un gateway client BGP, con i valori presi dalla configurazione del dispositivo scaricata anziché dalla memoria.

Tre ruoli di indirizzo, un tunnel

Gli indirizzi esterni sono pubblici e appartengono ai peer IPsec: uno per tunnel sul lato AWS, e l’identità raggiungibile del gateway client sul vostro lato, adattata alla disposizione NAT che avete davvero. Gli indirizzi interni sono privati e appartengono al collegamento logico, che AWS documenta come un /30 preso da 169.254.0.0/16. I prefissi protetti sono le reti VPC, locali o di transito che instradate e annunciate su quel collegamento.

Assegnare un prefisso LAN come indirizzo dell’interfaccia del tunnel è la versione classica di questo errore. L’interfaccia sembra configurata, la LAN non viene annunciata, e il lato remoto non ha una rotta per essa. Il tunnel può persino superare il proprio ping interno mentre ogni nome applicativo va in timeout. Il riferimento alle opzioni del tunnel elenca i vincoli del CIDR interno, compreso l’intervallo di indirizzi da cui deve provenire.

Leggete i valori dalla configurazione scaricata

Scaricate la configurazione per il vostro modello di dispositivo specifico dalla connessione, poi trattate la sua tabella degli indirizzi come fonte di verità. La console mostra gli stessi valori per tunnel: IP esterno, CIDR interno e l’indirizzo del peer BGP sul lato AWS. I due tunnel sono oggetti separati con endpoint esterni separati e /30 interni separati, anche se entrambi trasportano le stesse reti protette.

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 il file scaricato e la console live non concordano, il file è obsoleto. Riscaricate invece di modificare gli indirizzi a mano, perché una discrepanza tra la coppia interna e il vicino configurato del peer è un guasto BGP silenzioso.

Costruite il collegamento con l’indirizzo giusto sopra

Su un gateway Linux il tunnel è un’interfaccia VTI o XFRM, e il /30 interno va su quell’interfaccia. Due tunnel significano due interfacce e due vicini BGP, uno per endpoint AWS. La convenzione che AWS stampa nella configurazione del dispositivo scaricata mette il gateway privato virtuale sul primo indirizzo di ogni /30 interno e il vostro gateway client sul secondo, quindi prendete l’indirizzo più alto e fate peering con quello più basso. Nulla qui ha bisogno di un indirizzo 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 il file per il vostro modello di dispositivo stampa l’accoppiamento opposto, usate i suoi numeri e tenete la regola: l’indirizzo sull’interfaccia è vostro, l’indirizzo del peer appartiene ad AWS. Farlo al contrario produce un tunnel che non raggiunge mai Established, perché il vicino che avete configurato è l’indirizzo che la vostra interfaccia già possiede.

Tenete il mark e la chiave VTI allineati a ciò che il demone IKE usa per legare una SA figlia all’interfaccia, altrimenti il traffico arriva sul tunnel senza un’interfaccia su cui atterrare. Controllate l’MTU rispetto al percorso e rispetto alle impostazioni del demone IKE invece di copiare un numero da un altro sito.

Verificate BGP prima di verificare le rotte

Il fatto che IPsec salga dimostra che i peer concordano su un’associazione di sicurezza e nulla più. La sessione BGP è una negoziazione separata sul collegamento interno, quindi leggete lo stato del vicino e i contatori dei prefissi, poi confrontateli con ciò che intendevate annunciare.

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'

Lo stato Established con zero prefissi ricevuti è un problema di policy o di annuncio, non del tunnel. Ripetete l’intera verifica sul secondo tunnel; un primo tunnel funzionante vi dice che gli indirizzi sono plausibili, non che il secondo tunnel sia stato configurato.

Seguite un pacchetto instradato, poi fermatevi

Quando la sessione trasporta i prefissi, provate la rotta in entrambe le direzioni dal gateway: indirizzo sorgente, next hop e la policy di sicurezza che consente il traffico. Una sessione BGP può essere attiva mentre il prefisso specifico che serve alla vostra applicazione è filtrato, riepilogato o puntato all’interfaccia sbagliata.

Reachability Analyzer è lo strumento lato AWS che prende una sorgente, una destinazione e un percorso, e riferisce quale componente in una configurazione supportata lo ha bloccato. Usatelo per testare il percorso dal VPC all’indirizzo del vostro gateway client, non da un host applicativo. Analizza la configurazione e non invia un pacchetto attraverso un firewall locale, quindi tenete il suo verdetto separato dai vostri contatori di interfaccia e dalle catture di pacchetti.

Registrate la coppia esterna, il /30 interno e i prefissi annunciati per ogni tunnel in un’unica tabella. È quella tabella che rende rivedibile la modifica successiva.