AWS Site-to-Site VPN: utanför, innanför och LAN-prefixet

Tre adressroller blandas ihop på en AWS VPN: de yttre parterna, den inre /30-länken och de skyddade LAN-prefixen. Läs dem i den nedladdade konfigurationen.

De flesta fel med AWS Site-to-Site VPN är adressfel, och de görs innan något paket rör sig. Tunnels yttre adresser når IPsec-parterna, de inre adresserna bildar routinglänken mellan dem, och de skyddade prefixen är vad länken är till för. Kopiera en roll till en annan och tunneln kommer upp medan ingenting routas. Här är ordningen läs-kontrollera-konfigurera som jag använder på en BGP-kundgateway, med värdena från den nedladdade enhetskonfigurationen och inte från minnet.

Tre adressroller, en tunnel

De yttre adresserna är publika och tillhör IPsec-parterna: en per tunnel på AWS-sidan, och kundgatewayens nåbara identitet på din sida, anpassad till den NAT-lösning du faktiskt har. De inre adresserna är privata och tillhör den logiska länken, som AWS dokumenterar som ett /30 hämtat från 169.254.0.0/16. De skyddade prefixen är de VPC-, lokala eller transitnätverk som du routar och annonserar över den länken.

Att tilldela ett LAN-prefix som adress på tunnelgränssnittet är den klassiska varianten av det här felet. Gränssnittet ser konfigurerat ut, LANet annonseras inte, och andra sidan har ingen rutt till det. Tunneln kan till och med klara sin egen inre ping medan varje applikationsnamn får tidsutfall. Referensen för tunnelalternativ listar begränsningarna för det inre CIDR:et, inklusive vilket adressområde det måste komma från.

Läs värdena från den nedladdade konfigurationen

Ladda ner konfigurationen för din specifika enhetsmodell från anslutningen och behandla sedan dess adresstabell som sanningen. Konsolen visar samma värden per tunnel: extern IP, internt CIDR och BGP-partnerns adress på AWS-sidan. De två tunnlarna är separata objekt med separata yttre ändpunkter och separata inre /30, även om båda bär samma skyddade nätverk.

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

Om den nedladdade filen och den live-konsolen inte stämmer överens är filen inaktuell. Ladda ner igen i stället för att redigera adresser för hand, eftersom en avvikelse mellan det inre paret och partnerns konfigurerade granne är ett tyst BGP-fel.

Bygg länken med rätt adress på

På en Linux-gateway är tunneln ett VTI- eller XFRM-gränssnitt, och det inre /30:et läggs på det gränssnittet. Två tunnlar betyder två gränssnitt och två BGP-grannar, en per AWS-ändpunkt. Konventionen som AWS skriver ut i den nedladdade enhetskonfigurationen sätter den virtuella privata gatewayen på den första adressen i varje inre /30 och din kundgateway på den andra, så du tar den högre adressen och peerar med den lägre. Inget här behöver en LAN-adress.

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

Om filen för din enhetsmodell skriver ut det omvända paret, använd dess siffror och håll regeln: adressen på gränssnittet är din, partnerns adress tillhör AWS. Att göra tvärtom ger en tunnel som aldrig når Established, eftersom grannen du konfigurerade är den adress som ditt eget gränssnitt redan har.

Håll markeringen och VTI-nyckeln i linje med det IKE-demonen använder för att binda en underordnad SA till gränssnittet, annars kommer trafiken till tunneln utan ett gränssnitt att landa på. Kontrollera MTU:n mot vägen och mot IKE-demonens egna inställningar i stället för att kopiera en siffra från en annan plats.

Verifiera BGP innan du verifierar rutter

Att IPsec kommer upp bevisar att parterna är överens om en säkerhetsassociation och inget annat. BGP-sessionen är en separat förhandling över den inre länken, så läs grannstatusen och prefixtäljarna och jämför dem sedan med det du tänkte annonsera.

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'

Tillståndet Established med noll mottagna prefix är ett policy- eller annonseringsproblem, inte ett tunnelproblem. Upprepa hela kontrollen på den andra tunneln; en fungerande första tunnel säger att adresserna är rimliga, inte att den andra tunneln ens konfigurerades.

Följ ett routat paket och stanna sedan

När sessionen bär prefixen, testa rutten i båda riktningarna från gatewayen: källadress, nästa hopp och den säkerhetspolicy som tillåter trafiken. En BGP-session kan vara uppe medan det specifika prefix som din applikation behöver är filtrerat, sammanfattat eller pekar på fel gränssnitt.

Reachability Analyzer är verktyget på AWS-sidan som tar en källa, ett mål och en väg, och rapporterar vilken komponent i en konfiguration som stöds som blockerade den. Använd det för att testa vägen från VPC:n till adressen för din kundgateway, inte från en applikationsvärd. Det analyserar konfiguration och skickar inte ett paket genom en lokal brandvägg, så håll dess dom skild från dina egna gränssnittsräknare och paketinspelningar.

Skriv det yttre paret, det inre /30:et och de annonserade prefixen för varje tunnel i en enda tabell. Det är tabellen som gör nästa ändring granskningsbar.

Relaterade artiklar