AWS Site-to-Site VPN: külső, belső és a LAN-előtag

Három címszerep keveredik egy AWS VPN-en: a külső társak, a belső /30-as kapcsolat és a védett LAN-előtagok. Olvassa ki őket a letöltött konfigurációból.

Az AWS Site-to-Site VPN hibáinak többsége címhiba, és még azelőtt keletkeznek, hogy egyetlen csomag elmozdulna. Az alagút külső címei érik el az IPsec-társakat, a belső címek alkotják a köztük lévő útválasztó kapcsolatot, a védett előtagok pedig azok, amiért ez a kapcsolat létezik. Másolja át az egyik szerepet a másikba, és az alagút feljön, miközben semmi sem útválasztódik. Íme az olvas-ellenőriz-konfigurál sorrend, amit BGP-ügyfélátjárón használok, az értékeket a letöltött eszközkonfigurációból véve, nem emlékezetből.

Három címszerep, egy alagút

A külső címek nyilvánosak és az IPsec-társakhoz tartoznak: egy alagútonként az AWS oldalán, és az ügyfélátjáró elérhető identitása az Ön oldalán, igazítva ahhoz a NAT-elrendezéshez, ami valójában van. A belső címek privátak és a logikai kapcsolathoz tartoznak, amelyet az AWS /30-ként dokumentál, a 169.254.0.0/16 tartományból véve. A védett előtagok azok a VPC-, helyszíni vagy tranzit hálózatok, amelyeket ezen a kapcsolaton át útválaszt és hirdet.

Ha egy LAN-előtagot ad az alagút interfészének címeként, az a hiba klasszikus változata. Az interfész konfiguráltnak látszik, a LAN nincs hirdetve, és a túloldalon nincs útvonal hozzá. Az alagút még a saját belső pingjét is teljesítheti, miközben minden alkalmazásnév időtúllépést kap. Az alagút-beállítások referenciája felsorolja a belső CIDR korlátait, beleértve azt a címtartományt, ahonnan származnia kell.

Olvassa ki az értékeket a letöltött konfigurációból

Töltse le a konkrét eszközmodelljének konfigurációját a kapcsolatból, majd kezelje a címtáblázatát igazságforrásként. A konzol ugyanazokat az értékeket mutatja alagútonként: külső IP, belső CIDR és a BGP-társ címe az AWS oldalán. A két alagút külön objektum, külön külső végpontokkal és külön belső /30-akkal, bár mindkettő ugyanazokat a védett hálózatokat szállítja.

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

Ha a letöltött fájl és az élő konzol nem egyezik, a fájl elavult. Töltse le újra, ne szerkessze kézzel a címeket, mert a belső pár és a társ konfigurált szomszédja közötti eltérés csendes BGP-hiba.

Építse fel a kapcsolatot a megfelelő címmel

Linux-átjárón az alagút VTI vagy XFRM interfész, és a belső /30 erre az interfészre kerül. Két alagút két interfészt és két BGP-szomszédot jelent, egyet AWS-végpontonként. Az a konvenció, amelyet az AWS a letöltött eszközkonfigurációba nyomtat, a virtuális magánátjárót minden belső /30 első címére, az ügyfélátjárót pedig a másodikra teszi, tehát Ön a magasabb címet veszi, és az alacsonyabbal peerel. Itt semminek nincs szüksége LAN-címre.

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

Ha az eszközmodellje fájlja a fordított párosítást nyomtatja, használja annak számait, és tartsa a szabályt: az interfészen lévő cím az Öné, a társ címe az AWS-hez tartozik. Ennek fordítottja olyan alagutat ad, amely soha nem éri el az Established állapotot, mert a konfigurált szomszéd az a cím, amelyet a saját interfésze már tart.

Tartsa a markot és a VTI-kulcsot összhangban azzal, amit az IKE-démon a gyermek SA interfészhez kötéséhez használ, különben a forgalom megérkezik az alagútra, de nincs interfész, ahol landolhatna. Ellenőrizze az MTU-t az útvonalhoz és az IKE-démon saját beállításaihoz képest, ne másoljon számot egy másik helyről.

Az útvonalak ellenőrzése előtt ellenőrizze a BGP-t

Az IPsec feljövetele azt bizonyítja, hogy a társak egy biztonsági társulásban megegyeztek, és semmi mást. A BGP-munkamenet külön egyeztetés a belső kapcsolaton, ezért olvassa ki a szomszéd állapotát és az előtagszámlálókat, majd hasonlítsa össze azzal, amit hirdetni akart.

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'

Az Established állapot nulla fogadott előtaggal szabályzat- vagy hirdetési probléma, nem alagútprobléma. Ismételje meg a teljes ellenőrzést a második alagúton; egy működő első alagút azt mondja, hogy a címek hihetőek, nem azt, hogy a második alagút egyáltalán konfigurálva van.

Kövessen egy útválasztott csomagot, majd álljon meg

Amikor a munkamenet már szállítja az előtagokat, tesztelje az útvonalat mindkét irányban az átjárótól: forráscím, következő ugrás és a forgalmat engedélyező biztonsági szabályzat. A BGP-munkamenet állhat, miközben az alkalmazásának szükséges konkrét előtag szűrve, összevonva vagy a rossz interfészre irányítva van.

A Reachability Analyzer az AWS oldali eszköz, amely forrást, célt és útvonalat vesz, és jelenti, melyik összetevő blokkolta egy támogatott konfigurációban. Arra használja, hogy a VPC-től az ügyfélátjárója címéig tesztelje az útvonalat, ne egy alkalmazáskiszolgálóról. Konfigurációt elemez, és nem küld csomagot helyszíni tűzfalon át, ezért tartsa a verdiktjét külön a saját interfész-számlálóitól és csomagrögzítéseitől.

Jegyezze fel a külső párt, a belső /30-at és a hirdetett előtagokat alagútonként egyetlen táblázatba. Ez a táblázat teszi a következő változtatást áttekinthetővé.

Kapcsolódó cikkek