Jaringan diperlukan agar resource dapat berkomunikasi dalam organisasi Google Cloud Anda dan antara lingkungan cloud dan lingkungan lokal Anda. Bagian ini menjelaskan struktur dalam blueprint 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 yang terpisah untuk setiap lingkungan, tanpa traffic jaringan yang diizinkan secara langsung di antara lingkungan.
- Gunakan model hub-and-spoke yang menambahkan jaringan hub untuk menghubungkan setiap lingkungan di Google Cloud, dengan traffic jaringan antar-lingkungan dibatasi oleh peralatan virtual jaringan (NVA).
Pilih topologi jaringan Shared VPC ganda jika Anda tidak ingin konektivitas jaringan langsung antar-lingkungan. Pilih topologi jaringan hub-and-spoke jika Anda ingin mengizinkan konektivitas jaringan antar-lingkungan yang difilter oleh NVA, seperti saat 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 dan menggunakan resource jaringan dalam project layanan yang dilampirkan ke project host.
Kedua topologi tersebut menyertakan versi dasar dan versi terbatas dari setiap jaringan VPC. Jaringan VPC dasar digunakan untuk resource yang berisi data non-sensitif, dan jaringan VPC yang dibatasi digunakan untuk resource dengan data sensitif yang memerlukan Kontrol Layanan VPC. Untuk informasi selengkapnya tentang cara menerapkan Kontrol Layanan VPC, lihat 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 dibagi 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 ini:
- 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 menunjukkan lingkungan produksi, tetapi pola yang sama diulang untuk setiap lingkungan.
- Setiap jaringan VPC Bersama memiliki dua subnet, dengan setiap subnet di region yang 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 on-premise dan Google Cloud.
Berdasarkan desainnya, topologi ini tidak mengizinkan traffic jaringan mengalir langsung di antara lingkungan. Jika Anda memerlukan traffic jaringan untuk mengalir langsung antar-lingkungan, Anda harus melakukan 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 lain. Atau, Anda dapat mengonfigurasi jaringan lokal untuk mengizinkan traffic 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 mengubah topologi untuk menambahkan jaringan hub. Diagram berikut menunjukkan topologi hub-and-spoke.
Diagram ini menjelaskan konsep utama topologi jaringan hub-and-spoke berikut:
- Model ini menambahkan jaringan hub, dan setiap jaringan pengembangan, non-produksi, dan produksi (spoke) terhubung ke jaringan hub melalui Peering Jaringan VPC. Atau, jika Anda memperkirakan akan melampaui batas kuota, Anda dapat menggunakan gateway VPN dengan ketersediaan tinggi (HA).
- Konektivitas ke jaringan lokal hanya diizinkan melalui jaringan hub. Semua jaringan spoke dapat berkomunikasi dengan resource bersama di jaringan hub dan menggunakan jalur ini untuk terhubung ke jaringan lokal.
- Jaringan hub menyertakan 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 agar dapat berkomunikasi antar-jaringan spoke.
- Jaringan hub juga menghosting alat yang memerlukan konektivitas ke semua jaringan lainnya. Misalnya, Anda dapat men-deploy alat di instance VM untuk pengelolaan konfigurasi ke 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 di jaringan VPC Bersama hub yang berfungsi sebagai gateway antar-jaringan. Rute ditukarkan dari jaringan VPC hub-ke-spoke melalui pertukaran rute kustom. Dalam skenario ini, konektivitas antara spoke harus dirutekan melalui NVA karena Peering Jaringan VPC bersifat non-transitif, sehingga jaringan VPC spoke tidak dapat saling bertukar data secara langsung. Anda harus mengonfigurasi peralatan virtual untuk mengizinkan traffic secara selektif di antara spoke.
Pola deployment project
Saat membuat project baru untuk beban kerja, Anda harus memutuskan cara resource dalam project ini terhubung ke jaringan yang ada. Tabel berikut menjelaskan pola untuk men-deploy project yang digunakan dalam blueprint.
| Pola | Deskripsi | Contoh penggunaan |
|---|---|---|
| Project dasar bersama | Project ini dikonfigurasi sebagai project layanan ke project host VPC Bersama dasar. Gunakan pola ini jika resource dalam project Anda memiliki kriteria berikut:
|
example_base_shared_vpc_project.tf |
| Project bersama yang dibatasi | Project ini dikonfigurasi sebagai project layanan ke project host VPC Bersama yang dibatasi. Gunakan pola ini jika 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 jika resource dalam project Anda memiliki kriteria berikut:
Anda mungkin memiliki skenario saat ingin mempertahankan jaringan VPC project mengambang terpisah dari topologi jaringan VPC utama, tetapi juga ingin mengekspos sejumlah terbatas endpoint di antara jaringan. Dalam hal ini, publikasikan layanan menggunakan Private Service Connect untuk berbagi 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 jika resource dalam project Anda memiliki kriteria berikut:
Jika Anda 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 blueprint. Lingkungan hub hanya berlaku dalam topologi hub-and-spoke.
| Tujuan | Jenis VPC | Wilayah | Lingkungan hub | Lingkungan pengembangan | Lingkungan non-produksi | Lingkungan produksi |
|---|---|---|---|---|---|---|
| Rentang subnet utama | Dasar | 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 | Dasar | 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 | Dasar | 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 | Dasar | 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 | Dasar | 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 ini untuk mengalokasikan rentang alamat IP:
- Alokasi alamat IP dibagi lagi 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 region.
- Secara default, untuk resource regional, blueprint di-deploy di dua region. Selain itu, ada rentang alamat IP yang tidak digunakan sehingga Anda dapat memperluas 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 penggunaan setiap jenis rentang alamat IP.
| Tujuan | Deskripsi |
|---|---|
| Rentang subnet utama | Resource yang Anda deploy ke jaringan VPC, seperti instance virtual machine, menggunakan alamat IP internal dari rentang ini. |
| Akses layanan pribadi | Beberapa layanan Google Cloud seperti Cloud SQL mengharuskan Anda mengalokasikan rentang subnet terlebih dahulu 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 melakukan pra-alokasi subnet khusus proxy. Meskipun blueprint tidak men-deploy Application Load Balancer yang memerlukan rentang ini, mengalokasikan rentang terlebih dahulu 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 mengaloksir rentang dari ruang alamat IP RFC 6598 untuk rentang sekunder. |
Penyiapan DNS terpusat
Untuk resolusi DNS antara Google Cloud dan lingkungan lokal, sebaiknya Anda menggunakan pendekatan campuran dengan dua sistem DNS yang kredibel. Dalam pendekatan ini, Cloud DNS menangani resolusi DNS yang kredibel untuk lingkungan Google Cloud Anda dan server DNS lokal yang ada menangani resolusi DNS yang kredibel untuk resource lokal. Lingkungan lokal Anda dan lingkungan Google Cloud melakukan pencarian DNS di antara lingkungan 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 blueprint:
- 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
yang sudah dikonfigurasi dalam 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 me-resolve data DNS di lingkungan Google Cloud menggunakan kebijakan server DNS yang mengizinkan 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 menjangkau hub DNS terlebih dahulu, yang kemudian me-resolve 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 di tingkat 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 ini 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 gunakan hanya kebijakan firewall dan hindari penggunaan campuran dengan aturan firewall VPC lama.
Kebijakan firewall hierarkis
Blueprint menentukan satu kebijakan firewall hierarkis dan melampirkan kebijakan 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 | Direction of traffic | Filter (rentang IPv4) | Protocols and ports | Tindakan |
|---|---|---|---|---|
| Delegasikan evaluasi traffic masuk dari RFC 1918 ke tingkat 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 tingkat 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 |
| Aktifasi 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 kumpulan aturan minimum yang mengizinkan akses ke layanan Google Cloud dan menolak keluar ke semua alamat IP lainnya.
Dalam model hub-and-spoke, kebijakan firewall jaringan berisi aturan tambahan untuk mengizinkan komunikasi antar-spoke. Kebijakan firewall jaringan mengizinkan traffic keluar dari satu spoke ke hub atau spoke lain, dan mengizinkan 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 | Direction of traffic | Filter | Protocols and ports |
|---|---|---|---|
| Izinkan traffic keluar ke Google Cloud API. | Egress |
Endpoint Private Service Connect yang dikonfigurasi untuk setiap jaringan. Lihat Akses pribadi ke Google API. | tcp:443 |
| Menolak traffic keluar yang tidak cocok dengan aturan lain. | Egress |
semua | all |
Mengizinkan traffic keluar dari satu spoke ke spoke lain (khusus model hub-and-spoke). |
Egress |
Agregat dari semua alamat IP yang digunakan dalam topologi hub-and-spoke. Traffic yang keluar dari VPC spoke dirutekan ke NVA di jaringan hub terlebih dahulu. | all |
Mengizinkan traffic masuk ke spoke dari NVA di jaringan hub (khusus model hub-and-spoke). |
Ingress |
Traffic 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 di 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 dievaluasi berdasarkan tag tersebut. Tag juga memiliki kontrol IAM sehingga Anda dapat menentukannya secara terpusat dan mendelegasikan penggunaannya ke tim lain.
Diagram berikut menunjukkan contoh cara menambahkan tag kustom dan aturan kebijakan firewall jaringan agar beban kerja dapat berkomunikasi di dalam jaringan VPC.
Diagram ini menunjukkan konsep berikut dari contoh ini:
- Kebijakan firewall jaringan berisi Aturan 1 yang menolak traffic keluar dari semua sumber dengan prioritas 65530.
- Kebijakan firewall jaringan berisi Aturan 2 yang mengizinkan traffic masuk dari instance dengan tag
service=frontendke instance dengan tagservice=backenddengan prioritas 999. - VM instance-2 dapat menerima traffic dari instance-1 karena traffic 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 akan 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 bersama, kontrol ini akan 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 mana yang dapat diakses di jaringan mana. Jaringan dasar
menggunakan paket all-apis dan dapat menjangkau layanan Google apa pun, dan 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 Anda menggunakan konvensi FQDN kustom untuk setiap endpoint, seperti yang dijelaskan dalam tabel berikut. Blueprint menggunakan endpoint Private Service Connect unik untuk setiap jaringan VPC, yang dikonfigurasi untuk akses ke kumpulan paket API yang berbeda. Oleh karena itu, Anda harus mempertimbangkan cara merutekan traffic layanan dari lingkungan lokal ke jaringan VPC dengan endpoint API yang benar, dan jika Anda menggunakan Kontrol Layanan VPC, pastikan traffic ke layanan Google Cloud mencapai endpoint di dalam perimeter yang diinginkan. Konfigurasikan kontrol lokal Anda untuk DNS, firewall, dan router agar mengizinkan akses ke endpoint ini, dan konfigurasikan host lokal untuk menggunakan endpoint yang sesuai. Untuk 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 | ||||
|---|---|---|---|---|---|---|---|---|
| Dasar | 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 |
|||||
Untuk memastikan traffic untuk 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 terbatas) |
private.googleapis.com (untuk jaringan dasar) atau restricted.googleapis.com (untuk jaringan terbatas) |
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 melakukan langkah-langkah tambahan untuk mendesain jalur akses yang diperlukan.
Untuk beban kerja yang memerlukan traffic keluar ke internet, sebaiknya Anda mengelola 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 yang tepercaya.
Untuk beban kerja yang memerlukan traffic masuk dari internet, sebaiknya Anda mendesain beban kerja dengan Cloud Load Balancing dan Google Cloud Armor untuk mendapatkan manfaat dari perlindungan DDoS dan WAF.
Sebaiknya Anda tidak 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 ini 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 lain. Dalam setiap metro, ada dua zona berbeda dalam fasilitas kolokasi.
- 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 terpasang ke topologi VPC Bersama.
- Setiap jaringan VPC Bersama memiliki empat Cloud Router, dua di setiap region, dengan mode pemilihan rute dinamis yang ditetapkan 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 yang lebih rendah dibandingkan dengan subnet lokal (subnet yang berada di region Cloud Router). Secara opsional, Anda dapat mengubah awalan 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 equal cost multi-path (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 on-premise Anda.
Beberapa komponen untuk konektivitas campuran dari lingkungan lokal Anda ke Google Cloud diaktifkan secara otomatis oleh blueprint, termasuk hal berikut:
- Cloud DNS dikonfigurasi dengan penerusan DNS di antara semua jaringan VPC Bersama ke satu hub, seperti yang dijelaskan dalam Penyiapan DNS. Kebijakan server Cloud DNS dikonfigurasi dengan alamat IP penerusan masuk.
- Cloud Router dikonfigurasi untuk mengekspor rute untuk semua subnet dan rute kustom untuk 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 ditujukan untuk Google Cloud ke alamat IP penerusan masuk yang telah dikonfigurasi oleh blueprint.
- Konfigurasikan server DNS, firewall, dan router lokal 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 informasi selengkapnya, lihat Akses Google Pribadi untuk host lokal.
Langkah selanjutnya
- Baca kontrol detektif (dokumen berikutnya dalam rangkaian ini).