Jaringan diperlukan agar resource dapat berkomunikasi dalam organisasi Google Cloud Anda serta antara lingkungan cloud dan lingkungan lokal Anda. Bagian ini menjelaskan struktur dalam cetak biru untuk jaringan VPC, ruang alamat IP, DNS, kebijakan firewall, dan konektivitas ke lingkungan lokal.
Topologi jaringan
Repositori blueprint menyediakan opsi berikut untuk topologi jaringan Anda:
- Gunakan jaringan VPC Bersama terpisah untuk setiap lingkungan, tanpa traffic jaringan yang diizinkan secara langsung antarlingkungan.
- Gunakan model hub-and-spoke yang menambahkan jaringan hub untuk menghubungkan setiap lingkungan di Google Cloud, dengan traffic jaringan antarlingkungan yang dilindungi oleh alat virtual jaringan (NVA).
Pilih topologi jaringan VPC Bersama ganda jika Anda tidak menginginkan konektivitas jaringan langsung antarlingkungan. Pilih topologi jaringan hub-dan-spoke jika Anda ingin mengizinkan konektivitas jaringan antarlingkungan yang difilter oleh NVA, seperti ketika Anda mengandalkan alat yang ada yang memerlukan jalur jaringan langsung ke setiap server di lingkungan Anda.
Kedua topologi tersebut menggunakan VPC Bersama sebagai konstruksi jaringan utama karena VPC Bersama memungkinkan pemisahan tanggung jawab yang jelas. Administrator jaringan mengelola resource jaringan dalam project host terpusat, dan tim beban kerja men-deploy resource aplikasi mereka sendiri serta menggunakan resource jaringan dalam project layanan yang terpasang pada project host.
Kedua topologi tersebut mencakup versi dasar dan versi terbatas dari setiap jaringan VPC. Jaringan VPC dasar digunakan untuk resource yang berisi data non-sensitif, sedangkan jaringan VPC terbatas digunakan untuk resource dengan data sensitif yang memerlukan Kontrol Layanan VPC. Untuk mengetahui informasi lebih lanjut mengenai implementasi Kontrol Layanan VPC, baca artikel Melindungi resource Anda dengan Kontrol Layanan VPC.
Topologi jaringan VPC Bersama Ganda
Jika Anda memerlukan isolasi jaringan antara jaringan pengembangan, non-produksi, dan produksi di Google Cloud, sebaiknya gunakan topologi jaringan VPC Bersama ganda. Topologi ini menggunakan jaringan VPC Bersama yang terpisah untuk setiap lingkungan, dengan setiap lingkungan juga dipisahkan antara jaringan VPC Bersama dasar dan jaringan VPC Bersama terbatas.
Diagram berikut menunjukkan topologi jaringan VPC Bersama ganda.
Diagram ini menjelaskan konsep utama topologi VPC Bersama ganda:
- Setiap lingkungan (produksi, non-produksi, dan pengembangan) memiliki satu jaringan VPC Bersama untuk jaringan dasar dan satu jaringan VPC Bersama untuk jaringan terbatas. Diagram ini hanya menampilkan lingkungan produksi, tetapi pola yang sama diulang untuk setiap lingkungan.
- Setiap jaringan VPC Bersama memiliki dua subnet, yang setiap subnet berada di region berbeda.
- Konektivitas dengan resource lokal diaktifkan melalui empat lampiran VLAN ke instance Dedicated Interconnect untuk setiap jaringan VPC Bersama, menggunakan empat layanan Cloud Router (dua di setiap region untuk redundansi). Untuk mengetahui informasi selengkapnya, lihat Konektivitas hybrid antara lingkungan lokal dan Google Cloud.
Secara desain, topologi ini tidak memungkinkan traffic jaringan mengalir langsung di antara lingkungan. Jika memerlukan traffic jaringan untuk mengalir langsung antar-lingkungan, Anda harus mengambil langkah tambahan untuk mengizinkan jalur jaringan ini. Misalnya, Anda dapat mengonfigurasi endpoint Private Service Connect untuk mengekspos layanan dari satu jaringan VPC ke jaringan VPC lainnya. Atau, Anda dapat mengonfigurasi jaringan lokal agar traffic dapat mengalir dari satu lingkungan Google Cloud ke lingkungan lokal lalu ke lingkungan Google Cloud lainnya.
Topologi jaringan hub-and-spoke
Jika Anda men-deploy resource di Google Cloud yang memerlukan jalur jaringan langsung ke resource di beberapa lingkungan, sebaiknya gunakan topologi jaringan hub-and-spoke.
Topologi hub-and-spoke menggunakan beberapa konsep yang merupakan bagian dari topologi VPC Bersama ganda, tetapi memodifikasi topologi tersebut untuk menambahkan jaringan hub. Diagram berikut menunjukkan topologi hub-and-spoke.
Diagram menjelaskan konsep utama topologi jaringan hub-and-spoke berikut:
- Model ini menambahkan jaringan hub, dan setiap jaringan pengembangan, non-produksi, serta produksi (spoke) terhubung ke jaringan hub melalui Peering Jaringan VPC. Atau, jika Anda mengantisipasi melebihi batas kuota, Anda dapat menggunakan gateway VPN dengan ketersediaan tinggi (HA).
- Konektivitas ke jaringan lokal hanya diizinkan melalui jaringan hub. Semua jaringan yang berbicara dapat berkomunikasi dengan resource bersama di jaringan hub dan menggunakan jalur ini untuk terhubung ke jaringan lokal.
- Jaringan hub mencakup NVA untuk setiap region, yang di-deploy secara redundan di belakang instance Load Balancer Jaringan internal. NVA ini berfungsi sebagai gateway untuk mengizinkan atau menolak traffic berkomunikasi antara jaringan yang diucapkan.
- Jaringan hub juga menghosting alat yang memerlukan konektivitas ke semua jaringan lainnya. Misalnya, Anda dapat men-deploy alat pada instance VM untuk pengelolaan konfigurasi di lingkungan umum.
- Model hub-and-spoke diduplikasi untuk versi dasar dan versi terbatas dari setiap jaringan.
Untuk mengaktifkan traffic spoke-to-spoke, blueprint men-deploy NVA pada jaringan VPC bersama hub yang bertindak sebagai gateway antarjaringan. Rute dipertukarkan dari jaringan VPC hub-ke-spoke melalui pertukaran rute kustom. Dalam skenario ini, konektivitas antar-jari harus dirutekan melalui NVA karena Peering Jaringan VPC bersifat non-transitif, sehingga jaringan VPC bicara tidak dapat bertukar data satu sama lain secara langsung. Anda harus mengonfigurasi peralatan virtual untuk mengizinkan traffic di antara jari-jari secara selektif.
Untuk mengetahui informasi selengkapnya tentang penggunaan NVA guna mengontrol traffic antar- spoke, lihat peralatan jaringan terpusat di Google Cloud.
Pola deployment project
Saat membuat project baru untuk beban kerja, Anda harus menentukan cara resource dalam project ini terhubung ke jaringan yang ada. Tabel berikut menjelaskan pola untuk men-deploy project yang digunakan dalam cetak biru.
| Pola | Deskripsi | Contoh penggunaan |
|---|---|---|
| Project dasar bersama | Project ini dikonfigurasi sebagai project layanan ke project host VPC Bersama dasar. Gunakan pola ini saat resource dalam project Anda memiliki kriteria berikut:
|
example_base_shared_vpc_project.tf |
| Project yang dibatasi bersama | Project ini dikonfigurasi sebagai project layanan untuk project host VPC Bersama yang dibatasi. Gunakan pola ini saat resource dalam project Anda memiliki kriteria berikut:
|
example_restricted_shared_vpc_project.tf |
| Project mengambang | Project mengambang tidak terhubung ke jaringan VPC lain dalam topologi Anda. Gunakan pola ini saat resource dalam project Anda memiliki kriteria berikut:
Anda mungkin memiliki skenario saat ingin memisahkan jaringan VPC project mengambang dari topologi jaringan VPC utama, tetapi juga ingin mengekspos endpoint dalam jumlah yang terbatas di antara jaringan. Dalam hal ini, publikasikan layanan menggunakan Private Service Connect untuk membagikan akses jaringan ke setiap endpoint di seluruh jaringan VPC tanpa mengekspos seluruh jaringan. |
example_floating_project.tf |
| Project peering | Project peering membuat jaringan VPC-nya sendiri dan melakukan peering ke jaringan VPC lain dalam topologi Anda. Gunakan pola ini saat resource dalam project Anda memiliki kriteria berikut:
Jika membuat project peering, Anda bertanggung jawab untuk mengalokasikan rentang alamat IP yang tidak bertentangan dan merencanakan kuota grup peering. |
example_peering_project.tf |
Alokasi alamat IP
Bagian ini memperkenalkan cara arsitektur blueprint mengalokasikan rentang alamat IP. Anda mungkin perlu mengubah rentang alamat IP tertentu yang digunakan berdasarkan ketersediaan alamat IP di lingkungan hybrid yang ada.
Tabel berikut memberikan perincian ruang alamat IP yang dialokasikan untuk cetak biru. Lingkungan hub hanya berlaku dalam topologi hub-and-spoke.
| Tujuan | Jenis VPC | Region | Lingkungan hub | Lingkungan pengembangan | Lingkungan non-produksi | Lingkungan produksi |
|---|---|---|---|---|---|---|
| Rentang subnet utama | Base | Region 1 | 10.0.0.0/18 | 10.0.64.0/18 | 10.0.128.0/18 | 10.0.192.0/18 |
| Region 2 | 10.1.0.0/18 | 10.1.64.0/18 | 10.1.128.0/18 | 10.1.192.0/18 | ||
| Belum dialokasikan | 10.{2-7}.0.0/18 | 10.{2-7}.64.0/18 | 10.{2-7}.128.0/18 | 10.{2-7}.192.0/18 | ||
| Dibatasi | Region 1 | 10.8.0.0/18 | 10.8.64.0/18 | 10.8.128.0/18 | 10.8.192.0/18 | |
| Region 2 | 10.9.0.0/18 | 10.9.64.0/18 | 10.9.128.0/18 | 10.9.192.0/18 | ||
| Belum dialokasikan | 10.{10-15}.0.0/18 | 10.{10-15}.64.0/18 | 10.{10-15}.128.0/18 | 10.{10-15}.192.0/18 | ||
| Akses layanan pribadi | Base | Global | 10.16.0.0/21 | 10.16.8.0/21 | 10.16.16.0/21 | 10.16.24.0/21 |
| Dibatasi | Global | 10.16.32.0/21 | 10.16.40.0/21 | 10.16.48.0/21 | 10.16.56.0/21 | |
| Endpoint Private Service Connect | Base | Global | 10.17.0.1/32 | 10.17.0.2/32 | 10.17.0.3/32 | 10.17.0.4/32 |
| Dibatasi | Global | 10.17.0.5/32 | 10.17.0.6/32 | 10.17.0.7/32 | 10.17.0.8/32 | |
| Subnet khusus proxy | Base | Region 1 | 10.18.0.0/23 | 10.18.2.0/23 | 10.18.4.0/23 | 10.18.6.0/23 |
| Region 2 | 10.19.0.0/23 | 10.19.2.0/23 | 10.19.4.0/23 | 10.19.6.0/23 | ||
| Belum dialokasikan | 10.{20-25}.0.0/23 | 10.{20-25}.2.0/23 | 10.{20-25}.4.0/23 | 10.{20-25}.6.0/23 | ||
| Dibatasi | Region 1 | 10.26.0.0/23 | 10.26.2.0/23 | 10.26.4.0/23 | 10.26.6.0/23 | |
| Region 2 | 10.27.0.0/23 | 10.27.2.0/23 | 10.27.4.0/23 | 10.27.6.0/23 | ||
| Belum dialokasikan | 10.{28-33}.0.0/23 | 10.{28-33}.2.0/23 | 10.{28-33}.4.0/23 | 10.{28-33}.6.0/23 | ||
| Rentang subnet sekunder | Base | Region 1 | 100.64.0.0/18 | 100.64.64.0/18 | 100.64.128.0/18 | 100.64.192.0/18 |
| Region 2 | 100.65.0.0/18 | 100.65.64.0/18 | 100.65.128.0/18 | 100.65.192.0/18 | ||
| Belum dialokasikan | 100.{66-71}.0.0/18 | 100.{66-71}.64.0/18 | 100.{66-71}.128.0/18 | 100.{66-71}.192.0/18 | ||
| Dibatasi | Region 1 | 100.72.0.0/18 | 100.72.64.0/18 | 100.72.128.0/18 | 100.72.192.0/18 | |
| Region 2 | 100.73.0.0/18 | 100.73.64.0/18 | 100.73.128.0/18 | 100.73.192.0/18 | ||
| Belum dialokasikan | 100.{74-79}.0.0/18 | 100.{74-79}.64.0/18 | 100.{74-79}.128.0/18 | 100.{74-79}.192.0/18 |
Tabel sebelumnya menunjukkan konsep berikut untuk mengalokasikan rentang alamat IP:
- Alokasi alamat IP dibagi menjadi beberapa rentang untuk setiap kombinasi VPC Bersama dasar, VPC Bersama yang dibatasi, region, dan lingkungan.
- Beberapa resource bersifat global dan tidak memerlukan subdivisi untuk setiap wilayah.
- Secara default, untuk resource regional, cetak biru akan di-deploy di dua region. Selain itu, ada rentang alamat IP yang tidak digunakan sehingga Anda dapat memperluasnya ke enam region tambahan.
- Jaringan hub hanya digunakan dalam topologi jaringan hub-and-spoke, sedangkan lingkungan pengembangan, non-produksi, dan produksi digunakan dalam kedua topologi jaringan.
Tabel berikut memperkenalkan cara menggunakan setiap jenis rentang alamat IP.
| Tujuan | Deskripsi |
|---|---|
| Rentang subnet utama | Resource yang Anda deploy ke jaringan VPC, seperti instance mesin virtual, menggunakan alamat IP internal dari rentang ini. |
| Akses layanan pribadi | Beberapa layanan Google Cloud seperti Cloud SQL mengharuskan Anda mengalokasikan lebih dahulu rentang subnet untuk akses layanan pribadi. Blueprint mencadangkan rentang /21 secara global untuk setiap jaringan VPC Bersama guna mengalokasikan alamat IP untuk layanan yang memerlukan akses layanan pribadi. Saat membuat layanan yang bergantung pada akses layanan pribadi, Anda mengalokasikan subnet /24 regional dari rentang /21 yang dicadangkan. |
| Private Service Connect | Blueprint menyediakan setiap jaringan VPC dengan endpoint Private Service Connect untuk berkomunikasi dengan Google Cloud API. Endpoint ini memungkinkan resource Anda di jaringan VPC menjangkau Google Cloud API tanpa mengandalkan traffic keluar ke internet atau rentang internet yang diiklankan secara publik. |
| Load balancer berbasis proxy | Beberapa jenis Load Balancer Aplikasi mengharuskan Anda untuk mengalokasikan subnet khusus proxy terlebih dahulu. Meskipun cetak biru ini tidak men-deploy Load Balancer Aplikasi yang memerlukan rentang ini, mengalokasikan rentang di awal akan membantu mengurangi hambatan untuk workload saat perlu meminta rentang subnet baru untuk mengaktifkan resource load balancer tertentu. |
| Rentang subnet sekunder | Beberapa kasus penggunaan, seperti beban kerja berbasis container, memerlukan rentang sekunder. Blueprint mengalokasikan rentang dari ruang alamat IP RFC 6598 untuk rentang sekunder. |
Penyiapan DNS terpusat
Untuk resolusi DNS antara Google Cloud dan lingkungan lokal, sebaiknya gunakan pendekatan campuran dengan dua sistem DNS otoritatif. Dalam pendekatan ini, Cloud DNS menangani resolusi DNS otoritatif untuk lingkungan Google Cloud Anda, sedangkan server DNS lokal yang ada menangani resolusi DNS otoritatif untuk resource lokal. Lingkungan lokal Anda dan lingkungan Google Cloud melakukan pencarian DNS antarlingkungan melalui permintaan penerusan.
Diagram berikut menunjukkan topologi DNS di beberapa jaringan VPC yang digunakan dalam blueprint.
Diagram ini menjelaskan komponen desain DNS berikut yang di-deploy oleh cetak biru:
- Project hub DNS di folder umum adalah titik pusat pertukaran DNS antara lingkungan lokal dan lingkungan Google Cloud. Penerusan DNS menggunakan instance Dedicated Interconnect dan Cloud Router yang sama dengan yang sudah dikonfigurasi di topologi jaringan Anda.
- Dalam topologi VPC Bersama ganda, hub DNS menggunakan jaringan VPC Bersama produksi dasar.
- Dalam topologi hub-and-spoke, hub DNS menggunakan jaringan VPC bersama hub dasar.
- Server di setiap jaringan VPC Bersama dapat me-resolve data DNS dari jaringan VPC Bersama lainnya melalui penerusan DNS, yang dikonfigurasi antara Cloud DNS di setiap project host VPC Bersama dan hub DNS.
- Server lokal dapat menyelesaikan data DNS di lingkungan Google Cloud menggunakan kebijakan server DNS yang memungkinkan kueri dari server lokal. Blueprint mengonfigurasi kebijakan server masuk di hub DNS untuk mengalokasikan alamat IP, dan server DNS lokal meneruskan permintaan ke alamat ini. Semua permintaan DNS ke Google Cloud akan mencapai hub DNS terlebih dahulu, yang kemudian menyelesaikan data dari peer DNS.
- Server di Google Cloud dapat me-resolve data DNS di lingkungan lokal menggunakan zona penerusan yang mengkueri server lokal. Semua permintaan DNS ke lingkungan lokal berasal dari hub DNS. Sumber permintaan DNS adalah 35.199.192.0/19.
Kebijakan firewall
Google Cloud memiliki beberapa jenis kebijakan firewall. Kebijakan firewall hierarkis diterapkan pada level organisasi atau folder untuk mewarisi aturan kebijakan firewall secara konsisten di semua resource dalam hierarki. Selain itu, Anda dapat mengonfigurasi kebijakan firewall jaringan untuk setiap jaringan VPC. Blueprint menggabungkan kebijakan firewall ini untuk menerapkan konfigurasi umum di semua lingkungan menggunakan kebijakan firewall Hierarkis dan untuk menerapkan konfigurasi yang lebih spesifik di setiap jaringan VPC menggunakan kebijakan firewall jaringan.
Blueprint tidak menggunakan aturan firewall VPC lama. Sebaiknya hanya gunakan kebijakan firewall dan hindari penggunaan campuran dengan aturan firewall VPC lama.
Kebijakan firewall hierarkis
Blueprint menetapkan satu kebijakan firewall hierarkis dan melampirkan kebijakan tersebut ke setiap folder produksi, non-produksi, pengembangan, bootstrap, dan umum. Kebijakan firewall hierarkis ini berisi aturan yang harus diterapkan secara luas di semua lingkungan, dan mendelegasikan evaluasi aturan yang lebih terperinci ke kebijakan firewall jaringan untuk setiap lingkungan.
Tabel berikut menjelaskan aturan kebijakan firewall hierarkis yang di-deploy oleh blueprint.
| Deskripsi aturan | Arah traffic | Filter (rentang IPv4) | Protocols and ports | Tindakan |
|---|---|---|---|---|
| Delegasikan evaluasi traffic masuk dari RFC 1918 ke level yang lebih rendah dalam hierarki. | Ingress |
192.168.0.0/16, 10.0.0.0/8, 172.16.0.0/12 |
all |
Go to next |
| Delegasikan evaluasi traffic keluar ke RFC 1918 ke level yang lebih rendah dalam hierarki. | Egress |
192.168.0.0/16, 10.0.0.0/8, 172.16.0.0/12 |
all |
Go to next |
| IAP untuk penerusan TCP | Ingress |
35.235.240.0/20 |
tcp:22,3390 |
Allow |
| Aktivasi server Windows | Egress |
35.190.247.13/32 |
tcp:1688 |
Allow |
| Health check untuk Cloud Load Balancing | Ingress |
130.211.0.0/22, 35.191.0.0/16, 209.85.152.0/22, 209.85.204.0/22 |
tcp:80,443 |
Allow |
Kebijakan firewall jaringan
Blueprint mengonfigurasi kebijakan firewall jaringan untuk setiap jaringan. Setiap kebijakan firewall jaringan dimulai dengan serangkaian aturan minimum yang mengizinkan akses ke layanan Google Cloud dan menolak traffic keluar ke semua alamat IP lainnya.
Pada model hub-and-spoke, kebijakan firewall jaringan berisi aturan tambahan untuk memungkinkan komunikasi antara spoke. Kebijakan firewall jaringan memungkinkan traffic keluar dari satu hub atau sambungan lainnya, dan memungkinkan traffic masuk dari NVA di jaringan hub.
Tabel berikut menjelaskan aturan dalam kebijakan firewall jaringan global yang di-deploy untuk setiap jaringan VPC dalam blueprint.
| Deskripsi aturan | Arah traffic | Filter | Protocols and ports |
|---|---|---|---|
| Mengizinkan traffic keluar ke Google Cloud API. | Egress |
Endpoint Private Service Connect yang dikonfigurasi untuk setiap jaringan individual. Lihat Akses pribadi ke Google API. | tcp:443 |
| Menolak traffic keluar yang tidak cocok dengan aturan lain. | Egress |
all | all |
Izinkan traffic keluar dari satu spoke ke spoke lainnya (hanya untuk model hub-and-spoke). |
Egress |
Agregat semua alamat IP yang digunakan dalam topologi hub-and-spoke. Traffic yang keluar dari VPC yang dibicarakan akan dirutekan ke NVA di jaringan hub terlebih dahulu. | all |
Mengizinkan traffic masuk ke spoke dari NVA di jaringan hub (hanya untuk model hub-dan-spoke). |
Ingress |
Lalu lintas yang berasal dari NVA di jaringan hub. | all |
Saat Anda pertama kali men-deploy blueprint, instance VM di jaringan VPC dapat berkomunikasi dengan layanan Google Cloud, tetapi tidak dengan resource infrastruktur lain dalam jaringan VPC yang sama. Agar instance VM dapat berkomunikasi, Anda harus menambahkan aturan tambahan ke kebijakan firewall jaringan dan tag yang secara eksplisit mengizinkan instance VM untuk berkomunikasi. Tag ditambahkan ke instance VM, dan traffic akan dievaluasi berdasarkan tag tersebut. Tag juga memiliki kontrol IAM sehingga Anda dapat menentukannya secara terpusat dan mendelegasikan penggunaannya kepada tim lain.
Diagram berikut menunjukkan contoh cara menambahkan tag kustom dan aturan kebijakan firewall jaringan agar beban kerja berkomunikasi di dalam jaringan VPC.
Diagram menunjukkan konsep berikut dari contoh ini:
- Kebijakan firewall jaringan berisi Aturan 1 yang menolak traffic keluar dari semua sumber pada prioritas 65530.
- Kebijakan firewall jaringan berisi Aturan 2 yang mengizinkan traffic masuk
dari instance dengan tag
service=frontendke instance dengan tagservice=backendpada prioritas 999. - VM instance-2 dapat menerima traffic dari instance-1 karena traffic-nya cocok dengan tag yang diizinkan oleh Aturan 2. Aturan 2 dicocokkan sebelum Aturan 1 dievaluasi, berdasarkan nilai prioritas.
- VM instance-3 tidak menerima traffic. Satu-satunya aturan kebijakan firewall yang cocok dengan traffic ini adalah Aturan 1, sehingga traffic keluar dari instance-1 ditolak.
Akses pribadi ke Google Cloud API
Agar resource di jaringan VPC atau lingkungan lokal Anda dapat menjangkau layanan Google Cloud, sebaiknya gunakan konektivitas pribadi, bukan traffic internet keluar ke endpoint API publik. Blueprint mengonfigurasi Akses Google Pribadi di setiap subnet dan membuat endpoint internal dengan Private Service Connect untuk berkomunikasi dengan layanan Google Cloud. Jika digunakan bersamaan, kontrol ini memungkinkan jalur pribadi ke layanan Google Cloud, tanpa mengandalkan traffic keluar internet atau rentang internet yang diiklankan secara publik.
Blueprint mengonfigurasi endpoint Private Service Connect dengan paket API untuk membedakan layanan yang dapat diakses di jaringan tertentu. Jaringan dasar menggunakan paket all-apis dan dapat menjangkau layanan Google apa pun, sedangkan jaringan yang dibatasi menggunakan paket vpcsc yang memungkinkan akses ke kumpulan layanan terbatas yang mendukung Kontrol Layanan VPC.
Untuk akses dari host yang berada di lingkungan lokal, sebaiknya gunakan konvensi FQDN kustom untuk setiap endpoint, seperti yang dijelaskan dalam tabel berikut. Blueprint ini menggunakan endpoint Private Service Connect unik untuk setiap jaringan VPC, yang dikonfigurasi untuk mengakses berbagai paket API. Oleh karena itu, Anda harus mempertimbangkan cara merutekan traffic layanan dari lingkungan lokal ke jaringan VPC dengan endpoint API yang benar. Selain itu, pastikan bahwa traffic ke layanan Google Cloud mencapai endpoint di dalam perimeter yang diinginkan, jika Anda menggunakan Kontrol Layanan VPC. Konfigurasikan kontrol lokal untuk DNS, firewall, dan router guna mengizinkan akses ke endpoint tersebut, serta mengonfigurasi host lokal agar menggunakan endpoint yang sesuai. Untuk mengetahui informasi selengkapnya, lihat mengakses Google API melalui endpoint.
Tabel berikut menjelaskan endpoint Private Service Connect yang dibuat untuk setiap jaringan.
| VPC | Lingkungan | Paket API | Alamat IP endpoint Private Service Connect | FQDN Kustom | ||||
|---|---|---|---|---|---|---|---|---|
| Base | Umum | all-apis |
10.17.0.1/32 | c.private.googleapis.com |
||||
| Pengembangan | all-apis |
10.17.0.2/32 | d.private.googleapis.com |
|||||
| Non-produksi | all-apis |
10.17.0.3/32 | n.private.googleapis.com |
|||||
| Produksi | all-apis |
10.17.0.4/32 | p.private.googleapis.com |
|||||
| Dibatasi | Umum | vpcsc |
10.17.0.5/32 | c.restricted.googleapis.com |
||||
| Pengembangan | vpcsc |
10.17.0.6/32 | d.restricted.googleapis.com |
|||||
| Non-produksi | vpcsc |
10.17.0.7/32 | n.restricted.googleapis.com |
|||||
| Produksi | vpcsc |
10.17.0.8/32 | p.restricted.googleapis.com |
|||||
Guna memastikan bahwa traffic layanan Google Cloud memiliki pencarian DNS ke endpoint yang benar, blueprint mengonfigurasi zona DNS pribadi untuk setiap jaringan VPC. Tabel berikut menjelaskan zona DNS pribadi ini.
| Nama zona pribadi | Nama DNS | Jenis data | Data |
|---|---|---|---|
googleapis.com. |
*.googleapis.com. |
CNAME |
private.googleapis.com. (untuk jaringan
dasar) atau restricted.googleapis.com. (untuk
jaringan yang dibatasi) |
private.googleapis.com (untuk jaringan
dasar) atau restricted.googleapis.com (untuk
jaringan yang dibatasi) |
A |
Alamat IP endpoint Private Service Connect untuk jaringan VPC tersebut. | |
gcr.io. |
*.gcr.io |
CNAME |
gcr.io. |
gcr.io |
A |
Alamat IP endpoint Private Service Connect untuk jaringan VPC tersebut. | |
pkg.dev. |
*.pkg.dev. |
CNAME |
pkg.dev. |
pkg.dev. |
A |
Alamat IP endpoint Private Service Connect untuk jaringan VPC tersebut. |
Blueprint memiliki konfigurasi tambahan untuk memastikan bahwa endpoint Private Service Connect ini digunakan secara konsisten. Setiap jaringan VPC Bersama juga menerapkan hal berikut:
- Aturan kebijakan firewall jaringan yang mengizinkan traffic keluar dari semua sumber ke alamat IP endpoint Private Service Connect di TCP:443.
- Aturan kebijakan firewall jaringan yang menolak traffic keluar ke 0.0.0.0/0, yang mencakup domain default yang digunakan untuk mengakses layanan Google Cloud.
Konektivitas internet
Blueprint tidak mengizinkan traffic masuk atau keluar antara jaringan VPC-nya dan internet. Untuk beban kerja yang memerlukan konektivitas internet, Anda harus mengambil langkah tambahan untuk mendesain jalur akses yang diperlukan.
Untuk workload yang memerlukan traffic keluar ke internet, sebaiknya kelola traffic keluar melalui Cloud NAT untuk mengizinkan traffic keluar tanpa koneksi masuk yang tidak diminta, atau melalui Secure Web Proxy untuk kontrol yang lebih terperinci guna mengizinkan traffic keluar hanya ke layanan web tepercaya.
Untuk workload yang memerlukan traffic masuk dari internet, sebaiknya desain workload dengan Cloud Load Balancing dan Google Cloud Armor untuk mendapatkan manfaat dari perlindungan DDoS dan WAF.
Sebaiknya jangan mendesain beban kerja yang memungkinkan konektivitas langsung antara internet dan VM menggunakan alamat IP eksternal di VM.
Konektivitas hybrid antara lingkungan lokal dan Google Cloud
Untuk membangun konektivitas antara lingkungan lokal dan Google Cloud, sebaiknya gunakan Dedicated Interconnect untuk memaksimalkan keamanan dan keandalan. Koneksi Dedicated Interconnect adalah link langsung antara jaringan lokal Anda dan Google Cloud.
Diagram berikut memperkenalkan konektivitas hybrid antara lingkungan lokal dan jaringan Virtual Private Cloud Google.
Diagram menjelaskan komponen pola berikut untuk ketersediaan 99,99% untuk Dedicated Interconnect:
- Empat koneksi Dedicated Interconnect, dengan dua koneksi di satu area metropolitan (metro) dan dua koneksi di metro lainnya.
- Koneksi dibagi menjadi dua pasangan, dan setiap pasangan terhubung ke pusat data lokal yang terpisah.
- Lampiran VLAN digunakan untuk menghubungkan setiap instance Dedicated Interconnect ke Cloud Router yang terhubung ke topologi VPC Bersama. Lampiran VLAN ini
dihosting di project
prj-c-interconnect. - Setiap jaringan VPC Bersama memiliki empat Cloud Router, dua di setiap region, dengan mode perutean dinamis yang disetel ke
globalsehingga setiap Cloud Router dapat mengumumkan semua subnet, terlepas dari region.
Dengan perutean dinamis global, Cloud Router mengiklankan rute ke semua subnet di jaringan VPC. Cloud Router mengiklankan rute ke subnet jarak jauh (subnet di luar region Cloud Router) dengan prioritas lebih rendah dibandingkan dengan subnet lokal (subnet yang berada di region Cloud Router). Secara opsional, Anda dapat mengubah prefiks dan prioritas yang diiklankan saat mengonfigurasi sesi BGP untuk Cloud Router.
Traffic dari Google Cloud ke lingkungan lokal menggunakan Cloud Router yang terdekat dengan resource cloud. Dalam satu region, beberapa rute ke jaringan lokal memiliki nilai multi-exit discriminator (MED) yang sama, dan Google Cloud menggunakan perutean multi-jalur dengan biaya yang sama (ECMP) untuk mendistribusikan traffic keluar di antara semua kemungkinan rute.
Perubahan konfigurasi lokal
Untuk mengonfigurasi konektivitas antara lingkungan lokal dan Google Cloud, Anda harus mengonfigurasi perubahan tambahan di lingkungan lokal. Kode Terraform dalam blueprint akan otomatis mengonfigurasi resource Google Cloud, tetapi tidak mengubah resource jaringan lokal Anda.
Beberapa komponen untuk konektivitas hybrid dari lingkungan lokal Anda ke Google Cloud diaktifkan secara otomatis oleh blueprint, yang meliputi hal berikut:
- Cloud DNS dikonfigurasi dengan penerusan DNS antara semua jaringan VPC Bersama ke satu hub, seperti yang dijelaskan dalam penyiapan DNS. Kebijakan server Cloud DNS dikonfigurasi dengan alamat IP penerus masuk.
- Cloud Router dikonfigurasi untuk mengekspor rute untuk semua subnet dan rute kustom bagi alamat IP yang digunakan oleh endpoint Private Service Connect.
Untuk mengaktifkan konektivitas hybrid, Anda harus melakukan langkah-langkah tambahan berikut:
- Pesan koneksi Dedicated Interconnect.
- Konfigurasikan router dan firewall lokal untuk mengizinkan traffic keluar ke ruang alamat IP internal yang ditentukan dalam alokasi ruang alamat IP.
- Konfigurasikan server DNS lokal Anda untuk meneruskan pencarian DNS yang terikat untuk Google Cloud ke alamat IP penerusan masuk yang sudah dikonfigurasi oleh blueprint.
- Konfigurasikan server DNS lokal, firewall, dan router Anda untuk menerima kueri DNS dari zona penerusan Cloud DNS (35.199.192.0/19).
- Konfigurasikan server DNS lokal untuk merespons kueri dari host lokal ke layanan Google Cloud dengan alamat IP yang ditentukan dalam akses pribadi ke Cloud API.
- Untuk enkripsi dalam pengiriman melalui koneksi Dedicated Interconnect, konfigurasikan MACsec untuk Cloud Interconnect atau konfigurasikan VPN dengan ketersediaan tinggi (HA) melalui Cloud Interconnect untuk enkripsi IPsec.
Untuk mengetahui informasi selengkapnya, lihat Akses Google Pribadi untuk host lokal.
Langkah selanjutnya
- Baca kontrol detektif (dokumen berikutnya dalam rangkaian ini).