GCP HA VPN: relace BGP visí na Waiting for peer, záměna dvojice adres

Relace BGP, která na tunelu Cloud VPN nikdy nedosáhne stavu Established, obvykle není problém směrování. Je to problém zapojení: dvě adresy, které se musí navzájem zrcadlit, byly zadány v opačném pořadí, nebo byla dvojice prvního tunelu znovu použita na druhém. Samotný tunel může být zcela zdravý, zatímco relace zůstává na Waiting for peer, protože IPsec a BGP jsou oddělená vyjednávání mezi stejnými dvěma koncovými body. Rozhodněte, která z těch dvou je rozbitá, než cokoli přestavíte.

Jedna otázka vyřeší většinu případů: vidí zařízení protistrany adresu Cloud Routeru vůbec?

Stav tunelu a stav relace jsou různé kontroly

IKE a ESP přicházejí první. Pokud tunel není ustaven, nic uvnitř něj nehraje roli a debata o adrese BGP je předčasná. Přečtěte stav a podrobný stav tunelu, poté stav BGP protistrany routeru pro tentýž tunel.

Tunel, který je nahoře, zatímco jeho BGP protistrana je dole, zužuje závadu na relaci: adresa protistrany, ASN nebo TCP 179 přicházející na vnitřní adresu. Tunel nahoře, relace nahoře a stále žádné trasy ve VPC je třetí případ. Změna adres tam nepomůže, protože relace už funguje a prefix se prostě neinzeruje nebo není preferován. Rozlišovat tyto tři případy je většina práce.

Každý tunel potřebuje vlastní /30 s vyplněnými oběma konci

Každý tunel HA VPN dostane link-local /30 z 169.254.0.0/16, jednu adresu na rozhraní Cloud Routeru a druhou u vaší protistrany. Pole protistrany musí pojmenovat vzdálený konec, nikdy vlastní adresu routeru.

Dva tunely znamenají dvě rozhraní na Cloud Routeru, každé s jinou /30. Znovupoužití dvojice tunelu 0 na tunelu 1 je chyba, která vypadá úhledně v souhrnné tabulce a umírá v paketu OPEN.

Čtěte dvojici z prostředku routeru, nikoli ze souhrnu v konzoli. Souhrn uvádí adresu protistrany ve sloupci, který se snadno přečte špatně, a ipRange rozhraní plus peerIpAddress protistrany musí popisovat protilehlé konce jedné /30.

Záměna obvykle nastane při přestavbě

Právě při přestavbě tunelu se dvojice zkříží. Adresa protistrany starého tunelu se zkopíruje do pole rozhraní nového, nebo nová relace míří na protistranu té předchozí. V obou případech Cloud Router posílá pakety OPEN na adresu, která je nyní jím samotným, nebo na adresu bez tunelu za sebou.

Zapište si dvojice před otevřením konzole: název tunelu, rozhraní, adresa routeru, adresa protistrany, ASN protistrany. Potom vytvořte oba tunely v jednom průchodu, aby se druhý nevyplnil zbytky prvního.

Tři další důvody, proč relace čeká

ASN protistrany je první: každá strana musí být nakonfigurována s ASN té druhé, a neshoda se k protistraně dostane, ale nikdy se neustaví. Druhý je vlastní firewall protistrany, který musí povolit TCP 179 na rozhraní tunelu; pravidlo IKE nebo ESP to nepokrývá. Třetí je protistrana, která odpovídá z jiné zdrojové adresy, než je ta nakonfigurovaná jako její soused.

Rozhodující je vlastní log protistrany. Pokud její souhrn BGP neuvádí pro tuto adresu žádného souseda, pakety nedorazí a dvojice nebo cesta jsou špatné. Pokud soused stojí v Active nebo Connect, pakety dorazí a parametry relace si neodpovídají.

Ověřujte v pořadí, v jakém pakety putují

Pracujte směrem ven: stav tunelu, pak stav BGP protistrany routeru, pak souhrn BGP protistrany, pak trasy. Pokud jsou první dva zdravé, přestaňte upravovat stranu Cloud VPN a pracujte na zařízení protistrany. Pokud router hlásí protistranu jako dole a vaše zařízení nemá žádného souseda, je dvojice špatná nebo je port BGP filtrován. Zachytávání paketů na rozhraní tunelu protistrany to vyřeší na jeden pohled, protože pakety OPEN tam buď dorazí, nebo nikdy nedorazí.

gcloud compute routers get-status ROUTER --region=REGION vypíše stav protistrany vedle adresy, kterou používá, což je přesně dvojice, kterou je třeba porovnat.

Jakmile se relace ustaví, ověřte, že se naučený prefix objeví ve směrovací tabulce VPC a že jeden hostitel na každé straně odpovídá. Potom si zapište konečné dvojice vedle názvů tunelů, aby příští přestavba začala z ověřené tabulky, a ne ze souhrnu v konzoli.