GCP HA VPN: BGP-økten henger på Waiting for peer, ombyttingen av adresseparet
En Cloud VPN BGP-økt som henger på Waiting for peer har som regel byttet om tunnel- og peer-adressen. Kontroller paret før du bygger noe på nytt.
En BGP-økt som aldri når Established på en Cloud VPN-tunnel er som regel ikke et rutingsproblem. Det er et kablingsproblem: to adresser som skal speile hverandre ble lagt inn i feil rekkefølge, eller paret fra den første tunnelen ble gjenbrukt på den andre. Selve tunnelen kan være helt sunn mens økten står på Waiting for peer, fordi IPsec og BGP er separate forhandlinger mellom de samme to endepunktene. Avgjør hvilken av de to som er ødelagt før du bygger noe på nytt.
Ett spørsmål avgjør de fleste tilfellene: ser peer-enheten i det hele tatt Cloud Routers adresse?
Tunnelstatus og øktstatus er forskjellige kontroller
IKE og ESP kommer først. Hvis tunnelen ikke er etablert, betyr ingenting inni den noe, og diskusjonen om BGP-adressen er for tidlig. Les tunnelens status og detaljerte status, og les deretter ruterens BGP-peerstatus for den samme tunnelen.
En tunnel som er oppe mens BGP-peeren er nede, snevrer feilen inn til økten: peer-adresse, ASN eller TCP 179 som ankommer den indre adressen. En tunnel som er oppe, en økt som er oppe, og fortsatt ingen ruter i VPC-en er et tredje tilfelle. Å endre adresser hjelper ikke der, fordi økten allerede virker og prefikset rett og slett ikke annonseres eller ikke foretrekkes. Å holde de tre tilfellene fra hverandre er det meste av arbeidet.
Hver tunnel trenger sitt eget /30, med begge ender fylt ut
Hver HA VPN-tunnel får et link-local /30 fra 169.254.0.0/16, med én adresse på Cloud Router-grensesnittet og den andre på din peer. Peer-feltet må navngi den fjerne enden, aldri ruterens egen adresse.
To tunneler betyr to grensesnitt på Cloud Router, hvert med et forskjellig /30. Å gjenbruke paret fra tunnel 0 på tunnel 1 er feilen som ser ryddig ut i en sammendragstabell og dør i OPEN-pakken.
| 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 |
Les paret fra ruterressursen i stedet for fra konsollsammendraget. Sammendraget viser peer-adressen i en kolonne som er lett å lese feil, og grensesnittets ipRange pluss peer-ens peerIpAddress må beskrive motsatte ender av ett /30.
Ombyttingen skjer som regel under en gjenoppbygging
Det er når en tunnel bygges på nytt at par krysses. Den gamle tunnelens peer-adresse kopieres inn i den nye tunnelens grensesnittfelt, eller den nye økten pekes mot den forrige øktens peer. Uansett sender Cloud Router OPEN-pakker til en adresse som nå er den selv, eller til en adresse uten tunnel bak.
Skriv ned parene før du åpner konsollen: tunnelnavn, grensesnitt, ruteradresse, peer-adresse, peer-ASN. Opprett deretter begge tunnelene i én omgang, slik at den andre ikke fylles ut fra den førstes rester.
Tre andre grunner til at en økt venter
Peer-ASN er den første: hver side må konfigureres med den andres ASN, og et avvik når peeren men etableres aldri. Den andre er peer-ens egen brannmur, som må tillate TCP 179 på tunnelgrensesnittet; en IKE- eller ESP-regel dekker ikke det. Den tredje er en peer som svarer fra en annen kildeadresse enn den som er konfigurert som dens nabo.
Peer-ens egen logg er den avgjørende. Hvis BGP-sammendraget ikke viser noen nabo for den adressen, ankommer ikke pakkene, og paret eller veien er feil. Hvis naboen står i Active eller Connect, ankommer pakkene, og øktparameterne stemmer ikke.
Kontroller i den rekkefølgen pakkene beveger seg
Arbeid utover: tunnelstatus, deretter ruterens BGP-peerstatus, deretter peer-ens BGP-sammendrag, deretter rutene. Hvis de to første er sunne, slutt å redigere Cloud VPN-siden og arbeid på peer-enheten. Hvis ruteren rapporterer peeren som nede og enheten din ikke har noen nabo, er paret feil eller BGP-porten filtreres. En pakkefangst på peer-ens tunnelgrensesnitt avgjør det med ett blikk, fordi OPEN-pakker enten ankommer der eller aldri gjør det.
gcloud compute routers get-status ROUTER --region=REGION skriver ut peer-statusen ved siden av adressen den bruker, og det er nøyaktig paret du må sammenligne.
Når økten er etablert, bekreft at det lærte prefikset vises i VPC-ens rutetabell og at én vert på hver side svarer. Skriv deretter ned de endelige parene ved siden av tunnelnavnene, slik at neste gjenoppbygging starter fra en verifisert tabell og ikke fra konsollsammendraget.