AWS Site-to-Site VPN: uden for, inden for og LAN-præfikset

De fleste fejl med AWS Site-to-Site VPN er adressefejl, og de begås før nogen pakke bevæger sig. Tunnellens eksterne adresser når IPsec-partnerne, de interne adresser udgør routing-forbindelsen mellem dem, og de beskyttede præfikser er dét, forbindelsen er der for. Kopiér én rolle ind i en anden, og tunnelen kommer op, mens intet routes. Her er rækkefølgen læs-kontrollér-konfigurér, som jeg bruger på en BGP-kundegateway, med værdierne taget fra den downloadede enhedskonfiguration og ikke fra hukommelsen.

Tre adresseroller, én tunnel

De eksterne adresser er offentlige og tilhører IPsec-partnerne: én pr. tunnel på AWS-siden, og kundegatewayens tilgængelige identitet på din side, tilpasset det NAT-arrangement du faktisk har. De interne adresser er private og tilhører den logiske forbindelse, som AWS dokumenterer som et /30 taget fra 169.254.0.0/16. De beskyttede præfikser er de VPC-, lokale eller transitnetværk, som du router og annoncerer over den forbindelse.

At tildele et LAN-præfiks som tunnelinterfacens adresse er den klassiske udgave af denne fejl. Interfacet ser konfigureret ud, LAN’et annonceres ikke, og den anden side har ingen rute til det. Tunnelen kan endda bestå sin egen interne ping, mens hvert applikationsnavn timer ud. Referencen for tunnelindstillinger opremser begrænsningerne for det interne CIDR, herunder det adresseområde, det skal komme fra.

Læs værdierne fra den downloadede konfiguration

Download konfigurationen til din specifikke enhedsmodel fra forbindelsen, og behandl derefter dens adressetabel som sandhedskilde. Konsollen viser de samme værdier pr. tunnel: ekstern IP, internt CIDR og BGP-partnerens adresse på AWS-siden. De to tunneler er separate objekter med separate eksterne endepunkter og separate interne /30’er, selv om begge bærer de samme beskyttede netværk.

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

Hvis den downloadede fil og den live konsol er uenige, er filen forældet. Download igen i stedet for at redigere adresser manuelt, fordi uoverensstemmelse mellem det interne par og partnerens konfigurerede nabo er en tavs BGP-fejl.

Byg forbindelsen med den rigtige adresse på

På en Linux-gateway er tunnelen et VTI- eller XFRM-interface, og det interne /30 lægges på det interface. To tunneler betyder to interfaces og to BGP-naboer, én pr. AWS-endepunkt. Den konvention, AWS trykker i den downloadede enhedskonfiguration, sætter den virtuelle private gateway på den første adresse i hvert interne /30 og din kundegateway på den anden, så du tager den højere adresse og peering med den lavere. Intet her har brug for en LAN-adresse.

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

Hvis filen til din enhedsmodel trykker det omvendte par, brug dens tal og hold reglen: adressen på interfacet er din, partneradressen tilhører AWS. At gøre det omvendt giver en tunnel, der aldrig når Established, fordi den nabo, du konfigurerede, er den adresse, dit eget interface allerede har.

Hold markeringen og VTI-nøglen på linje med det, IKE-dæmonen bruger til at binde en underordnet SA til interfacet, ellers ankommer trafikken på tunnelen uden et interface at lande på. Kontrollér MTU’en mod stien og mod IKE-dæmonens egne indstillinger i stedet for at kopiere et tal fra et andet sted.

Bekræft BGP, før du bekræfter ruter

At IPsec kommer op beviser, at partnerne er enige om en sikkerhedsassociation og intet andet. BGP-sessionen er en separat forhandling over den interne forbindelse, så læs nabostatus og præfikstællere, og sammenlign dem med det, du havde til hensigt at annoncere.

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'

Tilstanden Established med nul modtagne præfikser er et politik- eller annonceringsproblem, ikke et tunnelproblem. Gentag hele kontrollen på den anden tunnel; en fungerende første tunnel fortæller dig, at adresserne er plausible, ikke at den anden tunnel overhovedet blev konfigureret.

Følg en rutet pakke, og stop så

Når sessionen bærer præfikserne, test ruten i begge retninger fra gatewayen: kildeadresse, næste hop og den sikkerhedspolitik, der tillader trafikken. En BGP-session kan være oppe, mens det konkrete præfiks, din applikation har brug for, er filtreret, opsummeret væk eller peger på det forkerte interface.

Reachability Analyzer er AWS-sidens værktøj, der tager en kilde, en destination og en sti og rapporterer, hvilken komponent i en understøttet konfiguration der blokerede den. Brug det til at teste stien fra VPC’en til din kundegatewayadresse, ikke fra en applikationsvært. Det analyserer konfiguration og sender ikke en pakke gennem en lokal firewall, så hold dets dom adskilt fra dine egne interfacetællere og pakkeoptagelser.

Skriv det eksterne par, det interne /30 og de annoncerede præfikser for hver tunnel i én tabel. Det er den tabel, der gør den næste ændring gennemskuelig.