Maraming proyekto sa Google Cloud, isang hybrid na VPN? Magpasya muna

Kapag maraming proyekto sa Google Cloud ang nangangailangan ng hybrid na access, ang instinct ay isang VPN bawat proyekto, at halos palaging mali ang hugis na iyon. Ang pagmamay-ari ng proyekto at ang pag-ruta ng packet ay magkaugnay ngunit magkaibang usapin, at pinapanatili ng kapaki-pakinabang na arkitektura ang mga hangganang administratibo na kailangan mo habang binibigyan ang mga inilaan na prefix ng isang sinadyang landas patungo sa opisina o data center. Ang mga pagsusuring ito ang nagpapasya kung aling modelo ng network ang talagang gusto mo, sa pagkakasunod-sunod na umiiwas sa muling paggawa. Ang bawat isa ay maaaring tapusin ang talakayan nang maaga, at iyon ang punto.

Ang hangganan ng proyekto ay hindi awtomatikong nangangailangan ng sarili nitong tunnel.

Suriin kung ang shared na bagay ay ang network

Magsimula sa tanong tungkol sa pagmamay-ari, hindi sa konektividad: kaya bang suportahan ng sentral na pagmamay-ari ng network ang mga workload na ito? Kung oo ang sagot at may angkop na configuration ang organisasyon, pagmamay-ari ng host project ang VPC, mga subnet at konektividad, habang pagmamay-ari ng mga service project ang kanilang sariling mga resource ng application. Ang isang koneksyon ng Cloud VPN sa shared na network na iyon ay maaaring maglingkod sa mga inilaang prefix ng workload, napapailalim sa mga patakaran sa pag-ruta at seguridad .

Maging tiyak sa ginagawa ng association. Ang pagkakabit ng service project ay hindi nagsasama ng dati nitong independiyenteng VPC sa host network, at hindi awtomatikong naglilipat ng bawat resource. Ang pagkakabit ng workload, mga pahintulot, espasyo ng address at DNS ay bahagi ng arkitektura, hindi resulta ng setting. Basahin ang association bilang pagbabago ng pahintulot muna at pagbabago ng pag-ruta pagkatapos, dahil karaniwang natutuklasan ng mga team ang pagkakaiba sa panahon ng paglipat.

Kung hindi katanggap-tanggap ang sentral na pagmamay-ari sa mga kasangkot na team, huminto dito at ituring ang natitira bilang disenyo ng peering o hub. Ang pagpilit ng Shared VPC sa isang grupo na nangangailangan ng independiyenteng mga lifecycle ng network ay lumilikha ng pulitikal na problema na may teknikal na pangalan.

Suriin kung ang mga independiyenteng VPC ay maaaring manatiling independiyente

Pinapanatili ng peering ang magkakahiwalay na VPC, at iyon ang dahilan kung bakit ito umaakit sa mga team na gusto ang sarili nilang mga plano sa address at sarili nilang kontrol sa pagbabago. Ang bitag ay hindi transitive ang peering: ang peering A-sa-B at B-sa-C ay hindi mismo lumilikha ng pag-ruta A-sa-C sa pamamagitan ng B. Kung tatlong proyekto ang kailangang makarating sa isang hybrid na destinasyon, kailangan mo ng sinadyang plano ng pagpapalitan at hindi ng kadena ng peering.

Ang pagbabahagi ng hybrid na maabot ay nakasalalay din sa dokumentadong pagpapalitan ng custom na ruta at sa mga inilaang anunsyo ng Cloud Router. Ang aktibong estado ng peering ay nagpapatunay na umiiral ang peering, hindi na ang mga prefix na mahalaga sa bawat panig ay na-export kailanman. Suriin ang mga na-export na saklaw sa magkabilang panig ng peer, sa configuration na gumagawa ng export, at ihambing ang mga ito sa mga address na aktwal na ginagamit ng iyong mga workload. Ang hindi pagkakatugma doon ang pinakakaraniwang dahilan kung bakit mukhang malusog ang peering habang nananatiling hindi maabot ang isang prefix.

Isulat ang plano ng address bago ang lahat. Ang mga saklaw na hindi nagsasapawan, ang mga ruta patungo sa bawat inilaang destinasyon at ang mga anunsyo ng pagbabalik ay ang tatlong artifact na kinabubuhayan o ikinamamatay ng modelong ito.

Suriin kung ang modelo ng hub ay umaangkop sa topology

Para sa mas malaki o iba ang pagkakahating disenyo, inilalarawan ng pangkalahatang-tanaw ng Google Network Connectivity Center ang mga modelong hub at spoke. Basahin ito para sa sinusuportahan ng kasalukuyang release, hindi para sa ipinahihiwatig ng diagram: aling mga kombinasyon ng VPC at hybrid, aling mga pamilya ng ruta at aling mga patakaran ang pinapayagan ng bawat uri ng spoke.

Suriin ang pamilya ng address nang tahasan. Ang mga halimbawa ng pagpaplano sa karamihan ng gabay, kasama na ito, ay tungkol sa IPv4, at ang isang tampok na umiiral para sa isang uri ng spoke ay hindi awtomatikong nalalapat nang walang pagbabago sa isa pa. Kung ang iyong kapaligiran ay dual-stack, ang tanong na iyon ay kabilang sa pagpili ng modelo, hindi sa susunod na paglilipat.

Ang talahanayan sa ibaba ay ang buod ng tatlong modelo at ang tanong na nagpapasya sa bawat isa.

Suriin kung ano ang hindi ibinibigay ng pag-ruta

Ang pagpapalitan ng ruta ay hindi isang pangkalahatang pagbibigay ng tiwala. Ang resolusyon ng DNS, pahintulot ng firewall at awtorisasyon ng application ay nananatiling sariling responsibilidad, at ang bawat isa ay kinokonfigura ng ibang may-ari sa karamihan ng organisasyon. Ang isang disenyong ipinapalagay na ang maabot ay nangangahulugan ng awtorisasyon ay papasa sa pagsubok ng konektividad at babagsak sa pagsusuri ng seguridad.

Kumpirmahin din ang kuwento ng DNS para sa bawat modelo, dahil ang mga kaayusan ng zone at forwarding ay naiiba sa pagitan ng shared na network at mga peer na network. Ang mga pribadong pangalan na nalulutas sa isang proyekto ay hindi sumusunod sa isang ruta patungo sa isa pa.

Itala ang desisyon at ang may-ari nito

Isentralisa kung saan gusto ng organisasyon ang isang shared na may-ari ng network; panatilihin ang magkakahiwalay na VPC kung saan kailangan ito ng lifecycle o patakaran. Pagkatapos ay pumili ng sinusuportahang relasyon ng konektividad at isulat kung alin ang pinili mo, sino ang nagmamay-ari ng shared na network, at ano ang maaaring i-anunsyo ng bawat proyekto.

Ang pagbilang ng mga proyekto at pagbili ng isang VPN para sa bawat isa ay hindi kapalit ng desisyong iyon sa pagmamay-ari. Ito ang parehong desisyon, na ginawa mamaya, ng sinumang magmamana ng bill at ng talahanayan ng pag-ruta.