AWS Site-to-Site VPN: išoriniai, vidiniai adresai ir LAN prefiksas
Viename AWS VPN susimaišo trys adresų vaidmenys: išoriniai partneriai, vidinė /30 grandis ir apsaugoti LAN prefiksai. Skaitykite juos atsisiųstoje konfigūracijoje.
Dauguma AWS Site-to-Site VPN klaidų yra adresų klaidos, ir jos daromos dar prieš pajudant bet kuriam paketui. Išoriniai tunelio adresai pasiekia IPsec partnerius, vidiniai adresai sudaro maršrutizavimo grandį tarp jų, o apsaugoti prefiksai yra tai, kam ta grandis skirta. Nukopijuokite vieną vaidmenį į kitą ir tunelis pakyla, nors niekas nemaršrutizuojama. Štai skaitymo-tikrinimo-konfigūravimo seka, kurią naudoju BGP kliento šliuze, o reikšmės paimtos iš atsisiųstos įrenginio konfigūracijos, ne iš atminties.
Trys adresų vaidmenys, vienas tunelis
Išoriniai adresai yra vieši ir priklauso IPsec partneriams: vienas tuneliui AWS pusėje, o jūsų pusėje – pasiekiama kliento šliuzo tapatybė, pritaikyta tai NAT schemai, kurią iš tikrųjų turite. Vidiniai adresai yra privatūs ir priklauso loginei grandžiai, kurią AWS dokumentuoja kaip /30, paimtą iš 169.254.0.0/16. Apsaugoti prefiksai yra VPC, vietiniai ar tranzito tinklai, kuriuos maršrutizuojate ir skelbiate per tą grandį.
LAN prefikso priskyrimas tunelio sąsajos adresu yra klasikinė šios klaidos forma. Sąsaja atrodo sukonfigūruota, LAN neskelbiamas, o priešinga pusė neturi jam maršruto. Tunelis gali net praeiti savo vidinį ping, o kiekvienas programos vardas baigiasi skirtuoju laiku. Tunelio parinkčių žinynas išvardija vidinio CIDR apribojimus, įskaitant adresų diapazoną, iš kurio jis turi būti.
Skaitykite reikšmes iš atsisiųstos konfigūracijos
Atsisiųskite konfigūraciją savo konkrečiam įrenginio modeliui iš jungties, tada jos adresų lentelę laikykite tiesos šaltiniu. Konsolė rodo tas pačias reikšmes kiekvienam tuneliui: išorinį IP, vidinį CIDR ir BGP partnerio adresą AWS pusėje. Du tuneliai yra atskiri objektai su atskirais išoriniais galiniais taškais ir atskirais vidiniais /30, nors abu perneša tuos pačius apsaugotus tinklus.
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]'Jei atsisiųstas failas ir gyva konsolė nesutampa, failas pasenęs. Atsisiųskite iš naujo, o ne redaguokite adresus rankiniu būdu, nes neatitikimas tarp vidinės poros ir partnerio sukonfigūruoto kaimyno yra tyli BGP klaida.
Sukurkite grandį su teisingu adresu
Linux šliuze tunelis yra VTI arba XFRM sąsaja, o vidinis /30 dedamas ant tos sąsajos. Du tuneliai reiškia dvi sąsajas ir du BGP kaimynus, po vieną kiekvienam AWS galiniam taškui. Konvencija, kurią AWS spausdina atsisiųstoje įrenginio konfigūracijoje, deda virtualų privatų šliuzą į pirmąjį kiekvieno vidinio /30 adresą, o jūsų kliento šliuzą – į antrąjį, tad jūs imate aukštesnį adresą ir susiejate su žemesniuoju. Niekam čia nereikia LAN adreso.
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 1400Jei jūsų įrenginio modelio failas spausdina priešingą porą, naudokite jo skaičius ir laikykitės taisyklės: sąsajos adresas yra jūsų, partnerio adresas priklauso AWS. Apvertus gaunamas tunelis, kuris niekada nepasiekia Established, nes sukonfigūruotas kaimynas yra adresas, kurį jau turi jūsų pačių sąsaja.
Laikykite žymą ir VTI raktą suderintus su tuo, ką IKE demonas naudoja vaiko SA susiejimui su sąsaja, kitaip srautas atvyksta į tunelį be sąsajos, kur nusileisti. Tikrinkite MTU pagal kelią ir pagal paties IKE demono nustatymus, o ne kopijuokite skaičių iš kitos svetainės.
Patikrinkite BGP prieš tikrindami maršrutus
Tai, kad IPsec pakyla, įrodo, kad partneriai sutaria dėl saugos asociacijos, ir nieko daugiau. BGP sesija yra atskiros derybos per vidinę grandį, tad skaitykite kaimyno būseną ir prefiksų skaitiklius, tada palyginkite juos su tuo, ką ketinote skelbti.
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'Būsena Established su nuliu gautų prefiksų yra politikos arba skelbimo problema, o ne tunelio. Pakartokite visą patikrinimą antrame tunelyje; veikiantis pirmasis tunelis pasako, kad adresai yra tikėtini, o ne kad antrasis tunelis apskritai sukonfigūruotas.
Sekite maršrutizuotą paketą ir tada sustokite
Kai sesija jau perneša prefiksus, išbandykite maršrutą abiem kryptimis nuo šliuzo: šaltinio adresą, kitą šuolį ir saugos politiką, kuri leidžia srautą. BGP sesija gali būti pakilusi, kol konkretus prefiksas, kurio reikia jūsų programai, yra filtruojamas, apibendrintas arba nukreiptas į netinkamą sąsają.
Reachability Analyzer yra AWS pusės įrankis, kuris ima šaltinį, paskirties vietą ir kelią bei praneša, kuris komponentas palaikomoje konfigūracijoje jį užblokavo. Naudokite jį kelio nuo VPC iki jūsų kliento šliuzo adreso tikrinimui, o ne iš programos pagrindinio kompiuterio. Jis analizuoja konfigūraciją ir nesiunčia paketo per vietinę užkardą, tad jo nuosprendį laikykite atskirai nuo savo sąsajos skaitiklių ir paketų įrašų.
Užrašykite išorinę porą, vidinį /30 ir skelbiamus prefiksus kiekvienam tuneliui vienoje lentelėje. Būtent ši lentelė daro kitą pakeitimą peržiūrimą.