Satu beban kerja di satu Azure VM harus mencapai jaringan privat melalui tunnel. Pertanyaan yang menentukan desain bukanlah produk VPN mana yang lebih baik, melainkan apakah mesin lain akan pernah membutuhkan jalur itu. Jawab itu lebih dulu dan sisa arsitekturnya biasanya memilih sendiri. Kalau salah, Anda mewarisi VM yang diam-diam menjadi router yang tidak didokumentasikan siapa pun.

Dua pekerjaan yang tampak sama

VM bisa menjadi titik akhir atau titik transit, dan bedanya bukan perangkat lunak yang Anda pasang melainkan siapa yang memakai tunnel. Sebagai titik akhir, tamu menjalankan klien untuk prosesnya sendiri. Sebagai titik transit, ia meneruskan paket beban kerja lain, yang menjadikannya bagian dari topologi jaringan Anda.

TugasApa yang dilakukan VMSiapa pemilik routing
Titik akhir beban kerjaMenjalankan klien yang didukung untuk prosesnya sendiriRute tamu memilih tujuan yang disetujui
Perangkat transitMeneruskan beban kerja lain ke koneksi situsTabel rute subnet, penerusan NIC, kebijakan tamu, dan jalur balik

Sebagian besar permintaan satu VM adalah pekerjaan pertama yang memakai bahasa pekerjaan kedua. Seseorang berkata “VM itu VPN kami” padahal maksudnya satu aplikasi di atasnya perlu mencapai basis data di sisi lain.

Kondisi satu: apakah ada hal lain yang membutuhkan sisi jauh?

Kalau jawabannya tidak, pasang klien di tamu dan berhenti mendesain. Tidak ada yang dalam pilihan itu menuntut gateway terkelola, dan tidak ada yang menjadikan VM gateway bagi tetangganya. Anda menambahkan rute di dalam satu sistem operasi.

Kalau jawabannya ya, atau kemungkinan besar ya dalam setahun, perlakukan itu sebagai desain jaringan sekarang. VM lain mencapai VM transit hanya ketika tabel rute subnet mengirimnya ke sana dan NIC menerima lalu lintas yang diteruskan, jadi pekerjaannya adalah tabel rute dan izin penerusan, bukan pemasangan klien lagi.

Kondisi dua: bisakah Anda mempertahankan jalur administrasi?

Klien VPN yang memasang rute lebar bisa menangkap jalur yang Anda pakai untuk mengelola VM. Kalau daftar tujuan tunnel tumpang tindih dengan jaringan manajemen, sesi SSH atau RDP Anda putus pada saat klien terhubung, dan perbaikannya harus lewat konsol serial atau pembangunan ulang.

Periksa sebelum dan sesudah. Di Linux, ip route get <management-ip> menunjukkan antarmuka dan sumber mana yang akan dipakai kernel saat ini; bandingkan dengan jawabannya saat tunnel aktif. Tunnel terpisah dengan daftar tujuan eksplisit lebih mudah dipertahankan daripada rute default, dan biasanya itulah yang benar-benar dibutuhkan beban kerja.

Kondisi tiga: siapa yang menambal pada tengah malam?

Klien tamu berarti sistem operasi Anda, versi klien Anda, dan sertifikat Anda. Itu wajar bila Anda sudah menjalankan VM dan siklus tambalnya. Itu pertukaran buruk bila VM hanya ada untuk menahan tunnel. Hitung jam penambalan sebelum menyebut klien tamu lebih murah. Peningkatan klien yang butuh reboot adalah gangguan yang Anda jadwalkan untuk mesin yang ada demi menjaga tunnel tetap hidup.

Gateway terkelola memindahkan pemeliharaan itu ke platform. Anda tetap memiliki identitas, otorisasi, dan jalur jaringan di belakangnya, tetapi Anda tidak me-reboot mesin untuk menerapkan pembaruan klien.

Apa yang tidak dilakukan gateway terkelola

Azure VPN Gateway adalah layanan konektivitas VNet dengan pengaturan site-to-site dan point-to-site-nya sendiri. Ia bukan aturan yang melarang perangkat lunak VPN di tamu, dan bukan pengganti langsung bagi klien yang dibutuhkan satu aplikasi.

Yang diberikannya adalah koneksi pada lapisan jaringan, yang dapat dicapai banyak beban kerja melalui routing. Yang tidak diberikannya adalah tunnel yang hanya dipakai satu proses di satu VM, dan dibatasi pada identitas proses itu. Batasan itu bukan kekurangan yang perlu dimintakan maaf; justru itulah inti desain klien tamu. Satu aplikasi, satu rute, satu set kredensial, tanpa efek pada VM lain di subnet.

Jadi perbandingannya bukan terkelola lawan perangkat lunak. Ini konektivitas berlingkup jaringan lawan konektivitas berlingkup proses, dan yang kedua sah bila hanya satu proses yang membutuhkannya.

Rencanakan jalur pertumbuhan sebelum Anda membutuhkannya

Jika kebutuhan tumbuh dari satu VM ke satu subnet, bangun ulang desainnya alih-alih melebarkan prefiks yang diizinkan klien. Memakai ulang sesi yang nyaman sebagai router tanpa dokumentasi mengikat setiap konsumen pada masa hidup VM itu, kredensialnya, dan jendela tambalnya.

Titik awal yang benar, begitu koneksinya berlingkup jaringan bukan berlingkup beban kerja, adalah ikhtisar Azure VPN Gateway.

Sebelum memilih, tulis tiga baris: apa yang membutuhkan sisi jauh, siapa yang mengelola VM, dan siapa yang menambal tunnel. Jika ketiga jawabannya menunjuk ke satu beban kerja, klien tamu adalah desain yang jujur. Jika salah satunya menunjuk ke subnet, rancang lapisan jaringan sekarang.

Artikel terkait