VPN throughput mesh yang tinggi untuk menghubungkan host pusat data

Kami menyewa sejumlah host di pusat data publik. Pusat data tidak menawarkan VLAN pribadi; semua host menerima satu (atau lebih) alamat IPv4 / IPv6 publik. Host datang dengan CPU yang sangat modern (Haswell quad-core, 3.4GHz) dan memiliki uplink Gbit. Area berbeda (kamar? Lantai? Gedung?) Dari pusat data saling berhubungan dengan - dari apa yang bisa saya katakan - tautan Gbit atau 500Mbit. Host kami menjalankan debian wheezy. Saat ini kami menjalankan tepat di atas 10 host, dengan harapan pertumbuhan dalam waktu dekat.

Saya mencari cara untuk membuat semua host berkomunikasi satu sama lain, aman dan percaya diri. Layer 3 baik-baik saja, layer 2 ok (tapi tidak perlu). Karena saya tidak memiliki akses ke VLAN, itu harus semacam VPN.

Yang penting bagi saya:

throughput tinggi, idealnya dekat dengan wirespeed
desentralisasi, arsitektur bertautan - ini untuk memastikan bahwa throughput tidak diperlambat oleh elemen pusat (mis. VPN concentrator)
Jejak CPU tidak berlebihan (mengingat suite cipher AESNI dan GCM, saya berharap ini bukan persyaratan yang konyol)
kemudahan penggunaan operasional; tidak terlalu rumit untuk diatur; jaringan dapat tumbuh tanpa kehilangan koneksi yang ada

Kami saat ini menggunakan tinc . Itu berdetak [2] dan [4], tapi saya hanya mencapai sekitar 600Mbit / s (simpleks) dari kecepatan kabel 960Mbit / s, dan saya kehilangan satu inti sepenuhnya. Juga, tinc 1.1 - saat ini dalam pengembangan - belum multithreaded, jadi saya terjebak dengan kinerja singlecore.

IPSec tradisional keluar dari pertanyaan, karena membutuhkan elemen pusat, atau sh * tload terowongan yang harus dikonfigurasi (untuk mencapai [2]). IPsec dengan enkripsi oportunistik akan menjadi solusi, tetapi saya tidak yakin apakah itu berhasil menjadi kode produksi yang stabil.

Saya menemukan tcpcrypt hari ini. Kecuali untuk otentikasi yang hilang, sepertinya yang saya inginkan. Implementasi Userspace berbau lambat, tetapi juga semua VPN lainnya juga. Dan mereka berbicara tentang implementasi kernel. Saya belum mencobanya, dan saya tertarik bagaimana ia berperilaku kembali [1] dan [3].

Opsi apa lagi yang ada? Apa yang dilakukan orang, yang tidak menggunakan AWS?

Informasi tambahan

Saya tertarik pada GCM, berharap itu akan mengurangi jejak CPU. Lihat makalah Intel tentang topik tersebut . Ketika berbicara dengan salah satu pengembang tinc, dia menjelaskan bahwa bahkan menggunakan AESNI untuk enkripsi, HMAC (misalnya SHA-1) masih sangat mahal pada kecepatan Gbit.

Pembaruan Terakhir

IPsec dalam mode transport bekerja dengan sempurna dan melakukan apa yang saya inginkan. Setelah banyak evaluasi, saya telah memilih Openswan daripada ipsec-tools, hanya karena mendukung AES-GCM. Pada CPU Haswell saya mengukur sekitar 910-920Mbit / detik throughput simpleks dengan sekitar 8-9% beban CPU satu kworkerd.

— Gulungan
sumber

JADI, endapan rendah? Kinerja apa yang Anda harapkan untuk dipertahankan setelah melakukan enkripsi tingkat gigabit? Tidak mungkin - saya sarankan Anda mencari host yang lebih profesional atau membunuh bagian enkripsi.

— TomTom

@tomtom menurut kertas cryptoperformance Intel kinerja enkripsi untuk AES-128-CBC adalah di 4,52 siklus per byte, yang berarti bahwa 100 MB / s akan memakan ~ 450 MHz dari satu inti. Dekripsi jauh lebih murah. Jadi, kecuali masalah implementasi khusus menurunkan kinerja, itu harus bekerja untuk beban yang tidak memerlukan kinerja CPU maksimum dan kinerja jaringan maksimum pada saat yang sama .

— the-wabbit

mengapa Anda menginginkan GCM? IPSEC tidak rentan terhadap serangan TLS, jadi mempertimbangkan menggunakan GCM untuk mengatasi kelemahan TLS dalam mode CBC adalah poin yang bisa diperdebatkan.

— the-wabbit

Yang tidak Anda inginkan adalah VPN. Apa yang Anda lakukan inginkan memang IPsec, tetapi tidak dalam mode tunnel. Sebaliknya, Anda ingin IPsec dalam mode transportasi .

Dalam konfigurasi ini, setiap host berkomunikasi langsung dengan rekannya, dan hanya muatan paket dienkripsi, meninggalkan header IP di tempat. Dengan cara ini, Anda tidak perlu melakukan senam perutean apa pun agar semuanya berfungsi.

Ya, Anda memerlukan bait koneksi IPsec untuk setiap host (kecuali host Anda dikelompokkan dalam subnet, dalam hal ini Anda dapat melakukan ini melalui blok CIDR), tetapi hal itu dapat dengan mudah dihasilkan secara programatik oleh sistem manajemen konfigurasi Anda.

Anda tidak bertanya tentang detail konfigurasi, tetapi jika Anda memerlukan beberapa petunjuk (tidak ada banyak informasi padat di sana tentang mode transportasi), Anda dapat merujuk ke posting blog ini yang saya tulis baru-baru ini.

— EEAA
sumber

Saya kedua ide untuk menggunakan mode transportasi IPSEC untuk ini. Namun menggunakan PSK dengan OpenSWAN mungkin bukan yang terbaik dari semua pengaturan. Linux sudah dilengkapi dengan implementasi IPSEC asli dan daemon keying (racoon), saya akan tetap berpegang teguh pada itu kecuali ada persyaratan khusus yang tidak dicakup oleh KAME / racoon.

— the-wabbit

Terima kasih banyak! Menggabungkan saran Anda, saya menggunakan implementasi IPsec asli dengan racoon. Saya menguji pada mesin single-core kecil pertama, dan throughput sudah meningkat 50% dan latensi turun menjadi sekitar 60%. Saya akan mengkonfirmasi pada node Haswell minggu depan dan akan menerima jawabannya. Saya perlu mencari tahu apakah AES-GCM didukung di kernel, dan bagaimana memberi sinyal ke IPsec.

— Hank

@ syneticon-dj - hanya ingin tahu ... mengapa tidak openswan? Ia masih menggunakan bit ip xfrm kernel untuk IPsec, tetapi menggunakan pluto sebagai daemon IKE ruang pengguna alih-alih racoon. Saya tidak menganjurkan bahwa openswan adalah yang terbaik di luar sana - itu saja yang saya gunakan dan jika ada opsi yang lebih baik, saya ingin pindah ke arah itu.

— EEAA

Itu mungkin bermuara pada preferensi pribadi, tetapi saya selalu memiliki masalah dengan tidak adanya file konfigurasi Free- / OpenSWAN dan implementasi routing yang benar-benar jelek. Saya sangat menyukai bagian dinamis racoonctlyang sangat mirip dengan apa yang diizinkan router komersial dalam kontrol IPSEC mereka. KAME merasa lebih direkayasa secara menyeluruh sementara OpenSWAN agak merasa disatukan.

— the-wabbit

@ syneticon-dj, maukah Anda menguraikan ini? Maksud Anda, Anda dapat merutekan beberapa jaringan melalui tautan IPSec tanpa perlu beberapa konfigurasi SA, seperti yang sekarang berlaku pada Openswan?

— rsuarez