GCP BYOIP: ang pampublikong anunsyo ay hindi pribadong ruta

Ang isang bahagi ng pampublikong bloke ay nananatili sa site at ang isang bahagi ay lumilipat sa Google Cloud. Inilalarawan ng pangungusap na iyon ang dalawang plano, hindi isa: isang plano sa anunsyo sa internet at isang plano sa pribadong pagpapasa. Ang ituring ang mga ito na isang problemang routing ay doon nagkakamali ang mga disenyong BYOIP.

Ang mga kasangkot na bagay ay sumasagot sa magkakaibang tanong, at isa lamang sa kanila ang tungkol sa kung saan pupunta ang mga packet.

Tatlong bagay, tatlong tanong

Ang pampublikong inanunsyong prefix ay ang yunit na inaanunsyo ng Google sa internet sa iyong ngalan. Ang pampublikong idinelegang prefix ay kung paano inilalaan ang inangkat na espasyo sa mga sinusuportahang resource ng Cloud. Ang ruta ng VPC, kabilang ang natutunan sa Cloud Router mula sa VPN, ay pumipili ng pribadong susunod na hop. Bawat isa ay may sariling saklaw, sariling API at sariling mensahe ng error.

Ang bersyon sa talahanayan ay mas maikli.

Tanging ang ikatlong hilera ang tungkol sa pagpapasa sa loob ng iyong network.

Ano ang saklaw ng babala sa overlap ng BYOIP

Ang dokumentasyon ng BYOIP ng Google ay itinuturing ang inanunsyong prefix bilang yunit ng anunsyo at nagbababala tungkol sa mga panlabas na anunsyong nagsasapawan, kabilang ang subprefix na inaanunsyo sa labas ng Google. Ang babalang iyon ay tungkol sa plano ng pampublikong anunsyo. Hindi ito pahayag tungkol sa bawat pribadong rutang maaari mong idagdag.

Ang pagdelega ng mas maliit na alokasyon sa loob ng inangkat na prefix ay hindi, sa sarili nito, nagbibigay sa iyo ng pahintulot na i-anunsyo ang natitira mula sa ibang pinagmulan.

Itanong sa paraang sino ang nag-aanunsyo ng ano. Kung inaanunsyo ng Google ang buong inangkat na prefix, ang ikalawang pinagmulan na nag-aanunsyo ng subprefix ay lumilikha ng eksaktong overlap na binabalaan ng dokumentasyon, gaano man kaayos ang iyong mga ruta ng VPC.

Ano ang itinatakda ng pribadong ruta

Ang prefix na natutunan sa VPN ay hindi anunsyo sa internet, at walang dami ng BGP ang gagawa nitong ganoon. Ito ay isang entry sa talahanayan ng ruta ng VPC na nagsasabi kung aling tunnel o gateway ang dapat magdala ng trapiko patungo sa destinasyong iyon. Kung ang entry na iyon ay karapat-dapat, napili o magagamit ay nakasalalay sa sariling mga tuntunin sa routing ng VPC.

Ang pagtutugma ng pinakamahabang prefix ay nalalapat sa loob ng talahanayan ng ruta, kaya ang mas mahabang rutang VPN ay maaaring manalo nang lokal nang walang binabago sa pampublikong gilid.

Paghahati ng prefix: ang desisyong unang dumarating

Kung kailangan ng arkitektura na ang kalahati ng bloke ay i-anunsyo mula sa isang data center at ang kalahati mula sa Google, pagpasyahan ang plano ng anunsyo bago mag-angkat ng anuman. Kumpirmahin kung aling mga saklaw ang maaaring i-anunsyo ng Google, alin ang nananatiling inaanunsyo sa ibang lugar, at kung nagsasapawan ang dalawa. Pagkatapos ay idisenyo ang pribadong landas para sa bawat destinasyon at ang landas ng pagbabalik nito. Kung hindi sinusuportahan ng mga provider ang paghahating gusto mo, baguhin ang paghahati sa halip na umasa na ang mas mahabang prefix ng VPN ay magpapawalang-bisa sa desisyon sa pampublikong gilid.

Mahalaga ang pagkakasunod-sunod na iyon dahil hindi kayang ayusin ng ikalawang plano ang una.

I-verify ang dalawang plano nang hiwalay

Tingnan ang pampublikong bahagi gamit ang gcloud compute public-advertised-prefixes list at kumpirmahin ang mga saklaw at ang kanilang kalagayan. Tingnan ang pribadong bahagi gamit ang gcloud compute routes list at gcloud compute routers get-status, na nagpapakita kung ano ang aktuwal na ipinagpalit ng BGP.

Ang isang set ng output ay nagsasabi sa iyo kung ano ang nakikita ng internet. Ang isa ay nagsasabi kung saan pumupunta ang iyong trapiko. Wala sa kanila ang pumapalit sa isa.