AWS Site-to-Site VPN: utanfor, innanfor og LAN-prefikset

Dei fleste feila med AWS Site-to-Site VPN er adressefeil, og dei blir gjorde før nokon pakke flyttar seg. Dei ytre adressene til tunnelen når IPsec-partnarane, dei indre adressene utgjer rutelenkja mellom dei, og dei verna prefiksa er det lenkja er til for. Kopier éi rolle inn i ei anna, og tunnelen kjem opp medan ingenting blir ruta. Her er rekkjefølgja les-kontroller-konfigurer som eg brukar på ein BGP-kundegateway, med verdiane henta frå den nedlasta einingsoppsetninga og ikkje frå minnet.

Tre adresseroller, ein tunnel

Dei ytre adressene er offentlege og høyrer til IPsec-partnarane: éi per tunnel på AWS-sida, og den tilgjengelege identiteten til kundegatewayen på di side, tilpassa det NAT-oppsettet du faktisk har. Dei indre adressene er private og høyrer til den logiske lenkja, som AWS dokumenterer som ein /30 henta frå 169.254.0.0/16. Dei verna prefiksa er VPC-, lokale eller transitnettverk som du rutar og annonserer over den lenkja.

Å tildela eit LAN-prefiks som adresse på tunne grensesnittet er den klassiske varianten av denne feilen. Grensesnittet ser konfigurert ut, LAN-et blir ikkje annonsert, og den andre sida har inga rute til det. Tunnelen kan til og med klara sin eigen interne ping medan kvart applikasjonsnamn får tidsavbrot. Referansen for tunnelval listar avgrensingane for den interne CIDR-en, mellom anna adresseområdet han må kome frå.

Les verdiane frå den nedlasta oppsetninga

Last ned oppsetninga for din spesifikke einingsmodell frå tilkoplinga, og handsam adressetabellen som sanninga. Konsollen viser dei same verdiane per tunnel: ekstern IP, intern CIDR og adressa til BGP-partnaren på AWS-sida. Dei to tunnelane er separate objekt med separate eksterne endepunkt og separate interne /30-ar, sjølv om begge ber dei same verna netta.

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

Viss den nedlasta fila og den direkte konsollen ikkje stemmer, er fila utdatert. Last ned på nytt i staden for å redigera adresser for hand, fordi avvik mellom det interne paret og den konfigurerte naboen til partnaren er ein stille BGP-feil.

Bygg lenkja med rett adresse på

På ein Linux-gateway er tunnelen eit VTI- eller XFRM-grensesnitt, og det interne /30-et blir lagt på det grensesnittet. To tunnelar tyder to grensesnitt og to BGP-nabbar, éin per AWS-endepunkt. Konvensjonen AWS skriv ut i den nedlasta einingsoppsetninga set den virtuelle private gatewayen på den første adressa i kvart interne /30 og kundegatewayen din på den andre, så du tek den høgste adressa og peerar med den lågaste. Ingenting her treng ei 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

Viss fila for einingsmodellen din skriv ut det motsette paret, bruk tala hennar og hald regelen: adressa på grensesnittet er di, partnaradressa høyrer til AWS. Å gjera det motsette gir ein tunnel som aldri når Established, fordi naboen du konfigurerte er adressa di eige grensesnitt allereie har.

Hald markeringa og VTI-nøkkelen i takt med det IKE-demonen brukar for å binda ein underordna SA til grensesnittet, elles kjem trafikken til tunnelen utan eit grensesnitt å landa på. Kontroller MTU-en mot stien og mot IKE-demonen sine eigne innstillingar i staden for å kopiera eit tal frå ein annan stad.

Stadfest BGP før du stadfestar ruter

At IPsec kjem opp beviser at partnarane er samde om ein tryggingsassosiasjon og ingenting anna. BGP-økta er ei separat forhandling over den interne lenkja, så les nabostatusen og prefiksteljarane, og samanlikn dei med det du hadde tenkt å 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'

Tilstanden Established med null mottekne prefiks er eit policy- eller annonseringsproblem, ikkje eit tunnelproblem. Gjenta heile kontrollen på den andre tunnelen; ein tunnel som verkar fortel deg at adressene er trulege, ikkje at den andre tunnelen vart konfigurert i det heile.

Følg ein ruta pakke, og stopp så

Når økta ber prefiksa, test ruta i begge retningar frå gatewayen: kjeldeadresse, neste hopp og tryggingspolicyen som tillèt trafikken. Ei BGP-økta kan vera oppe medan det konkrete prefikset applikasjonen din treng er filtrert, summert bort eller peikar på feil grensesnitt.

Reachability Analyzer er verktøyet på AWS-sida som tek ein kjelde, ein destinasjon og ein sti, og rapporterer kva komponent i ein støtta konfigurasjon som blokkerte han. Bruk det til å testa stien frå VPC-en til kundegatewayadressa di, ikkje frå ein applikasjonsvert. Det analyserer konfigurasjon og sender ikkje ein pakke gjennom ein lokal brannmur, så hald dommen skild frå dine eigne grensesnittteljarar og pakkeopptak.

Skriv det ytre paret, det interne /30-et og dei annonserte prefiksa for kvar tunnel i éin tabell. Det er tabellen som gjer den neste endringa gjennomgåeleg.