GCP HA VPN: BGP-økta heng på Waiting for peer, ombytinga av adresseparet

Ei BGP-økt som aldri når Established på ein Cloud VPN-tunnel er som regel ikkje eit ruteproblem. Det er eit kablingsproblem: to adresser som skal spegle kvarandre vart lagde inn i feil rekkjefølgje, eller paret frå den første tunnelen vart brukt om att på den andre. Sjølve tunnelen kan vere heilt sunn medan økta står på Waiting for peer, fordi IPsec og BGP er separate forhandlingar mellom dei same to endepunkta. Avgjer kva av dei to som er øydelagd før du byggjer noko på nytt.

Eitt spørsmål avgjer dei fleste tilfella: ser peer-eininga i heile teke adressa til Cloud Router?

Tunnelstatus og øktstatus er ulike kontrollar

IKE og ESP kjem først. Viss tunnelen ikkje er etablert, betyr ingenting inni han noko, og drøftinga om BGP-adressa er for tidleg. Les statusen og den detaljerte statusen til tunnelen, og les deretter BGP-peerstatusen til rutaren for den same tunnelen.

Ein tunnel som er oppe medan BGP-peeren er nede, snevrar feilen inn til økta: peer-adresse, ASN eller TCP 179 som kjem inn på den indre adressa. Ein tunnel som er oppe, ei økt som er oppe, og framleis ingen ruter i VPC-en er eit tredje tilfelle. Å endre adresser hjelper ikkje der, fordi økta alt verkar og prefikset rett og slett ikkje vert annonsert eller ikkje vert føretrekt. Å halde dei tre tilfella frå kvarandre er det meste av arbeidet.

Kvar tunnel treng sitt eige /30, med begge endar fylte ut

Kvar HA VPN-tunnel får eit link-local /30 frå 169.254.0.0/16, med éi adresse på grensesnittet til Cloud Router og den andre på peeren din. Peer-feltet må namngje den fjerne enden, aldri den eigne adressa til rutaren.

To tunnels tyder to grensesnitt på Cloud Router, kvart med eit ulikt /30. Å bruke paret frå tunnel 0 om att på tunnel 1 er feilen som ser ryddig ut i ein samandragstabell og døyr i OPEN-pakken.

Les paret frå ruterressursen i staden for frå konsollsamandraget. Samandraget viser peer-adressa i ein kolonne som er lett å lese feil, og ipRange til grensesnittet pluss peerIpAddress til peeren må skildre motsette endar av eitt /30.

Ombytinga skjer som regel under ein gjenoppbygging

Det er når ein tunnel vert bygd på nytt at par kryssar kvarandre. Peer-adressa til den gamle tunnelen vert kopiert inn i grensesnittfeltet til den nye, eller den nye økta vert peika mot peeren til den førre økta. Uansett sender Cloud Router OPEN-pakkar til ei adresse som no er han sjølv, eller til ei adresse utan tunnel bak.

Skriv ned para før du opnar konsollen: tunnelnamn, grensesnitt, ruteradresse, peer-adresse, peer-ASN. Opprett deretter begge tunnelane i ein omgang, slik at den andre ikkje vert fylt ut frå restane av den første.

Tre andre grunnar til at ei økt ventar

Peer-ASN er den første: kvar side må konfigurerast med ASN-en til den andre, og eit avvik når peeren men vert aldri etablert. Den andre er brannmuren til peeren sjølv, som må tillate TCP 179 på tunnelgrensesnittet; ein IKE- eller ESP-regel dekkjer ikkje det. Den tredje er ein peer som svarar frå ei anna kjeldeadresse enn den som er konfigurert som naboen hans.

Loggen til peeren sjølv er den avgjerande. Viss BGP-samandraget ikkje viser nokon nabo for den adressa, kjem ikkje pakkane inn, og paret eller vegen er feil. Viss naboen står i Active eller Connect, kjem pakkane inn, og øktparametrane stemmer ikkje.

Kontroller i den rekkjefølgja pakkane flyttar seg

Arbeid utover: tunnelstatus, deretter BGP-peerstatusen til rutaren, deretter BGP-samandraget til peeren, deretter rutene. Viss dei to første er sunne, slutt å redigere Cloud VPN-sida og arbeid på peer-eininga. Viss rutaren melder peeren som nede og eininga di ikkje har nokon nabo, er paret feil eller BGP-porten vert filtrert. Ei pakkefangst på tunnelgrensesnittet til peeren avgjer det med eit blikk, fordi OPEN-pakkar anten kjem dit eller aldri kjem.

gcloud compute routers get-status ROUTER --region=REGION skriv ut peer-statusen ved sida av adressa han brukar, og det er nøyaktig paret du må samanlikne.

Når økta er etablert, stadfest at det lærde prefikset viser seg i rutetabellen til VPC-en og at éin vert på kvar side svarar. Skriv deretter ned dei endelege para ved sida av tunnelnamna, slik at neste gjenoppbygging startar frå ein verifisert tabell og ikkje frå konsollsamandraget.