Load Balancer Jaringan passthrough internal sebagai next hop

Load Balancer Jaringan passthrough internal adalah load balancer regional yang memungkinkan Anda menjalankan dan menskalakan layanan di balik alamat IP internal. Anda dapat menggunakan Load Balancer Jaringan passthrough internal sebagai next hop yang meneruskan paket di sepanjang jalur ke tujuan akhirnya. Untuk melakukannya, Anda menetapkan load balancer sebagai next hop dalam rute statis.

Sebelum meninjau informasi di halaman ini, Anda harus sudah memahami konsep dari berikut ini:

• Ringkasan rute
• Ringkasan Load Balancer Jaringan passthrough internal

Next hop Load Balancer Jaringan passthrough internal berguna dalam kasus berikut:

• Untuk melakukan load balancing traffic di beberapa VM yang berfungsi sebagai VM gateway atau router.

• Untuk menggunakan peralatan virtual gateway sebagai next hop untuk rute default. Dengan konfigurasi ini, instance mesin virtual (VM) di jaringan Virtual Private Cloud (VPC) Anda mengirim traffic ke internet melalui serangkaian VM gateway virtual yang di-load balance.

• Untuk mengirim traffic melalui beberapa load balancer dalam dua arah atau lebih dengan menggunakan set VM gateway atau router multi-NIC yang sama sebagai backend. Untuk melakukannya, Anda membuat load balancer dan menggunakannya sebagai next hop untuk rute statis di setiap jaringan VPC. Setiap Load Balancer Jaringan passthrough internal beroperasi dalam satu jaringan VPC, mendistribusikan traffic ke antarmuka jaringan VM backend dalam jaringan tersebut.

Arsitektur

Dalam diagram berikut, grup instance VM router berfungsi sebagai backend untuk dua load balancer yang berbeda. Load Balancer Jaringan passthrough internal pertama mengirim paket ke nic0 VM backend, dan Load Balancer Jaringan passthrough internal kedua mengirim paket ke nic1 di backend yang sama.

Load balancing ke beberapa NIC (klik untuk memperbesar).

Manfaat menggunakan Load Balancer Jaringan passthrough internal sebagai next hop

Jika load balancer adalah next hop untuk rute statis, tidak ada konfigurasi khusus yang diperlukan dalam sistem operasi tamu VM klien di jaringan VPC tempat rute ditentukan. VM klien mengirim paket ke backend load balancer melalui perutean jaringan VPC, dengan cara bump-in-the-wire.

Menggunakan Load Balancer Jaringan passthrough internal sebagai next hop untuk rute statis memberikan manfaat yang sama dengan Load Balancer Jaringan passthrough internal mandiri. Health check load balancer memastikan bahwa koneksi baru dirutekan ke VM backend yang responsif. Dengan menggunakan grup instance terkelola sebagai backend, Anda dapat mengonfigurasi penskalaan otomatis untuk memperbesar atau memperkecil set VM berdasarkan permintaan layanan.

Spesifikasi

Berikut adalah spesifikasi untuk menggunakan Load Balancer Jaringan passthrough internal sebagai next hop.

Rute

Anda dapat membuat rute statis untuk meneruskan traffic TCP, UDP, dan protokol lainnya ke Load Balancer Jaringan passthrough internal yang merupakan next hop untuk rute statis. Rute dapat berupa awalan CIDR eksternal (dapat dirutekan secara publik) atau awalan CIDR internal, jika awalan tidak berkonflik dengan rute subnet. Misalnya, Anda dapat mengganti rute default (0.0.0.0/0) dengan rute yang mengarahkan traffic ke VM backend pihak ketiga untuk pemrosesan paket.

Perhatian: Saat mengirim traffic ke Google API dan layanan Google, jangan merutekan traffic melalui VM next hop atau melalui Load Balancer Jaringan passthrough internal next hop. Sebagai gantinya, arahkan traffic tersebut melalui gateway internet default next hop. Hal ini mencakup traffic ke Google API dan layanan Google yang dikirim melalui Akses Google Pribadi.

Opsi untuk menentukan hop berikutnya

Anda dapat menentukan next hop Load Balancer Jaringan passthrough internal dengan salah satu dari dua cara berikut:

• Dengan menggunakan nama dan region aturan penerusan
• Dengan menggunakan alamat IP aturan penerusan

Untuk mengetahui detail tentang project dan jaringan VPC tempat next hop Load Balancer Jaringan passthrough internal dapat berada, lihat Next hop dan fitur.

Anda dapat menukar rute statis dengan next hop Load Balancer Jaringan passthrough internal menggunakan Peering Jaringan VPC. Untuk mengetahui detailnya, lihat Opsi untuk bertukar rute statis.

Catatan: Load balancer yang aturan penerusannya menggunakan protokol L3_DEFAULT tidak dapat menjadi next hop untuk rute statis. Jika rute statis ini dibuat, traffic akan dihentikan tanpa pemberitahuan.

Rentang tujuan

Tujuan rute statis tidak boleh sama dengan atau lebih spesifik daripada rute subnet. Perhatikan bahwa lebih spesifik berarti masker subnet lebih panjang. Aturan ini berlaku untuk semua rute statis, termasuk saat next hop adalah Load Balancer Jaringan passthrough internal. Misalnya, anggaplah rute subnet Anda adalah 10.140.0.0/20. Tujuan rute statis tidak boleh sama (10.140.0.0/20), dan tidak boleh lebih spesifik, seperti pada 10.140.0.0/22.

Jaringan dan region VPC yang sama

Rute statis yang menggunakan Load Balancer Jaringan passthrough internal sebagai next hop dibatasi untuk berikut ini:

• Satu jaringan VPC. Load balancer dan rute statis harus berada di jaringan VPC yang sama.

• Satu region atau semua region. Kecuali jika Anda mengonfigurasi akses global, rute statis hanya tersedia untuk resource di region yang sama dengan load balancer. Pembatasan regional ini diberlakukan meskipun rute itu sendiri merupakan bagian dari tabel perutean untuk seluruh jaringan VPC. Jika Anda mengaktifkan akses global, rute statis akan tersedia untuk resource di region mana pun.

Mengiklankan rute statis

Untuk mengiklankan awalan (tujuan) rute statis, Anda dapat menggunakan mode pemberitahuan kustom Cloud Router. Cakupan pengumuman rute bergantung pada setelan akses global load balancer, sebagai berikut:

• Jika akses global dinonaktifkan, Load Balancer Jaringan passthrough internal hanya tersedia untuk VM, tunnel Cloud VPN, dan lampiran Cloud Interconnect (VLAN) yang berada di region yang sama dengan load balancer. Oleh karena itu, pemberitahuan rute kustom untuk awalan rute statis hanya masuk akal jika Cloud Router dan load balancer berada di region yang sama.

• Jika akses global diaktifkan, Load Balancer Jaringan passthrough internal tersedia untuk VM, tunnel Cloud VPN, dan lampiran Cloud Interconnect (VLAN) yang berada di region mana pun. Dengan perutean dinamis global, sistem lokal dapat menggunakan rute statis dari region yang terhubung.

Tabel berikut merangkum aksesibilitas load balancer.

Akses global	Mode perutean dinamis jaringan VPC	Akses load balancer
Nonaktif	Regional	Dapat diakses oleh router di region yang sama
Nonaktif	Global	Dapat diakses oleh router di region yang sama
Aktif	Regional	Dapat diakses oleh semua router di region mana pun
Aktif	Global	Dapat diakses oleh semua router di region mana pun

Untuk mengetahui informasi selengkapnya, lihat Load Balancer Jaringan passthrough internal dan jaringan yang terhubung.

Urutan operasi

Anda harus membuat Load Balancer Jaringan passthrough internal sebelum dapat membuat rute statis yang menggunakannya sebagai next hop. Load balancer harus ada sebelum Anda dapat membuat rute. Jika Anda mencoba membuat rute yang merujuk ke load balancer yang tidak ada, Google Cloud akan menampilkan error.

Anda menentukan next hop Load Balancer Jaringan passthrough internal dengan menggunakan nama aturan penerusan dan region load balancer, atau dengan menggunakan alamat IP internal yang terkait dengan aturan penerusan.

Setelah membuat rute dengan next hop yang merujuk ke Load Balancer Jaringan passthrough internal, Anda tidak dapat menghapus load balancer kecuali jika Anda menghapus rute terlebih dahulu. Secara khusus, Anda tidak dapat menghapus aturan penerusan internal hingga tidak ada rute statis yang menggunakan load balancer tersebut sebagai next hop.

Pemrosesan traffic TCP, UDP, dan protokol lainnya

Penting: Informasi di bagian ini hanya berlaku untuk rute kustom yang dibuat sebelum 15 Mei 2021.

Jika rute next hop Load Balancer Jaringan passthrough internal dibuat sebelum 15 Mei 2021, load balancer hanya meneruskan traffic TCP dan UDP di semua port ke VM backend, terlepas dari konfigurasi aturan penerusan atau layanan backend. Semua traffic lainnya, seperti ping ICMP, akan ditangani oleh rute paling spesifik berikutnya di jaringan VPC Anda.

Jika rute yang dibuat sebelum 15 Mei 2021 masih beroperasi pada 16 Agustus 2021, rute tersebut akan otomatis dimigrasikan untuk meneruskan semua traffic protokol mulai 16 Agustus 2021.

Saat di-deploy sebagai next hop,Load Balancer Jaringan passthrough internal Google Cloud meneruskan semua traffic di semua port ke VM backend, terlepas dari hal berikut:

• Konfigurasi protokol dan port aturan penerusan
• Konfigurasi protokol layanan backend

Load Balancer Jaringan passthrough internal, yang merupakan next hop rute, mendukung penerusan semua traffic untuk protokol yang didukung oleh jaringan VPC (seperti TCP, UDP, dan ICMP) dengan lancar. Google Cloud

Pertimbangan lainnya

• Aturan penerusan yang didukung. Google Cloud hanya mendukung aturan penerusan Load Balancer Jaringan passthrough internal next hop. Google Cloud Tidak mendukung aturan penerusan next hop yang digunakan oleh load balancer lain, penerusan protokol, atau sebagai endpoint Private Service Connect.

• Metode spesifikasi serta jaringan dan project aturan penerusan. Anda dapat menentukan aturan penerusan next hop menggunakan salah satu dari tiga metode berikut. Metode spesifikasi yang Anda gunakan menentukan apakah jaringan aturan penerusan harus cocok dengan jaringan rute dan dalam project apa aturan penerusan tersebut dapat ditemukan.

  Pilih salah satu metode berikut dan pastikan versi IP aturan penerusan Anda cocok dengan versi IP rute statis yang Anda buat:

  • Berdasarkan nama aturan penerusan (--next-hop-ilb) dan region (--next-hop-ilb-region): saat Anda menentukan aturan penerusan next hop berdasarkan nama dan region, jaringan aturan penerusan harus cocok dengan jaringan VPC rute. Aturan penerusan harus berada dalam project yang sama yang berisi jaringan aturan penerusan (project mandiri atau project host VPC Bersama).

  • Berdasarkan link resource aturan penerusan: link resource aturan penerusan menggunakan format /projects/PROJECT_ID/regions/REGION/forwardingRules/FORWARDING_RULE_NAME, dengan PROJECT_ID adalah project ID project yang berisi aturan penerusan, REGION adalah region aturan penerusan, dan FORWARDING_RULE_NAME adalah nama aturan penerusan. Saat Anda menentukan aturan penerusan next hop berdasarkan link resource-nya, jaringan aturan penerusan harus cocok dengan jaringan VPC rute. Aturan penerusan dapat berada di salah satu project yang berisi jaringan aturan penerusan (project mandiri atau project host VPC Bersama) atau di project layanan VPC Bersama.

  • Dengan alamat IP aturan penerusan: saat Anda menentukan aturan penerusan next hop berdasarkan alamat IPv4 atau IPv6-nya, jaringan aturan penerusan dapat berupa salah satu dari jaringan VPC rute atau jaringan VPC yang terhubung ke jaringan VPC rute menggunakan Peering Jaringan VPC atau NCC. NCC mendukung Load Balancer Jaringan passthrough internal next hop di spoke VPC yang tunduk pada persyaratan NCC untuk konektivitas. Aturan penerusan dapat berada di salah satu project yang berisi jaringan aturan penerusan (project mandiri atau project host VPC Bersama) atau di project layanan VPC Bersama.

• Pengaruh akses global. Rute statis kustom yang menggunakan next hop Load Balancer Jaringan passthrough internal diprogram di semua region. Kemampuan next hop untuk dapat digunakan bergantung pada setelan akses global load balancer. Dengan mengaktifkan akses global, next hop load balancer dapat diakses di semua region jaringan VPC. Jika akses global dinonaktifkan, next hop load balancer hanya dapat diakses di region yang sama dengan load balancer. Dengan menonaktifkan akses global, paket yang dikirim dari region lain ke rute menggunakan next hop Load Balancer Jaringan passthrough internal akan dihentikan.

• Saat semua backend tidak responsif. Jika semua backend Load Balancer Jaringan passthrough internal gagal dalam health check, rute yang menggunakan next hop load balancer tersebut masih akan berpengaruh. Paket yang diproses oleh rute dikirim ke salah satu backend load balancer next hop sesuai dengan distribusi traffic.

• Aturan penerusan yang menggunakan alamat IP internal yang umum (--purpose=SHARED_LOADBALANCER_VIP) tidak didukung. Load Balancer Jaringan passthrough internal next hop dan aturan penerusan Load Balancer Jaringan passthrough internal yang menggunakan alamat IP umum untuk mereferensikan layanan backend yang berbeda (Load Balancer Jaringan passthrough internal yang berbeda) adalah fitur yang sama-sama eksklusif. Load Balancer Jaringan passthrough internal next hop harus menggunakan alamat IP yang unik untuk aturan penerusan load balancer, sehingga hanya satu layanan backend (satu load balancer) yang direferensikan dengan jelas. Traffic yang dikirim ke Load Balancer Jaringan passthrough internal next hop yang dikonfigurasi dengan alamat IP bersama akan dihentikan tanpa pemberitahuan.

• Beberapa rute dengan tujuan dan prioritas yang sama, tetapi Load Balancer Jaringan passthrough internal next hop yang berbeda. Google Cloud Tidak pernah mendistribusikan traffic di antara dua atau lebih Load Balancer Jaringan passthrough internal next hop menggunakan ECMP. Sebagai gantinya, Google Cloud hanya memilih satu Load Balancer Jaringan passthrough internal next hop menggunakan algoritma internal yang deterministik. Untuk menghindari ambiguitas ini, Anda dapat menggunakan tag jaringan unik untuk setiap rute.

  

  Google Cloud memilih satu next hop saat rute statis dengan berbagai next hop Load Balancer Jaringan passthrough internal yang berbeda memiliki prioritas dan tujuan yang sama.

• Beberapa rute dengan tujuan, prioritas, dan Load Balancer Jaringan passthrough internal next hop yang sama. Tanpa tag jaringan, Google Cloud Anda tidak dapat membuat beberapa rute statis yang memiliki kombinasi tujuan, prioritas, dan next hop Load Balancer Jaringan passthrough internal yang sama. Dengan tag jaringan, Anda dapat membuat beberapa rute statis yang memiliki kombinasi tujuan, prioritas, dan next hop Load Balancer Jaringan passthrough internal yang sama.

Persyaratan

Persyaratan berikut berlaku saat Anda perlu mengirim traffic melalui dua Load Balancer Jaringan passthrough internal yang menggunakan VM backend yang sama. Dalam situasi ini, VM backend memiliki dua antarmuka jaringan dengan load balancing, satu antarmuka digunakan oleh setiap load balancer. Setiap antarmuka berada di jaringan VPC yang berbeda, dan setiap jaringan VPC memiliki rute statis yang menggunakan salah satu load balancer sebagai next hop. Konfigurasi ini umum jika VM backend melakukan fungsi perutean, firewall, atau proxy.

Persyaratan load balancer

1. Kedua load balancer harus memiliki kumpulan backend yang memenuhi syarat yang sama. Perhatikan bahwa Anda akan menemukan kumpulan backend yang memenuhi syarat setelah langkah 2.1 dan 2.2 dalam proses pelacakan koneksi dan pemilihan backend.

   Hal ini memiliki konsekuensi berikut:

   • Kedua load balancer harus menonaktifkan fitur failover atau mengaktifkan fitur failover. Jika diaktifkan, kedua load balancer harus memiliki kebijakan failover yang identik.

   • Backend harus lulus atau gagal health check secara bersamaan untuk kedua load balancer.

   • Kedua load balancer harus memiliki konfigurasi afinitas zonal yang sama.

2. Kedua load balancer harus memilih backend yang memenuhi syarat dengan cara yang sama. Artinya, kedua load balancer harus menggunakan setelan afinitas sesi yang sama karena afinitas sesi menentukan karakteristik paket mana yang di-hash untuk memilih backend yang memenuhi syarat.

   Jika afinitas sesi adalah CLIENT_IP, CLIENT_IP_PROTO, CLIENT_IP_PORT_PROTO, load balancer menghitung hash paket yang identik meskipun hal berikut terjadi:

   • alamat IP sumber ditukar dengan alamat IP tujuan
   • port sumber ditukar dengan port tujuan

3. Kedua load balancer harus melacak koneksi dengan cara yang sama. Hal ini memiliki konsekuensi berikut:

   • Kedua load balancer harus menggunakan mode pelacakan koneksi yang sama (PER_CONNECTION atau PER_SESSION). Hal ini menghindari situasi di mana satu load balancer dapat mengelompokkan beberapa koneksi ke dalam entri tabel pelacakan koneksi yang sama dibandingkan dengan load balancer lainnya.

   • Kedua load balancer harus menggunakan setelan waktu tunggu tidak ada aktivitas dan persistensi koneksi yang sama pada backend yang tidak sehat.

Persyaratan klien dan server

Jika Anda mengonfigurasi Load Balancer Jaringan passthrough internal next hop dengan afinitas zona, pertimbangkan dengan cermat bagaimana afinitas zona memengaruhi alur klien ke server dan server ke klien untuk koneksi yang sama. Jika Anda memerlukan paket untuk diproses oleh VM backend yang sama di kedua arah untuk koneksi yang sama, opsi penempatan berikut didukung:

• VM klien, server, dan backend semuanya berada di zona yang sama: Dengan penempatan ini, setiap backend yang memenuhi syarat dan telah dimodifikasi dari load balancer dapat identik, tunduk pada persyaratan load balancer, karena kecocokan zonal terjadi di kedua arah. Alur paket klien ke server untuk koneksi dapat menggunakan backend yang sama dengan alur server ke klien yang sesuai.

• VM klien dan server di zona (atau zona) yang tidak memiliki VM backend: Dengan penempatan ini, kecocokan zona tidak akan pernah mungkin terjadi saat paket dikirim antara klien dan server, sehingga afinitas zona tidak memengaruhi backend yang memenuhi syarat asli.

Persyaratan backend

• Anda harus mengonfigurasi semua VM backend Load Balancer Jaringan passthrough internal agar mengizinkan penerusan IP (--can-ip-forward = True). Untuk mengetahui informasi selengkapnya, lihat Pertimbangan umum untuk next hop Load Balancer Jaringan passthrough internal dan instance.

• Anda tidak dapat menggunakan Load Balancer Jaringan passthrough internal yang backend-nya adalah node Google Kubernetes Engine (GKE) sebagai next hop untuk rute statis. Software di node hanya dapat merutekan traffic ke Pod jika tujuannya cocok dengan alamat IP yang dikelola oleh cluster, bukan tujuan arbitrer.

Kasus penggunaan

Anda dapat menggunakan Load Balancer Jaringan passthrough internal sebagai next hop di beberapa deployment dan topologi.

Untuk setiap contoh, perhatikan panduan berikut:

• Dalam contoh ini, antarmuka jaringan setiap VM berada di jaringan VPC yang terpisah.

• Anda tidak dapat menggunakan VM backend atau load balancer untuk merutekan traffic antar-subnet dalam jaringan VPC yang sama karena rute subnet tidak dapat diganti.

• Load Balancer Jaringan passthrough internal adalah load balancer passthrough yang ditentukan software. Paket dikirimkan ke VM backend tanpa mengubah informasi sumber atau tujuan (alamat atau alamat dan port).

  Perutean, pemfilteran paket, proxy, dan terjemahan alamat adalah tanggung jawab VM perangkat virtual yang berfungsi sebagai backend untuk Load Balancer Jaringan passthrough internal.

Menggunakan Load Balancer Jaringan passthrough internal sebagai next hop ke gateway NAT

Kasus penggunaan ini menyeimbangkan beban traffic dari VM internal ke beberapa instance gateway NAT yang merutekan traffic ke internet.

Kasus penggunaan NAT (klik untuk memperbesar).

Hub dan spoke: Menukar rute next hop menggunakan Peering Jaringan VPC

Selain bertukar rute subnet, Anda dapat mengonfigurasi Peering Jaringan VPC untuk mengekspor dan mengimpor rute statis dan dinamis kustom. Rute statis yang memiliki next hop gateway internet default akan dikecualikan. Rute statis kustom yang menggunakan Load Balancer Jaringan passthrough internal next hop disertakan.

Anda dapat mengonfigurasi topologi hub dan spoke dengan peralatan virtual firewall next-hop yang berada di jaringan VPC hub dengan melakukan hal berikut:

• Di jaringan VPC hub, buat Load Balancer Jaringan passthrough internal dengan peralatan virtual firewall sebagai backend.
• Di jaringan VPC hub, buat rute statis, dan tetapkan next hop ke Load Balancer Jaringan passthrough internal.
• Hubungkan jaringan VPC hub ke setiap jaringan VPC spoke menggunakan Peering Jaringan VPC.
• Untuk setiap peering, konfigurasi jaringan hub untuk mengekspor rute kustomnya, dan konfigurasi jaringan spoke yang sesuai untuk mengimpor rute kustom. Rute dengan next hop load balancer adalah salah satu rute yang diekspor oleh jaringan hub.

Tunduk pada urutan perutean, load balancer peralatan firewall next hop di jaringan VPC hub tersedia di jaringan spoke:

• ke klien di region yang sama dengan load balancer, jika akses global dinonaktifkan
• ke klien di semua region, jika akses global diaktifkan, sesuai dengan urutan perutean.

Hub dan spoke (klik untuk memperbesar).

Load balancing ke beberapa NIC

Dalam kasus penggunaan berikut, VM backend adalah instance peralatan virtual (misalnya, VM inspeksi paket, perutean, atau gateway) dengan NIC di beberapa jaringan VPC. Instance perangkat virtual ini dapat berupa solusi komersial dari pihak ketiga atau solusi yang Anda buat sendiri. Virtual appliance adalah VM Compute Engine dengan beberapa NIC.

Contoh ini menunjukkan satu set peralatan virtual backend dalam grup instance VM terkelola.

Di jaringan VPC yang disebut testing, Load Balancer Jaringan passthrough internal memiliki aturan penerusan yang disebut fr-ilb1. Dalam contoh ini, load balancer mendistribusikan traffic ke antarmuka nic0.

Di jaringan VPC yang disebut production, Load Balancer Jaringan passthrough internal yang berbeda memiliki aturan penerusan yang disebut fr-ilb2. Load balancer ini mendistribusikan traffic ke antarmuka yang berbeda, nic1 dalam contoh ini.

Traffic dengan load balancing multi-NIC (klik untuk memperbesar).

Untuk penyiapan konfigurasi yang mendetail, lihat Load balancing ke beberapa NIC backend.

Hashing simetris

Contoh sebelumnya tidak menggunakan penafsiran alamat jaringan sumber (SNAT). SNAT tidak diperlukan karena Google Cloud menggunakan hashing simetris. Artinya, saat paket termasuk dalam alur yang sama, Google Cloud menghitung hash yang sama. Dengan kata lain, hash tidak berubah saat alamat IP:port sumber ditukar dengan alamat IP:port tujuan.

Catatan:

• Hashing simetris diaktifkan secara otomatis saat Anda membuat aturan penerusan Network Load Balancer passthrough internal pada atau setelah 22 Juni 2021.

• Untuk mengaktifkan hashing simetris di Load Balancer Jaringan passthrough internal yang ada, Anda harus membuat ulang aturan penerusan dan rute next hop, seperti yang dijelaskan dalam Mengaktifkan hashing simetris.

• Hashing simetris hanya didukung dengan Load Balancer Jaringan passthrough internal.

• Hashing simetris didukung dengan jenis afinitas sesi berikut untuk protokol TCP dan UDP:

  • IP Klien (CLIENT_IP)
  • IP dan protokol klien (CLIENT_IP_PROTO)
  • IP, protokol, dan port klien (CLIENT_IP_PORT_PROTO)

  Untuk mengetahui informasi selengkapnya tentang setelan ini, lihat Opsi afinitas sesi.

• Anda dapat menggunakan SNAT secara opsional jika kasus penggunaan Anda memerlukannya karena alasan tertentu.

Langkah berikutnya

• Untuk mengonfigurasi Load Balancer Jaringan passthrough internal sebagai next hop, lihat Menyiapkan Load Balancer Jaringan passthrough internal untuk appliance pihak ketiga atau Men-deploy jaringan hub-dan-spoke dengan menggunakan load balancer sebagai next hop.
• Untuk mengonfigurasi dan menguji Network Load Balancer passthrough internal, lihat Menyiapkan Network Load Balancer passthrough internal dengan backend grup instance VM.
• Untuk memecahkan masalah next hop dengan Load Balancer Jaringan passthrough internal, lihat Memecahkan masalah Load Balancer Jaringan passthrough internal.