GCP HA VPN: relácia BGP visí na Waiting for peer, zámena dvojice adries
Relácia BGP v Cloud VPN zaseknutá na Waiting for peer má zvyčajne prehodené adresy tunela a protistrany. Skontrolujte dvojicu, skôr než čokoľvek prestavíte.
Relácia BGP, ktorá na tuneli Cloud VPN nikdy nedosiahne Established, zvyčajne nie je problém smerovania. Je to problém zapojenia: dve adresy, ktoré sa musia navzájom zrkadliť, boli zadané v opačnom poradí, alebo bola dvojica prvého tunela znova použitá na druhom. Samotný tunel môže byť úplne zdravý, kým relácia zostáva na Waiting for peer, pretože IPsec a BGP sú oddelené rokovania medzi tými istými dvoma koncovými bodmi. Rozhodnite, ktorá z tých dvoch je pokazená, skôr než čokoľvek prestavíte.
Jedna otázka vyrieši väčšinu prípadov: vidí zariadenie protistrany adresu Cloud Routeru vôbec?
Stav tunela a stav relácie sú rôzne kontroly
IKE a ESP prichádzajú prvé. Ak tunel nie je ustanovený, nič v jeho vnútri nehrá rolu a debata o adrese BGP je predčasná. Prečítajte stav a podrobný stav tunela, potom stav BGP protistrany routera pre ten istý tunel.
Tunel, ktorý je hore, kým jeho BGP protistrana je dole, zužuje závadu na reláciu: adresa protistrany, ASN alebo TCP 179 prichádzajúci na vnútornú adresu. Tunel hore, relácia hore a stále žiadne trasy vo VPC je tretí prípad. Zmena adries tam nepomôže, pretože relácia už funguje a prefix sa jednoducho neinzeruje alebo nie je preferovaný. Rozlišovať tieto tri prípady je väčšina práce.
Každý tunel potrebuje vlastnú /30 s vyplnenými oboma koncami
Každý tunel HA VPN dostane link-local /30 z 169.254.0.0/16, jednu adresu na rozhraní Cloud Routeru a druhú u vašej protistrany. Pole protistrany musí pomenovať vzdialený koniec, nikdy vlastnú adresu routera.
Dva tunely znamenajú dve rozhrania na Cloud Routeri, každé s inou /30. Opätovné použitie dvojice tunela 0 na tuneli 1 je chyba, ktorá vyzerá úhľadne v súhrnnej tabuľke a umiera v pakete OPEN.
| Tunnel | Router interface | Peer address | What a swap produces |
|---|---|---|---|
| tunnel 0 | 169.254.1.1/30 | 169.254.1.2 | OPEN sent to itself or to nothing; session waits |
| tunnel 1 | 169.254.1.5/30 | 169.254.1.6 | same failure on the second session |
| both | one pair reused | one address reused | one session up, the other never leaves waiting |
Dvojicu čítajte z prostriedku routera, nie zo súhrnu v konzole. Súhrn uvádza adresu protistrany v stĺpci, ktorý sa dá ľahko prečítať nesprávne, a ipRange rozhrania plus peerIpAddress protistrany musia opisovať protilehlé konce jednej /30.
Zámena zvyčajne nastane pri prestavbe
Práve pri prestavbe tunela sa dvojice skrížia. Adresa protistrany starého tunela sa skopíruje do poľa rozhrania nového, alebo nová relácia mieri na protistranu tej predchádzajúcej. V oboch prípadoch Cloud Router posiela pakety OPEN na adresu, ktorá je teraz ním samotným, alebo na adresu bez tunela za sebou.
Zapíšte si dvojice pred otvorením konzoly: názov tunela, rozhranie, adresa routera, adresa protistrany, ASN protistrany. Potom vytvorte oba tunely v jednom prechode, aby sa druhý nevyplnil zvyškami prvého.
Tri ďalšie dôvody, prečo relácia čaká
ASN protistrany je prvý: každá strana musí byť nakonfigurovaná s ASN tej druhej, a nezhoda sa k protistrane dostane, ale nikdy sa neustanoví. Druhý je vlastný firewall protistrany, ktorý musí povoliť TCP 179 na rozhraní tunela; pravidlo IKE alebo ESP to nepokrýva. Tretí je protistrana, ktorá odpovedá z inej zdrojovej adresy, než je tá nakonfigurovaná ako jej sused.
Rozhodujúci je vlastný log protistrany. Ak jej súhrn BGP neuvádza pre túto adresu žiadneho suseda, pakety neprichádzajú a dvojica alebo cesta sú nesprávne. Ak sused stojí v Active alebo Connect, pakety prichádzajú a parametre relácie si nezodpovedajú.
Overujte v poradí, v akom pakety putujú
Pracujte smerom von: stav tunela, potom stav BGP protistrany routera, potom súhrn BGP protistrany, potom trasy. Ak sú prvé dva zdravé, prestaňte upravovať stranu Cloud VPN a pracujte na zariadení protistrany. Ak router hlási protistranu ako dole a vaše zariadenie nemá žiadneho suseda, dvojica je nesprávna alebo je port BGP filtrovaný. Zachytenie paketov na rozhraní tunela protistrany to vyrieši na jeden pohľad, pretože pakety OPEN tam buď dorazia, alebo nikdy nedorazia.
gcloud compute routers get-status ROUTER --region=REGION vypíše stav protistrany vedľa adresy, ktorú používa, a to je presne dvojica, ktorú treba porovnať.
Keď sa relácia ustanoví, overte, že sa naučený prefix objaví v smerovacej tabuľke VPC a že jeden hostiteľ na každej strane odpovedá. Potom si zapíšte konečné dvojice vedľa názvov tunelov, aby ďalšia prestavba začala z overenej tabuľky, a nie zo súhrnu v konzole.