AWS Site-to-Site VPN: utenfor, innenfor og LAN-prefikset

Tre adresseroller blandes på én AWS VPN: eksterne partnere, den interne /30-lenken og de beskyttede LAN-prefiksene. Les dem i den nedlastede konfigurasjonen.

De fleste feilene med AWS Site-to-Site VPN er adressefeil, og de gjøres før noen pakke beveger seg. Tunnellens ytre adresser når IPsec-partnerne, de indre adressene utgjør rutingslenken mellom dem, og de beskyttede prefiksene er det lenken er til for. Kopier én rolle inn i en annen, og tunnelen kommer opp mens ingenting rutes. Her er rekkefølgen les-kontroller-konfigurer som jeg bruker på en BGP-kundegateway, med verdiene hentet fra den nedlastede enhetskonfigurasjonen og ikke fra hukommelsen.

Tre adresseroller, én tunnel

De ytre adressene er offentlige og tilhører IPsec-partnerne: én per tunnel på AWS-siden, og kundegatewayens tilgjengelige identitet på din side, tilpasset det NAT-oppsettet du faktisk har. De indre adressene er private og tilhører den logiske lenken, som AWS dokumenterer som et /30 hentet fra 169.254.0.0/16. De beskyttede prefiksene er VPC-, lokale eller transitnettverk som du ruter og annonserer over den lenken.

Å tildele et LAN-prefiks som adresse på tunnelgrensesnittet er den klassiske varianten av denne feilen. Grensesnittet ser konfigurert ut, LAN-et annonseres ikke, og den andre siden har ingen rute til det. Tunnelen kan til og med bestå sin egen interne ping mens hvert applikasjonsnavn timer ut. Referansen for tunnelvalg lister begrensningene for den interne CIDR-en, inkludert adresseområdet den må komme fra.

Les verdiene fra den nedlastede konfigurasjonen

Last ned konfigurasjonen for din spesifikke enhetsmodell fra tilkoblingen, og behandle adressetabellen som sannhetskilden. Konsollen viser de samme verdiene per tunnel: ekstern IP, intern CIDR og BGP-partnerens adresse på AWS-siden. De to tunnelene er separate objekter med separate eksterne endepunkter og separate interne /30-er, selv om begge bærer de samme beskyttede nettene.

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 nedlastede filen og den direkte konsollen ikke stemmer, er filen utdatert. Last ned på nytt i stedet for å redigere adresser for hånd, fordi avvik mellom det interne paret og partnerens konfigurerte nabo er en stille BGP-feil.

Bygg lenken med riktig adresse på

På en Linux-gateway er tunnelen et VTI- eller XFRM-grensesnitt, og det interne /30-et legges på det grensesnittet. To tunneler betyr to grensesnitt og to BGP-naboer, én per AWS-endepunkt. Konvensjonen AWS skriver ut i den nedlastede enhetskonfigurasjonen setter den virtuelle private gatewayen på den første adressen i hvert interne /30 og kundegatewayen din på den andre, så du tar den høyere adressen og peerer med den lavere. Ingenting her trenger 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 for enhetsmodellen din skriver ut det motsatte paret, bruk tallene dens og hold regelen: adressen på grensesnittet er din, partneradressen tilhører AWS. Å gjøre det motsatt gir en tunnel som aldri når Established, fordi naboen du konfigurerte er adressen ditt eget grensesnitt allerede har.

Hold markereringen og VTI-nøkkelen i tråd med det IKE-demonen bruker for å binde en underordnet SA til grensesnittet, ellers kommer trafikken til tunnelen uten et grensesnitt å lande på. Kontroller MTU-en mot stien og mot IKE-demonens egne innstillinger i stedet for å kopiere et tall fra et annet sted.

Bekreft BGP før du bekrefter ruter

At IPsec kommer opp beviser at partnerne er enige om en sikkerhetsassosiasjon og ingenting annet. BGP-økten er en separat forhandling over den interne lenken, så les nabostatusen og prefikstellerne, og sammenlign dem med det du hadde tenkt å annonsere.

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 null mottatte prefikser er et policy- eller annonseringsproblem, ikke et tunnelproblem. Gjenta hele kontrollen på den andre tunnelen; en tunnel som virker forteller deg at adressene er plausible, ikke at den andre tunnelen ble konfigurert i det hele tatt.

Følg en rutet pakke, og stopp så

Når økten bærer prefiksene, test ruten i begge retninger fra gatewayen: kildeadresse, neste hopp og sikkerhetspolicyen som tillater trafikken. En BGP-økt kan være oppe mens det konkrete prefikset applikasjonen din trenger er filtrert, oppsummert bort eller peker på feil grensesnitt.

Reachability Analyzer er verktøyet på AWS-siden som tar en kilde, en destinasjon og en sti, og rapporterer hvilken komponent i en støttet konfigurasjon som blokkerte den. Bruk det til å teste stien fra VPC-en til kundegatewayadressen din, ikke fra en applikasjonsvert. Det analyserer konfigurasjon og sender ikke en pakke gjennom en lokal brannmur, så hold dommen atskilt fra dine egne grensesnitttellere og pakkeopptak.

Skriv det ytre paret, det interne /30-et og de annonserte prefiksene for hver tunnel i én tabell. Det er tabellen som gjør den neste endringen gjennomgåelig.

Relaterte artikler