trueNetLab logo
ID
Menghubungkan lokasi: VPN, Tailscale, NetBird atau Cloudflare Mesh?

Menghubungkan lokasi: VPN, Tailscale, NetBird atau Cloudflare Mesh?

Saya banyak bekerja dengan konektivitas jaringan perusahaan. Pertanyaan yang sama sering muncul: apa solusi terbaik untuk menghubungkan lokasi kami? Perlukah alamat IP publik? Seberapa aman? Apakah masih cocok saat ada cabang baru, koneksi internet berbeda atau tambahan karyawan?

Jawaban saya bergantung pada kebutuhan nyata perusahaan. Dua lokasi tetap dengan firewall yang sudah tersedia berbeda dari beberapa cabang kecil dengan koneksi berubah-ubah. Ada pula pertanyaan di luar tunnel: siapa yang mengoperasikannya, di mana akses dikendalikan dan ketergantungan apa yang siap dipelihara perusahaan.

Karena itu saya ingin memahami arsitekturnya sebelum memilih produk. VPN site-to-site tradisional bisa cocok. Tailscale atau NetBird dapat mempermudah pengelolaan dan pembentukan koneksi. Cloudflare Mesh memindahkan jalur data ke jaringan penyedia. Perbedaan ini menentukan kapan masing-masing pendekatan masuk akal bagi saya.

Fokusnya adalah menghubungkan jaringan lokasi secara utuh. Akses karyawan perorangan dari rumah dibahas terpisah sebagai penggunaan akses jarak jauh tambahan.

Contoh: Tiga jaringan lokasi yang terhubung

Kantor pusat memakai 10.1.0.0/24, cabang 10.2.0.0/24 dan lab rumahan 10.3.0.0/24. Setiap lokasi memiliki gateway untuk menjangkau jaringan lain. Printer dan NAS di belakangnya tidak memerlukan klien VPN sendiri. Semua model memiliki tujuan sama: konektivitas terkendali antara ketiga jaringan.

Hasilnya adalah jaringan terarah Layer 3. Lokasi tidak otomatis berbagi domain broadcast dan tidak semua protokol penemuan lokal bekerja lintas lokasi. DNS harus menyelesaikan nama internal dengan benar, dan router lokal memerlukan rute ke jaringan jauh.

Pertama saya ingin mengetahui jaringan mana memerlukan layanan apa. Cabang mungkin membutuhkan server berkas tanpa akses administrasi lab. Server pencadangan membutuhkan tujuan cadangannya, bukan seluruh perangkat di lokasi lain. Semua opsi tetap membutuhkan keputusan tersebut.

Site-to-site menjelaskan koneksi, bukan topologi

Site-to-site berarti jaringan ke jaringan. Semua trafik tidak harus melalui firewall pusat. Hub-and-spoke melalui kantor pusat merupakan topologi umum; tunnel langsung antarpasangan lokasi juga menyediakan konektivitas site-to-site. Gateway Tailscale, NetBird atau Cloudflare Mesh bisa menjalankan peran yang sama.

Tailscale dan NetBird mengutamakan jalur data langsung meskipun pendaftaran dan koordinasi dikelola terpusat. Jaringan Cloudflare tersebar secara geografis, tetapi trafik antarlokasi tetap melewati Cloudflare. Ini bukan koneksi peer-to-peer langsung. Jaringan penyedia menggantikan firewall pusat sebagai titik transit.

IP publik dan kebutuhan yang berubah

Pertanyaan IP publik biasanya muncul lebih awal. Saya membedakan keterjangkauan dari luar dan kestabilan alamat. IP publik tetap mempermudah perencanaan endpoint VPN yang dapat dijangkau. Namun, tidak setiap lokasi membutuhkannya. Cabang bisa membuka tunnel keluar ke gateway pusat yang terjangkau; bergantung desainnya, DNS dinamis membantu menangani perubahan alamat.

Situasinya lebih sulit jika kedua ujung berada di balik carrier-grade NAT ketat tanpa endpoint yang langsung terjangkau. Khususnya untuk internet seluler, periksa alamat dan koneksi masuk yang benar-benar disediakan operator. Tailscale dan NetBird mencoba koneksi langsung menembus NAT dan memakai relay bila perlu. Cloudflare Mesh membentuk koneksi keluar ke jaringan penyedia.

Saya juga ingin perubahan berikutnya tetap mudah ditangani. Lokasi tambahan, pergantian penyedia atau koneksi tanpa akses masuk bisa mengubah konfigurasi kecil menjadi pekerjaan berbeda. Solusi yang bekerja tidak perlu diganti terlebih dahulu, tetapi kemungkinan ini perlu dipikirkan sebelum menetapkan topologi.

VPN site-to-site tradisional: Gateway menangani koneksi

Dua firewall atau router membentuk tunnel terenkripsi, biasanya memakai IPsec atau WireGuard yang dikonfigurasi manual. Routing lokal mengirim trafik jaringan jauh ke tunnel. Gateway di sisi lain mendekripsi paket lalu meneruskannya ke jaringan tujuan.

Tiga lokasi dengan gateway VPN pusat: lokasi B dan C berkomunikasi melalui A.

Pada tiga lokasi, pusat bisa menjadi hub. Cabang dan lab terhubung ke sana. Struktur lebih sederhana, tetapi pertukaran di antara keduanya harus melalui pusat. Full mesh menghubungkan setiap pasangan secara langsung. Untuk n lokasi diperlukan n × (n − 1) / 2 koneksi: tiga untuk tiga lokasi, sudah 45 untuk sepuluh. Controller dan metode dinamis dapat mengurangi pekerjaan; VPN tradisional tidak terbatas pada jaringan hub manual.

Kelebihan: cocok dengan firewall yang tersedia dan batas lokasi yang jelas. Endpoint tunnel berada dalam kendali sendiri. Tidak ada penyedia mesh tambahan di jalur data; aturan, routing dan log dapat mengikuti pengelolaan yang ada.

Kekurangan: pekerjaan routing, kunci dan operasi bertambah bersama jumlah lokasi. NAT, alamat berubah dan vendor berbeda menyulitkan diagnosis. Pengguna bergerak sering membutuhkan pengaturan akses jarak jauh tersendiri.

IP publik tetap di setiap lokasi bukan persyaratan mutlak. Dalam banyak konfigurasi, hub yang terjangkau dan tunnel keluar dari cabang sudah cukup. DNS dinamis serta traversal NAT juga membantu. Namun, jika kedua ujung memakai CGNAT ketat, koneksi langsung lebih sulit tanpa endpoint terjangkau atau perantara.

Untuk dua lokasi stabil dengan firewall yang sesuai, ini tetap pilihan masuk akal. VPN yang berfungsi tidak perlu diganti hanya karena produk lain menampilkan lebih sedikit kolom konfigurasi.

Tailscale: Koneksi langsung dengan koordinasi terpusat

Tailscale menambahkan pendaftaran perangkat, koordinasi dan kebijakan akses ke WireGuard. Layanan kendalinya membantu peserta saling menemukan. Data mengalir langsung antarpeer jika memungkinkan. Jika NAT atau firewall menghalangi, relay menyediakan jalur alternatif. Bahkan melalui DERP, trafik tetap terenkripsi antarpeer Tailscale.

Tailscale menghubungkan tiga gateway langsung melalui WireGuard, dengan koordinasi terpisah dan relay cadangan.

Subnet router menghubungkan seluruh LAN ke tailnet. Skenario site-to-site dalam dokumentasi Tailscale memakai Linux pada kedua endpoint. Perangkat di belakangnya tidak membutuhkan agen, tetapi tetap memerlukan rute yang benar. Menonaktifkan source NAT untuk mempertahankan alamat asli membuat perencanaan jalur balik sangat penting.

Kelebihan: perangkat LAN yang ada dapat bergabung melalui subnet router. Koneksi langsung antargateway menghindari perjalanan wajib melalui lokasi pusat. Perangkat pengguna perorangan dapat ditambahkan ke platform yang sama.

Kekurangan: jalur langsung tidak dijamin. Relay dapat mengubah latensi dan throughput. Koordinasi yang dihosting tetap menjadi ketergantungan operasional; paket dan fitur harus sesuai kebutuhan penerapan.

Enkripsi WireGuard berakhir pada peer. Jika peer itu subnet router, segmen LAN berikutnya berada di luar tunnel. HTTPS atau SSH tetap berguna di jaringan privat.

NetBird: Mesh serupa dengan opsi hosting sendiri

NetBird juga menggunakan WireGuard, berusaha membentuk koneksi langsung dan memakai relay bila diperlukan. Routing peer menghubungkan jaringan yang perangkatnya tidak menjalankan klien. Panduan site-to-site saat ini menjelaskan Networks, Resources dan kebijakan akses terkait.

NetBird menghubungkan tiga gateway langsung melalui WireGuard dengan koordinasi cloud atau hosting sendiri.

Kelebihan: proyek sumber terbuka menyediakan alternatif hosting sendiri bagi layanan cloud. Ini penting jika infrastruktur dan pengelolaan harus tetap menjadi tanggung jawab sendiri. Grup dan kebijakan membantu membatasi akses secara sengaja.

Kekurangan: hosting sendiri berarti memelihara pembaruan, cadangan, pemantauan serta ketersediaan koordinasi dan relay. Instalasi cepat tidak menghapus pekerjaan itu. Desain site-to-site Networks yang didokumentasikan mempertahankan masquerading aktif, sehingga tujuan tidak sekadar melihat alamat sumber asli. Varian routing lain perlu direncanakan tersendiri.

Tailscale dan NetBird mirip, tetapi konfigurasinya tidak dapat saling ditukar. Saya akan menilai keduanya berdasarkan routing dan model identitas yang dibutuhkan. Sumber terbuka juga tidak berarti semua fitur bebas digunakan tanpa batas: periksa lisensi dan fitur untuk penerapan yang direncanakan.

Cloudflare Mesh: Jaringan penyedia menjadi jalur

Peserta membentuk koneksi keluar ke Cloudflare. Trafik antarlokasi melewati jaringannya. Setiap lokasi tidak perlu terhubung langsung ke semua lokasi lain, dan kita tidak perlu mengoperasikan hub VPN sendiri. Batas kepercayaan serta jalurnya tetap berbeda dari mesh WireGuard langsung.

Tiga gateway membangun tunnel keluar menuju jaringan Cloudflare.

Kelebihan: menggabungkan konektivitas dengan kebijakan Gateway terpusat. Cocok dipertimbangkan jika Cloudflare One sudah digunakan. Lokasi di balik NAT dan klien bergerak bergabung lewat koneksi keluar.

Kekurangan: operasi dan jalur bergantung pada penyedia. Pemrosesan Cloudflare harus sesuai persyaratan kepercayaan dan privasi untuk data sensitif. TLS atau SSH tetap berguna bagi aplikasi. Manfaat jalur untuk aplikasi tertentu harus diukur; backbone global tidak membuktikan performa lebih baik di mana pun.

Untuk penerapan baru saya mengikuti pendekatan klien dalam dokumentasi terkini. Cloudflare menandai Mesh sebagai beta dan mensyaratkan MASQUE pada profil node. WireGuard memiliki batasan terdokumentasi untuk ketersediaan tinggi, rute IPv6 dan hostname. Router yang mendukung WireGuard saja belum setara dengan node Mesh.

Mesh juga perlu dibedakan dari tunnel cloudflared bagi aplikasi tertentu. Contoh ini membahas konektivitas IP privat dua arah antara peserta dan jaringan yang dirutekan.

Perbedaan secara ringkas

Inilah perbedaan yang saya pertimbangkan lebih dahulu. Paket berlangganan dan jalur nyata tetap harus diperiksa pada lingkungan tertentu.

KriteriaVPN tradisionalTailscaleNetBirdCloudflare Mesh
Jalur umumAntargateway, langsung atau melalui hub sendiriLangsung jika bisa, selain itu relayLangsung jika bisa, selain itu relayMelalui Cloudflare
KoordinasiGateway sendiri, controller opsionalDihostingCloud atau hosting sendiriCloudflare
Perangkat tanpa klienDi belakang gateway VPNMelalui subnet routerMelalui routing peerMelalui node yang mengumumkan rute
Akses jarak jauh tambahanSering perlu pengaturan terpisahKlien dalam tailnet yang samaKlien dalam overlay yang samaCloudflare One Client
Keunggulan utamaSesuai firewall yang adaJalur langsung dengan pengelolaan terpusatKoordinasi dapat dihosting sendiriPemrosesan jaringan dan kebijakan terpusat
Beban operasi utamaMemelihara tunnel dan ruteKetergantungan layanan dan relayMemelihara hosting sendiriPenyedia berada di jalur; perhatikan beta

Harapan saya terhadap konektivitas yang aman

Saat ditanya solusi mana paling aman, saya mulai dari koneksi yang diizinkan dan pengelolaan akses. Tunnel terenkripsi tetap bisa memberi akses terlalu luas. Saya ingin menentukan jaringan mana menjangkau layanan apa, cara melindungi administrator dan cara mencabut akses. MFA untuk administrasi dan pengguna yang didaftarkan secara pribadi, izin terbatas dan gateway terpelihara termasuk penilaian ini.

Batas enkripsi juga berbeda. VPN tradisional berakhir pada gateway; Tailscale dan NetBird mengenkripsi antarpeer, yang bisa berupa subnet router. LAN berikutnya tidak otomatis terenkripsi. Dengan Cloudflare, pemrosesan dalam jaringan penyedia harus sesuai kebutuhan perusahaan. HTTPS atau SSH tetap berguna bagi aplikasi.

Koneksi keluar mempermudah pemasangan dan dapat menghindari layanan VPN publik di cabang. Itu tidak menggantikan kebijakan akses. IP publik juga tidak otomatis membuat firewall tidak aman. Layanan yang terekspos, perlindungannya dan pengoperasian menentukan risiko. Saya tidak membuat peringkat keamanan berdasarkan nama produk.

Hal yang ingin saya periksa sebelum penerimaan

Jalur pergi dan pulang harus berfungsi. Rute ke 10.2.0.0/24 harus berada di router atau klien yang bertanggung jawab. Jika tujuan membalas lewat gateway default lain, diperlukan rute balik yang tepat. SNAT mempermudah balasan tetapi mengubah alamat yang terlihat dan memengaruhi log serta aturan. Ini harus merupakan keputusan sadar.

Untuk ketersediaan tinggi, dua node overlay saja tidak cukup. Perangkat LAN harus tetap mencapai gateway berikutnya setelah kegagalan. Keepalived dan VRRP dapat menyediakan alamat gateway virtual. Rute jauh juga harus memilih node sehat. Saya ingin melihat apa yang terjadi pada sesi TCP baru dan yang sudah berjalan saat gateway atau tunnel gagal. Proses aktif dan ping berhasil hanya menjawab sebagian.

Pengujian fungsi juga perlu mencakup koneksi yang sengaja diblokir. Jika SSH harus diizinkan dan aplikasi lain ditolak, perilaku itu harus diverifikasi. ICMP berhasil tidak membuktikan aturan TCP bekerja. Pendaftaran, kebijakan dan firewall tujuan harus selaras.

Lalu ada detail yang kurang terlihat tetapi menentukan penggunaan harian: prefiks unik, resolusi nama internal dan MTU yang tepat. Baik 192.168.x.x maupun 10.x.x.x tidak menjamin bebas konflik. Ping kecil berhasil tetapi transfer besar macet belum membuat koneksi selesai bagi saya.

Perbandingan performa memerlukan transfer berkas dan aplikasi interaktif yang sama lewat sambungan nyata. Catat jalur langsung atau relay, beban CPU dan perilaku setelah pergantian internet. Penilaian saya membahas arsitektur serta operasi, bukan peringkat kecepatan hasil pengukuran produk-produk ini.

Akses jarak jauh: Menambahkan perangkat individual

Karyawan yang menghubungkan laptop dari rumah ke perusahaan memakai remote access atau client-to-site. Klien berjalan pada laptop dan tidak otomatis menghubungkan seluruh jaringan rumah ke pusat. Bisa digunakan layanan firewall pusat atau klien platform yang dibandingkan. Pendaftaran pribadi juga memungkinkan izin berdasarkan pengguna dan grup.

Kantor rumahan dapat pula menjadi lokasi site-to-site: gateway menghubungkan jaringan yang disetujui atau VLAN ke pusat. Perbedaannya adalah perangkat atau jaringan yang dihubungkan, bukan tempat orang bekerja. Untuk perangkat individual, akses jarak jauh sering lebih sesuai. Tidak ada alasan membuat seluruh jaringan privat terjangkau tanpa disengaja.

Kapan masing-masing pendekatan masuk akal bagi saya

Untuk beberapa lokasi tetap dengan firewall tersedia, saya mulai dari VPN tradisional dan memilih antara hub-and-spoke dan tunnel langsung. Untuk lokasi di balik NAT dengan pengelolaan terpusat dan jalur langsung jika mungkin, saya membandingkan Tailscale dan NetBird. Jika koordinasi harus dioperasikan sendiri, NetBird masuk lebih awal. Bila kebijakan Cloudflare One sudah ada, saya memeriksa Mesh, status beta dan pemrosesan di jaringan penyedia. Akses jarak jauh tambahan adalah kriteria tersendiri.

Headscale juga patut dipertimbangkan: implementasi server koordinasi Tailscale yang dihosting sendiri. Ini proyek terpisah dengan cakupan fitur sendiri, bukan pengganti setiap kemampuan layanan terhosting. WireGuard manual sudah termasuk model tradisional dan cocok jika beberapa tunnel cukup tanpa lapisan pengelolaan lain.

Saat ditanya solusi terbaik, saya ingin merekomendasikan yang sesuai perusahaan dan perubahan berikutnya. Untuk penerapan kecil dengan firewall tersedia, itu tetap bisa VPN tradisional. Kondisi koneksi atau kebutuhan pengelolaan lain membuat mesh layak dipertimbangkan. Saya memilih berdasarkan apakah koneksi yang diperlukan bisa dioperasikan dengan aman, dipahami dan dipulihkan setelah gangguan.

Sampai jumpa,
Joe

Sumber