GCP HA VPN: bumabara ang BGP session sa Waiting for peer, ang pagpapalit ng pares ng address

Ang BGP session na hindi kailanman umaabot sa Established sa isang tunnel ng Cloud VPN ay kadalasang hindi problema sa routing. Problema ito sa mga kable: dalawang address na dapat magsalamin sa isa't isa ang inilagay sa maling pagkakasunod-sunod, o ang pares ng unang tunnel ay ginamit muli sa pangalawa. Ang tunnel mismo ay maaaring ganap na malusog habang ang session ay nananatili sa Waiting for peer, dahil ang IPsec at BGP ay magkahiwalay na negosasyon sa pagitan ng parehong dalawang endpoint. Magpasya kung alin sa dalawa ang sira bago magtayo muli ng kahit ano.

Isang tanong ang nagtatakda ng karamihan ng kaso: nakikita ba ng peer device ang address ng Cloud Router?

Ang estado ng tunnel at estado ng session ay magkaibang pagsusuri

IKE at ESP muna. Kung hindi naka-establish ang tunnel, walang mahalaga sa loob nito at ang usapan tungkol sa BGP address ay masyadong maaga. Basahin ang status at detalyadong status ng tunnel, pagkatapos ang BGP peer status ng router para sa parehong tunnel.

Ang tunnel na nasa itaas habang ang BGP peer nito ay nasa ibaba ay nagpapakipot ng depekto sa session: address ng peer, ASN, o TCP 179 na dumarating sa panloob na address. Tunnel nasa itaas, session nasa itaas at wala pa ring ruta sa VPC ang ikatlong kaso. Hindi makakatulong ang pagpalit ng address doon, dahil gumagana na ang session at ang prefix ay hindi lamang inaanunsyo o hindi pinipili. Ang paghihiwalay ng tatlong kasong ito ang malaking bahagi ng trabaho.

Bawat tunnel ay kailangan ng sariling /30, puno ang dalawang dulo

Bawat HA VPN tunnel ay nakakakuha ng link-local /30 mula sa 169.254.0.0/16, isang address sa interface ng Cloud Router at ang isa sa iyong peer. Dapat pangalanan ng peer field ang malayong dulo, hindi kailanman ang sariling address ng router.

Dalawang tunnel ay nangangahulugang dalawang interface sa Cloud Router, bawat isa ay may ibang /30. Ang paggamit muli ng pares ng tunnel 0 sa tunnel 1 ang pagkakamaling mukhang maayos sa buod na talahanayan at namamatay sa OPEN packet.

Basahin ang pares mula sa resource ng router, hindi sa buod ng console. Inililista ng buod ang address ng peer sa hanay na madaling mabasa nang mali, at ang ipRange ng interface at peerIpAddress ng peer ay dapat ilarawan ang magkabilang dulo ng isang /30.

Kadalasang nangyayari ang pagpapalit habang nagtatayo muli

Sa pagtatayo muli ng tunnel nagkakrus ang mga pares. Ang address ng peer ng lumang tunnel ay kinokopya sa field ng interface ng bago, o ang bagong session ay itinuturo sa peer ng nakaraang session. Alinman sa dalawa, nagpapadala ang Cloud Router ng OPEN packet sa address na siya na ngayon o sa address na walang tunnel sa likod.

Isulat ang mga pares bago buksan ang console: pangalan ng tunnel, interface, address ng router, address ng peer, ASN ng peer. Pagkatapos ay likhain ang dalawang tunnel sa isang pasada, upang ang pangalawa ay hindi mapuno ng natira sa una.

Tatlo pang dahilan kung bakit naghihintay ang session

Ang ASN ng peer ang una: bawat panig ay dapat naka-configure sa ASN ng kabila, at ang hindi pagtutugma ay umaabot sa peer ngunit hindi kailanman nagsasaestablish. Ang pangalawa ay ang firewall ng peer mismo, na dapat magpahintulot ng TCP 179 sa interface ng tunnel; hindi ito sakop ng IKE o ESP rule. Ang pangatlo ay peer na sumasagot mula sa ibang source address kaysa sa naka-configure bilang kapitbahay nito.

Ang log ng peer mismo ang nagtatangi. Kung walang kapitbahay ang BGP summary nito para sa address na iyon, hindi dumarating ang mga packet at mali ang pares o ang landas. Kung ang kapitbahay ay nasa Active o Connect, dumarating ang mga packet at hindi tugma ang mga parameter ng session.

Suriin sa ayos ng paglalakbay ng mga packet

Magtrabaho pakanluran: status ng tunnel, pagkatapos BGP peer status ng router, pagkatapos BGP summary ng peer, pagkatapos ang mga ruta. Kung malusog ang unang dalawa, itigil ang pag-edit sa panig ng Cloud VPN at magtrabaho sa peer device. Kung iniuulat ng router na nakababa ang peer at walang kapitbahay ang device mo, mali ang pares o na-filter ang BGP port. Ang paghuli ng packet sa interface ng tunnel ng peer ay nagtatakda nito sa isang tingin, dahil ang OPEN packet ay dumarating doon o hindi kailanman dumarating.

Ang gcloud compute routers get-status ROUTER --region=REGION ay nagpi-print ng peer status sa tabi ng address na ginagamit nito, at iyon mismo ang pares na kailangan mong ihambing.

Kapag naka-establish na ang session, tiyakin na lumilitaw ang natutunang prefix sa route table ng VPC at may isang host sa bawat panig na sumasagot. Pagkatapos itala ang huling mga pares sa tabi ng mga pangalan ng tunnel, upang ang susunod na pagtatayo muli ay magsimula sa isang beripikadong talahanayan at hindi sa buod ng console.