Hari ini, kami dengan senang hati mengumumkan dukungan untuk IPsec sebagai pendukung Cloudflare One. Sebagai pelanggan, Anda harus dapat menggunakan metode apa pun yang Anda inginkan untuk mendapatkan traffic ke jaringan Cloudflare. Kami telah mendengar dari Anda bahwa IPsec adalah metode pilihan Anda untuk terhubung dengan kami di layer jaringan, karena dukungan vendor yang hampir universal dan lapisan enkripsi menyeluruh di semua traffic. Jadi kami membangun dukungan untuk itu! Baca terus untuk mengetahui bagaimana implementasi IPsec kami lebih cepat dan lebih mudah digunakan daripada konektivitas IPsec tradisional, dan bagaimana implementasinya terintegrasi secara mendalam dengan suite Cloudflare One kami untuk memberikan keamanan, kinerja, dan keandalan terpadu di semua traffic Anda.
Menggunakan Internet sebagai jaringan perusahaan Anda
Dengan Cloudflare One, pelanggan dapat menghubungkan sumber atau tujuan traffic mana pun — kantor cabang, pusat data, properti cloud, perangkat pengguna — ke jaringan kami. traffic dirutekan ke lokasi Cloudflare terdekat, tempat kebijakan keamanan diterapkan sebelum kami mengirimkannya di sepanjang rute yang dioptimalkan ke tujuannya — baik itu dalam jaringan pribadi Anda atau di Internet. Ini adalah praktik yang baik untuk mengenkripsi traffic apa pun yang sensitif di tingkat aplikasi, tetapi bagi pelanggan yang beralih dari bentuk konektivitas pribadi seperti Pengalihan Label Multiprotokol (MPLS), ini sering kali tidak menjadi kenyataan. Kami telah berbicara dengan banyak pelanggan yang memiliki transfer file lama dan aplikasi lain yang berjalan di sirkuit MPLS mereka tidak terenkripsi, dan mengandalkan fakta bahwa sirkuit ini "pribadi" untuk memberikan keamanan. Untuk mulai mengirimkan traffic ini melalui Internet, pelanggan memerlukan layer enkripsi menyeluruh di semua itu; tunnel IPsec secara tradisional merupakan cara mudah untuk mencapai ini.
Implementasi IPsec tradisional
IPsec sebagai teknologi telah ada sejak tahun 1995 dan diimplementasikan secara luas di berbagai platform perangkat keras dan perangkat lunak. Banyak perusahaan telah mengadopsi VPN IPsec untuk mentransfer traffic perusahaan dengan aman melalui Internet. VPN ini cenderung memiliki salah satu dari dua arsitektur utama: hub and spoke, atau mesh.
Dalam model hub and spoke, setiap node “spoke” membuat tunnel IPsec kembali ke “hub” inti, biasanya lokasi kantor pusat atau pusat data. Traffic antara spoke mengalir melalui hub untuk perutean dan agar kebijakan keamanan diterapkan (seperti oleh firewall di lokasi). Arsitektur ini sederhana karena setiap node hanya perlu memelihara satu tunnel untuk mendapatkan konektivitas ke lokasi lain, tetapi dapat menimbulkan penalti kinerja yang signifikan. Bayangkan sebuah jaringan global dengan dua ”jari-jari”, satu di India dan satu lagi di Singapura, tetapi sebuah ”pusat” yang terletak di Amerika Serikat — traffic perlu menempuh perjalanan pulang pergi ribuan mil bolak-balik untuk sampai ke tujuannya.
Dalam model mesh, setiap node terhubung ke setiap node lain dengan tunnel IPsec khusus. Ini meningkatkan kinerja karena traffic dapat mengambil lebih banyak jalur langsung, tetapi dalam praktiknya berarti jumlah tunnel yang tidak dapat dikelola bahkan setelah beberapa lokasi ditambahkan.
Pelanggan yang telah kami ajak bicara tentang IPsec tahu bahwa mereka menginginkannya untuk enkripsi layer selimut dan dukungan vendor yang luas, tetapi mereka belum terlalu tertarik dengan hal tersebut karena masalah dengan model arsitektur yang ada. Kami tahu kami ingin mengembangkan sesuatu yang lebih mudah digunakan dan meninggalkan masalah tersebut di masa lalu, sehingga pelanggan dapat bersemangat untuk membangun jaringan generasi berikutnya di Cloudflare. Jadi bagaimana kita membawa IPsec keluar dari tahun 90-an? Dengan mengirimkannya di jaringan Anycast global kami: pelanggan membuat satu tunnel IPsec kepada kami dan mendapatkan konektivitas otomatis ke 250+ lokasi. Secara konseptual mirip dengan model hub and spoke, tetapi "hub" ada di mana-mana, sangat cepat, dan mudah dikelola.
Jadi bagaimana sebenarnya cara kerja IPsec?
IPsec dirancang kembali pada tahun 1995 untuk memberikan autentikasi, integritas, dan kerahasiaan untuk paket IP. Salah satu cara melakukannya adalah dengan membuat tunnel antara dua host, mengenkripsi paket IP, dan menambahkan header IP baru ke paket terenkripsi. Untuk mewujudkannya, IPsec memiliki dua komponen yang bekerja bersama: daemon Internet Key Exchange (IKE) userspace dan tumpukan IPsec di ruang kernel. IKE adalah protokol yang menciptakan Asosiasi Keamanan (SA) untuk IPsec. SA adalah kumpulan semua parameter keamanan, seperti untuk autentikasi dan enkripsi, yang diperlukan untuk membuat tunnel IPsec.
Saat tunnel IPsec baru perlu disiapkan, satu daemon IKE akan memulai sesi dengan yang lain dan membuat SA. Semua kerumitan konfigurasi, negosiasi kunci, dan pembuatan kunci terjadi dalam beberapa paket antara dua daemon IKE dengan aman di ruang pengguna. Setelah IKE Daemon memulai sesi mereka, mereka menyerahkan SA mereka yang bagus dan rapi ke tumpukan IPsec di ruang kernel, yang sekarang memiliki semua informasi yang dibutuhkan untuk mencegat paket yang tepat untuk enkripsi dan dekripsi.
Ada banyak daemon IKE open source, termasuk strongSwan, Libreswan, dan Openswan, yang kami pertimbangkan untuk digunakan untuk implementasi IPsec kami. "Angsa" ini semuanya mengikat protokol IKE dengan mengonfigurasi tumpukan IPsec. Ini bagus untuk membangun tunnel titik-ke-titik — menginstal satu "angsa" adalah satu-satunya yang harus dilakukan untuk berbicara IKE dan mengonfigurasi tunnel terenkripsi. Tetapi kami sedang membangun jaringan generasi berikutnya yang memanfaatkan seluruh keunggulan Anycast global Cloudflare. Jadi bagaimana kita membuatnya sehingga pelanggan membuat satu tunnel dengan Cloudflare dengan setiap server tepi yang mampu bertukar data di dalamnya?
Anycast IPsec: implementasi untuk jaringan generasi berikutnya
Masalah mendasar dari cara kerja Anycast IPsec adalah bahwa SA harus diserahkan ke tumpukan IPsec ruang-kernel di setiap server tepi Cloudflare, tetapi SA dibuat hanya di satu server — yang menjalankan daemon IKE yang terhubung dengan daemon IKE pelanggan. Bagaimana cara mengatasi masalah ini? Hal pertama yang harus dipastikan benar adalah setiap server harus dapat membuat SA tersebut.
Setiap server Cloudflare sekarang menjalankan daemon IKE, sehingga pelanggan dapat memiliki koneksi yang cepat dan andal untuk memulai tunnel di mana saja di dunia. Kami melihat menggunakan salah satu "angsa" yang ada tetapi penggabungan ketat IKE dengan tumpukan IPsec berarti bahwa SA sulit untuk dilepaskan dari mengonfigurasi dataplane. Kami membutuhkan SA yang benar-benar terpisah dan mudah dibagikan dari server yang membuatnya ke setiap server lain di tepi kami. Secara alami, kami membangun "angsa" kami sendiri untuk melakukan hal itu.
Untuk mengirim SA kami ke seluruh dunia, kami melakukan putaran baru pada trik lama. Dengan Cloudflare Tunnels, proses tunnel cloudflare pelanggan membuat koneksi ke beberapa server tepi Cloudflare terdekat. Tetapi traffic yang ditujukan untuk tunnel itu dapat tiba di server tepi mana pun, yang perlu mengetahui cara memproksi traffic ke server tepi yang terhubung dengan tunnel. Jadi, kami membangun teknologi yang memungkinkan server tepi untuk mendistribusikan informasi dengan cepat tentang koneksi Cloudflare Tunnel ke semua server tepi lainnya.
Pada dasarnya, masalah distribusi SA serupa -- daemon IKE pelanggan terhubung ke daemon IKE server Cloudflare tepi tunggal, dan informasi tentang koneksi itu perlu didistribusikan ke setiap server tepi lainnya. Jadi, kami meningkatkan teknologi Cloudflare Tunnel untuk membuatnya lebih umum dan sekarang menggunakannya untuk mendistribusikan SA sebagai bagian dari dukungan Anycast IPsec. Dalam beberapa detik setelah SA dibuat, itu didistribusikan ke setiap server tepi Cloudflare di mana protokol streaming menerapkan konfigurasi ke tumpukan IPsec ruang kernel. Anycast IPsec Cloudflare mendapat manfaat dari keandalan dan ketahanan yang sama dengan yang kami buat di Cloudflare Tunnels dan mengubah jaringan kami menjadi satu tunnel IPsec yang dapat diskalakan dan tangguh ke jaringan Anda.
On-ramp dengan IPsec, akses seluruh Cloudflare One
Kami membangun IPsec sebagai on-ramp ke Cloudflare One di atas arsitektur sistem global kami yang ada, dengan mengutamakan prinsip-prinsip yang dipedulikan pelanggan. Anda peduli dengan kemudahan penerapan, jadi kami memungkinkan Anda untuk terhubung ke seluruh jaringan virtual Anda di Cloudflare One dengan satu tunnel IPsec. Anda peduli dengan kinerja, jadi kami membangun teknologi yang menghubungkan tunnel IPsec Anda ke setiap lokasi Cloudflare, menghilangkan penalti kinerja hub-and-spoke. Anda peduli untuk menegakkan kebijakan keamanan di semua traffic Anda terlepas dari sumbernya, jadi kami mengintegrasikan IPsec dengan seluruh suite Cloudflare One termasuk Magic Transit, Magic Firewall, Zero Trust, dan banyak lagi.
IPsec dalam akses awal untuk pelanggan Cloudflare One. Jika Anda tertarik untuk mencobanya, hubungi tim akun Anda hari ini!