VGW BGP-hirdetései szemben a VPC útvonaltáblával: mi mit változtat

Egy hiányzó előtag a VPC egyik alhálózatának útvonaltáblájában és egy hiányzó előtag az ügyfél routerén két különböző hiba, és közülük csak az egyiket javítják az AWS útvonaltábláin belül. A virtuális privát átjáró a VPC-jéhez tartozó CIDR-blokkokat hirdeti; az alhálózat útvonaltáblája dönti el, hova küldi a munkaterhelés a választ. A másodikat az első megváltoztatásának eszközeként kezelni a leggyakoribb rossz irány ebben a diagnózisban. Futtassa az alábbi ellenőrzéseket sorrendben, és tartsa külön a két irányt.

Nevezze meg a csatolást, mielőtt bármelyik táblát elolvassa

Egy site-to-site VPN vagy virtuális privát átjárón, vagy tranzit átjárón végződik, és az erőforrás-azonosítók döntik el, melyik útválasztási modell érvényes. Először ezeket olvassa el: aws ec2 describe-vpn-connections --vpn-connection-ids vpn-0123456789abcdef0 --query 'VpnConnections[].{Tunnels:VgwTelemetry,Gateway:GatewayId,Transit:TransitGatewayId}'. A válasz megmondja, hogy a következő vizsgálandó tábla VPC útvonaltábla-e vagy tranzit átjáró útvonaltábla.

Ha a VPN tranzit átjáróhoz csatlakozik, hagyja abba a VPC útvonaltábla vezérlősíkként való kezelését. Ott a VPC táblája az átjáró csatolására mutat, a társítás és a propagálás pedig a tranzit átjáró útvonaltáblájában történik. A két nézet összekeverése magabiztos következtetéseket ad a rossz objektumról.

Az AWS-től az irodába irányuló irány egy hirdetés

VGW-csatolás esetén az átjáró a VPC-jéhez tartozó CIDR-blokkokat BGP-n keresztül hirdeti az ügyfél átjárója felé. Egyetlen alhálózati útvonal hozzáadása, vagy egy útvonal átirányítása egy társ VPC-hez vagy egy eszközhöz, nem ad hozzá másik társított CIDR-t, és nem jelenik meg abban a hirdetésben. Ha az irodában hiányzik egy előtag, hasonlítsa össze a fogadott útvonalak listáját a VPC-társításokkal, mielőtt bármelyik útvonaltáblát szerkesztené.

Az egyszerű szabálynak vannak kivételei, ezért tartsa a hatókörén belül. Egy VPN CloudHub elrendezés újrahirdetheti a telephelyi előtagokat az ügyfél átjárói között, a tranzit átjáró pedig a saját propagálási szabályait követi. Az az állítás, hogy a VGW csak a saját VPC-jét hirdeti, hasznos alapértelmezés, nem törvény, amely minden topológiát lefed, amellyel találkozik.

Az irodából AWS felé irányuló irány a propagálás plusz kiválasztás

A fordított irányban a VGW megtanulja az iroda előtagját, de ez önmagában nem mozgat munkaterhelést. Az alhálózat útvonaltáblájában vagy engedélyezve kell lennie a propagálásnak a csatolás számára, vagy statikus útvonalat kell tartalmaznia ugyanahhoz a célhoz. Ha egy előtaghoz mindkettő létezik, a statikus útvonal nyer, és a leghosszabb előtag egyezése mindkettő előtt fut.

Olvassa el az eredetet ahelyett, hogy feltételezné: aws ec2 describe-route-tables --route-table-ids rtb-0123456789abcdef0 --query 'RouteTables[].Routes'. Az EnableVgwRoutePropagation eredetű bejegyzés BGP-ből érkezett; a CreateRoute eredetű bejegyzést ember gépelte, és tovább nyer, amíg valaki nem törli.

Egy runbook, amely külön tartja a két irányt

Rögzítsen négy tényt az AWS oldalán, mielőtt bármit megváltoztat: a csatolás típusát, a VPC társított CIDR-jeit, a szóban forgó előtag alhálózati útvonalának eredetét, valamint az alagút és a BGP állapotát. Ugyanaz a describe-hívás VgwTelemetryt ad vissza az alagútonként elfogadott útvonalak számával, ami megmondja, hogy az AWS egyáltalán fogadott-e el útvonalakat. Ezután hasonlítsa össze azzal, amit az ügyféleszköz ténylegesen telepített. Az az előtag, amely BGP-ben jelen van, de a továbbítási táblából hiányzik, helyi import- vagy legjobb útvonal probléma, nem AWS útvonaltábla-probléma.

Ha az alhálózati táblából teljesen hiányzik az előtag, engedélyezze a propagálást vagy adjon hozzá statikus útvonalat, majd olvassa újra ugyanazt a lekérdezést a propagálási intervallum után, ahelyett hogy feltételezné, a változás azonnali volt. Ha az előtag létezik, és a forgalom továbbra is meghiúsul, hagyja békén a vezérlősíkot, és lépjen tovább az adatútvonalra.

Mit ne változtasson, amíg ott van

Ne kapcsolja be vagy ki a propagálást nem kapcsolódó útvonaltáblákon egyetlen hiányzó előtag javításához, és ne adjon hozzá alapértelmezett útvonalat egyetlen hiányzó CIDR elfedéséhez. Mindkét változtatás szélesíti a hatás terjedelmét, és megnehezíti a következő diagnózist. Korlátozza a szerkesztést arra a táblára, amely a szóban forgó munkaterhelés-alhálózatot kiszolgálja.

Az adatútvonal mindettől független. A biztonsági csoportok állapottal rendelkeznek, a hálózati ACL-ek nem, és egy gazdagép-tűzfal vagy aszimmetrikus visszaút eldobhatja azt a forgalmat, amelyet az útválasztás helyesen kézbesített. Egy hirdetett összesítés sem jogosít fel minden benne lévő szolgáltatást, ezért a hozzáférést a szabályzat határán korlátozza, ahelyett hogy arra támaszkodna, megjelenik-e egy cím véletlenül egy BGP-hirdetésben.

Mentse el minden útvonaltábla-lekérdezés előtte és utána állapotát a változásnaplóba. Ha a változtatás ront a helyzeten, állítsa vissza az előző útvonalakat, és erősítse meg ugyanazzal a lekérdezéssel, mert a visszagörgetés, amelyet nem tud ellenőrizni, csak találgatás.