AWS Site-to-Site VPN: exterior, interior și prefixul LAN

Trei roluri de adresă se confundă pe un singur VPN AWS: partenerii externi, legătura internă /30 și prefixele LAN protejate. Citiți-le în configurația descărcată.

Cele mai multe erori la AWS Site-to-Site VPN sunt erori de adresă, și se fac înainte să se miște vreun pachet. Adresele externe ale tunelului ajung la partenerii IPsec, cele interne formează legătura de rutare dintre ei, iar prefixele protejate sunt scopul acelei legături. Copiați un rol în altul și tunelul urcă în timp ce nimic nu este rutat. Iată secvența citește-verifică-configurează pe care o folosesc pe un gateway de client BGP, cu valorile luate din configurația dispozitivului descărcată, nu din memorie.

Trei roluri de adresă, un singur tunel

Adresele externe sunt publice și aparțin partenerilor IPsec: una pe tunel în partea AWS, iar identitatea accesibilă a gateway-ului de client din partea dumneavoastră, adaptată aranjamentului NAT pe care îl aveți de fapt. Adresele interne sunt private și aparțin legăturii logice, pe care AWS o documentează ca un /30 luat din 169.254.0.0/16. Prefixele protejate sunt rețelele VPC, locale sau de tranzit pe care le rutați și le anunțați prin acea legătură.

Atribuirea unui prefix LAN ca adresă a interfeței tunelului este versiunea clasică a acestei erori. Interfața pare configurată, LAN-ul nu este anunțat, iar partea cealaltă nu are rută către el. Tunelul poate trece chiar propriul ping intern în timp ce fiecare nume de aplicație expiră. Referința opțiunilor tunelului listează constrângerile CIDR-ului intern, inclusiv intervalul de adrese din care trebuie să provină.

Citiți valorile din configurația descărcată

Descărcați configurația pentru modelul dumneavoastră concret de dispozitiv din conexiune, apoi tratați tabelul ei de adrese ca sursă de adevăr. Consola arată aceleași valori pe tunel: IP extern, CIDR intern și adresa partenerului BGP din partea AWS. Cele două tuneluri sunt obiecte separate, cu puncte finale externe separate și /30 interne separate, deși ambele transportă aceleași rețele protejate.

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

Dacă fișierul descărcat și consola live nu coincid, fișierul este învechit. Descărcați din nou în loc să editați adresele manual, pentru că o nepotrivire între perechea internă și vecinul configurat al partenerului este o defecțiune BGP silențioasă.

Construiți legătura cu adresa corectă

Pe un gateway Linux tunelul este o interfață VTI sau XFRM, iar /30-ul intern se pune pe acea interfață. Două tuneluri înseamnă două interfețe și doi vecini BGP, unul pentru fiecare punct final AWS. Convenția pe care AWS o tipărește în configurația descărcată a dispozitivului pune gateway-ul privat virtual pe prima adresă a fiecărui /30 intern, iar gateway-ul dumneavoastră de client pe a doua, așa că luați adresa mai mare și faceți peering cu cea mai mică. Nimic aici nu are nevoie de o adresă LAN.

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

Dacă fișierul pentru modelul dumneavoastră de dispozitiv tipărește perechea inversă, folosiți numerele lui și păstrați regula: adresa de pe interfață este a dumneavoastră, adresa partenerului aparține AWS. Inversarea produce un tunel care nu ajunge niciodată la Established, pentru că vecinul configurat este adresa pe care interfața dumneavoastră o are deja.

Țineți marcajul și cheia VTI aliniate cu ce folosește daemonul IKE pentru a lega un SA copil de interfață, altfel traficul ajunge pe tunel fără o interfață pe care să aterizeze. Verificați MTU față de cale și față de setările proprii ale daemonului IKE în loc să copiați un număr dintr-un alt site.

Verificați BGP înainte de a verifica rutele

Faptul că IPsec urcă dovedește că partenerii cad de acord asupra unei asocieri de securitate și nimic mai mult. Sesiunea BGP este o negociere separată pe legătura internă, așa că citiți starea vecinului și contoarele de prefixe, apoi comparați-le cu ce intenționați să anunțați.

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'

Starea Established cu zero prefixe primite este o problemă de politică sau de anunț, nu de tunel. Repetați toată verificarea pe al doilea tunel; un prim tunel funcțional vă spune că adresele sunt plauzibile, nu că al doilea tunel a fost configurat.

Urmați un pachet rutat, apoi opriți-vă

Odată ce sesiunea transportă prefixele, testați ruta în ambele direcții de la gateway: adresa sursă, următorul salt și politica de securitate care permite traficul. O sesiune BGP poate fi activă în timp ce prefixul concret de care are nevoie aplicația dumneavoastră este filtrat, rezumat sau îndreptat spre interfața greșită.

Reachability Analyzer este instrumentul din partea AWS care ia o sursă, o destinație și o cale și raportează ce componentă dintr-o configurație acceptată l-a blocat. Folosiți-l pentru a testa calea de la VPC la adresa gateway-ului dumneavoastră de client, nu de la un host de aplicație. Analizează configurația și nu trimite un pachet printr-un firewall local, așa că țineți verdictul separat de contoarele proprii de interfață și capturile de pachete.

Înregistrați perechea externă, /30-ul intern și prefixele anunțate pentru fiecare tunel într-un singur tabel. Acel tabel este ceea ce face următoarea modificare verificabilă.

Articole similare