AWS Site-to-Site VPN: buiten, binnen en het LAN-prefix

De meeste fouten bij AWS Site-to-Site VPN zijn adresfouten, en ze worden gemaakt voordat er ook maar één pakket beweegt. De buitenadressen van de tunnel bereiken de IPsec-peers, de binnenadressen vormen de routeringslink daartussen, en de beschermde prefixen zijn waar die link voor dient. Kopieer de ene rol in de andere en de tunnel komt omhoog terwijl er niets routeert. Dit is de lees-controleer-configureer-volgorde die ik op een BGP-customer-gateway gebruik, met de waarden uit de gedownloade apparaatconfiguratie in plaats van uit het geheugen.

Drie adresrollen, één tunnel

De buitenadressen zijn openbaar en horen bij de IPsec-peers: één per tunnel aan de AWS-kant, en de bereikbare identiteit van de customer gateway aan jouw kant, aangepast aan de NAT-opstelling die je echt hebt. De binnenadressen zijn privé en horen bij de logische link, die AWS documenteert als een /30 uit 169.254.0.0/16. De beschermde prefixen zijn de VPC-, on-premises of transitnetwerken die je over die link routeert en adverteert.

Een LAN-prefix toewijzen als adres van de tunnelinterface is de klassieke versie van deze fout. De interface lijkt geconfigureerd, het LAN wordt niet geadverteerd, en de andere kant heeft er geen route voor. De tunnel kan zelfs zijn eigen interne ping halen terwijl elke applicatienaam een time-out krijgt. De referentie voor tunnelopties somt de beperkingen van de interne CIDR op, inclusief het adresbereik waaruit die moet komen.

Lees de waarden uit de gedownloade configuratie

Download de configuratie voor jouw specifieke apparaatmodel via de verbinding en behandel de adrestabel ervan als de bron van waarheid. De console toont dezelfde waarden per tunnel: buiten-IP, interne CIDR en het BGP-peeradres aan de AWS-kant. De twee tunnels zijn aparte objecten met aparte buitenste eindpunten en aparte interne /30's, ook al dragen beide dezelfde beschermde netwerken.

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]'

Als het gedownloade bestand en de live console niet overeenkomen, is het bestand verouderd. Download opnieuw in plaats van adressen met de hand te bewerken, want een mismatch tussen het interne paar en de geconfigureerde buur van de peer is een stille BGP-fout.

Bouw de link met het juiste adres erop

Op een Linux-gateway is de tunnel een VTI- of XFRM-interface, en het interne /30 gaat op die interface. Twee tunnels betekenen twee interfaces en twee BGP-buren, één per AWS-eindpunt. De conventie die AWS in de gedownloade apparaatconfiguratie afdrukt, zet de virtuele privégateway op het eerste adres van elk intern /30 en jouw customer gateway op het tweede, dus je neemt het hogere adres en peert met het lagere. Niets hier heeft een LAN-adres nodig.

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

Als het bestand voor jouw apparaatmodel het omgekeerde paar afdrukt, gebruik dan de getallen ervan en houd de regel vast: het adres op de interface is van jou, het peeradres hoort bij AWS. Andersom levert een tunnel op die nooit Established bereikt, omdat de buur die je hebt geconfigureerd het adres is dat je eigen interface al heeft.

Houd de mark en de VTI-sleutel gelijk met wat de IKE-daemon gebruikt om een child-SA aan de interface te binden, anders arriveert verkeer op de tunnel zonder interface om op te landen. Controleer de MTU tegen het pad en tegen de eigen instellingen van de IKE-daemon in plaats van een getal van een andere site te kopiëren.

Controleer BGP voordat je routes controleert

Dat IPsec omhoog komt bewijst dat de peers het eens zijn over een beveiligingsassociatie en niets anders. De BGP-sessie is een aparte onderhandeling over de interne link, dus lees de buurstatus en de prefixtellers en vergelijk ze met wat je van plan was te adverteren.

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'

De status Established met nul ontvangen prefixen is een beleids- of advertentieprobleem, geen tunnelprobleem. Herhaal de hele controle op de tweede tunnel; een werkende eerste tunnel zegt dat de adressen plausibel zijn, niet dat de tweede tunnel überhaupt is geconfigureerd.

Volg een gerouteerd pakket en stop dan

Zodra de sessie de prefixen draagt, test de route in beide richtingen vanaf de gateway: bronadres, volgende hop en het beveiligingsbeleid dat het verkeer toestaat. Een BGP-sessie kan omhoog zijn terwijl het specifieke prefix dat je applicatie nodig heeft wordt gefilterd, weggesummariseerd of naar de verkeerde interface wijst.

Reachability Analyzer is het hulpmiddel aan de AWS-kant dat een bron, een bestemming en een pad neemt, en rapporteert welke component in een ondersteunde configuratie het heeft geblokkeerd. Gebruik het om het pad van de VPC naar het adres van je customer gateway te testen, niet vanaf een applicatiehost. Het analyseert configuratie en stuurt geen pakket door een lokale firewall, dus houd het oordeel gescheiden van je eigen interfacetellers en pakketopnames.

Leg het buitenpaar, het interne /30 en de geadverteerde prefixen voor elke tunnel vast in één tabel. Die tabel maakt de volgende wijziging beoordeelbaar.