Hub dan spoke atau mesh penuh: topologi VPN mana yang cocok untuk situs Anda

Dua kantor cabang berbicara satu sama lain sepanjang hari, dan terowongan di antara keduanya memutar melalui pusat data di wilayah lain. Setiap permintaan membayar biaya memutar itu dua kali, dan tidak ada yang menyadarinya sampai sinkronisasi berkas mulai terasa salah. Di sinilah pertanyaan topologi benar-benar dimulai: bukan pada diagram mana yang tampak lebih tahan gangguan, melainkan pada pola lalu lintas mana Anda membayar. Kedua desain berfungsi, dan keduanya gagal dengan cara berbeda pada biaya berbeda.

Hitung hubungan antar-peer sebelum hal lain

Dengan N situs, mesh penuh membutuhkan N kali N dikurangi satu, dibagi dua, terowongan; hub membutuhkan N. Pada lima situs itu sepuluh berbanding lima, yang masih terdengar terkelola. Pada lima belas itu 105 berbanding lima belas, dan selisihnya bukan lagi aritmetika melainkan staf.

Setiap hubungan itu membawa status yang harus Anda miliki. Dalam IPsec itu berarti asosiasi keamanan, identitas, kunci atau sertifikat, deteksi peer mati, dan setidaknya satu rute per prefiks jarak jauh. Dalam WireGuard itu berarti kunci publik dan AllowedIPs blok per peer, yang lebih murah per peer tetapi datang tanpa penemuan sama sekali: situs baru tetap merupakan perubahan konfigurasi pada setiap situs yang sudah ada.

Biarkan campuran lalu lintas yang memutuskan, bukan gambarnya

Jika lalu lintas cabang sebagian besar berupa permintaan ke ERP pusat atau klaster berkas, hub bukan kompromi, itulah bentuk yang benar: lalu lintas memang sudah ingin ke sana, dan satu titik kebijakan lebih mudah diaudit daripada mesh aturan berpasangan. Mesh pantas mendapatkan kerumitannya ketika cabang saling bertukar data — replikasi antara dua kantor, suara antar situs, berbagi CAD yang dibuka lusinan insinyur sepanjang hari.

Kasus yang canggung berada di tengah, dan itulah mayoritas. Ukur sebelum berdebat alih-alih menebak dari bagan organisasi.

Bacalah tabel sebagai penentu, bukan aturan. Tiga dari empat baris menunjuk satu arah biasanya menyelesaikan desain; perpecahan berarti hibrida, yang memang akhirnya dijalankan sebagian besar jaringan matang.

Hub harus diperintahkan untuk meneruskan

Dua terowongan spoke-ke-hub yang berfungsi tidak menciptakan akses spoke-ke-spoke. Hub memerlukan penerusan IP diaktifkan, rute ke setiap jaringan spoke, aturan firewall yang mengizinkan transit, dan jalur balik yang sudah dihitung; setiap spoke memerlukan rute untuk prefiks situs lain. Pada hub Linux itu adalah net.ipv4.ip_forward=1 ditambah FORWARD rantai yang tidak menjatuhkan pasangan secara diam-diam, dan pada IPsec berbasis kebijakan itu adalah pemilih lalu lintas yang mencantumkan subnet spoke jarak jauh di kedua ujung. Di strongSwan catatan penerusan mencakup sisi kernel dan firewall ketika itulah lapisan yang Anda lewatkan. Uji murah adalah mengirim lalu lintas dari satu spoke ke layanan di spoke lain sambil mengamati penghitung hub; aturan yang tidak pernah bertambah berarti urutannya salah, bukan rutenya.

Kebijakan pusat juga bagian yang berguna. Cabang dapat diizinkan mencapai layanan bersama tanpa saling mencapai, dan matriks akses itu layak dituliskan secara eksplisit. Rute yang hilang adalah pengganti buruk bagi aturan yang bisa dibaca seseorang.

Waspadai versi setengah jadi: spoke A merutekan ke spoke B melalui hub, hub merutekan kedua arah, dan firewall hub mengizinkan koneksi baru dari A tetapi tidak dari B. Arah pertama diuji dengan baik dan yang kedua menggantung, yang tampak seperti kesalahan perutean dan bukan.

Rancang kegagalannya, lalu jalur normalnya

Satu hub adalah ketergantungan bersama dan penyempitan transit, dan redundansi adalah tempat desain hub biasanya salah. Dua hub berarti setiap spoke memegang dua terowongan, dan jalur balik harus sesuai dengan jalur keluar; bila tidak, firewall stateful membuang balasan dan gejalanya adalah koneksi yang terbuka lalu mati. Penerapan lebih besar menyelesaikannya dengan protokol perutean di atas terowongan alih-alih prefiks statis, yang lebih banyak mesin tetapi menghapus tebakan. Apa pun yang Anda pilih, tuliskan jalur balik di samping jalur keluar, karena bagian balik itulah yang tidak diuji siapa pun.

Mesh menyebarkan risiko itu: tautan satu situs yang turun tidak mengisolasi yang lain. Mesh juga melipatgandakan tempat di mana pemilihan jalur dapat mengejutkan Anda, dan sesi aplikasi tetap tidak selamat melewati perubahan jalur tanpa bantuan.

Tidak ada dari kedua desain yang menjaga sesi TCP tetap hidup melewati failover dengan sendirinya. Jika aplikasi tidak dapat menyambung ulang, topologi bukan masalah Anda.

Pilih berdasarkan biaya perubahan, lalu verifikasi rutenya

Mulailah dari hub, karena itulah hal yang lebih murah untuk salah, dan tambahkan terowongan langsung untuk pasangan yang lalu lintasnya membenarkannya. Hibrida itu bukan kegagalan memutuskan; itulah desain yang dituju sebagian besar organisasi dalam setahun. Yang penting adalah setiap tautan langsung punya alasan yang dinyatakan dan seorang pemilik.

Lalu verifikasi kedua gambar, bukan satu. Untuk jalur normal, traceroute dari setiap situs ke setiap prefiks layanan dan pastikan hop-nya sesuai diagram. Untuk jalur kegagalan, matikan satu terowongan dan ulangi, karena rute yang hanya bekerja selama semuanya hidup belum dirancang, hanya dikonfigurasi.

Simpan kedua gambar bersama matriks akses, dan tinjau kembali ketika sebuah situs ditambahkan; biaya yang Anda kelola adalah biaya perubahan berikutnya, bukan keanggunan gambar saat ini.