Konsul + iptables =: 3

Pada 2010, Wargaming memiliki 50 server dan model jaringan sederhana: backend, frontend, dan firewall. Jumlah server bertambah, model menjadi lebih rumit: staging, VLAN terisolasi dengan ACL, kemudian VPN dengan VRF, VLAN dengan ACL ke L2, VRF dari ACL ke L3. Kepala berputar? Lebih banyak akan lebih menyenangkan.

Ketika server mulai bekerja 16.000 tanpa air mata dengan begitu banyak segmen heterogen, itu menjadi mustahil. Karena itu, mereka datang dengan solusi yang berbeda. Kami mengambil tumpukan Netfilter, menambahkan Konsul sebagai sumber data, dan kami mendapat firewall yang didistribusikan dengan cepat. Mereka mengganti ACL pada router dan digunakan sebagai firewall eksternal dan internal. Untuk manajemen alat yang dinamis, kami mengembangkan sistem BEFW, yang digunakan di mana-mana: dari mengendalikan akses pengguna ke jaringan bahan makanan hingga mengisolasi segmen jaringan dari satu sama lain.



Bagaimana cara kerjanya dan mengapa Anda harus melihat lebih dekat pada sistem ini, kata Ivan Agarkov (annmuor) - kepala kelompok keamanan infrastruktur unit Pemeliharaan di pusat pengembangan perusahaan Minsk. Ivan adalah penggemar SELinux, mencintai Perl, menulis kode. Sebagai kepala kelompok IB, ia secara teratur bekerja dengan log, cadangan, dan R&D untuk melindungi Wargaming dari peretas dan memastikan operasi semua server game di perusahaan.


Referensi sejarah


Sebelum memberitahu bagaimana kami melakukannya, saya akan memberi tahu Anda bagaimana kami sampai pada ini dan mengapa itu diperlukan. Untuk melakukan ini, kami transfer 9 tahun lalu: 2010, hanya World of Tanks yang muncul. Wargaming memiliki sekitar 50 server.


Grafik pertumbuhan server perusahaan.

Kami memiliki model jaringan. Untuk saat itu sudah optimal.


Model jaringan pada tahun 2010.

Di ujung depan ada orang jahat yang ingin menghancurkan kita, tetapi ada firewall di dalamnya. Tidak ada firewall di backend, tetapi ada 50 server di sana, kita semua tahu mereka. Semuanya bekerja dengan baik.

Lebih dari 4 tahun, armada server telah tumbuh 100 kali, hingga 5000. Jaringan terisolasi pertama muncul - panggung: mereka tidak dapat masuk ke produksi, dan seringkali hal-hal yang bisa berbahaya berputar di sana.


Model jaringan pada tahun 2014.

Dengan inersia, semua potongan besi yang sama digunakan, dan semua pekerjaan dilakukan pada VLAN yang terisolasi: ACL ditulis ke VLAN yang memungkinkan atau melarang koneksi apa pun.

Pada 2016, jumlah server mencapai 8000. Wargaming menyerap studio lain, jaringan afiliasi tambahan muncul. Mereka tampaknya milik kita, tetapi tidak cukup: VLAN sering tidak berfungsi untuk mitra, Anda harus menggunakan VPN dengan VRF, isolasi menjadi lebih rumit. Campuran isolat ACL tumbuh.


Model jaringan pada 2016.

Pada awal 2018, armada mobil tumbuh menjadi 16.000.Ada 6 segmen, dan sisanya kami tidak menghitung, termasuk yang tertutup, di mana data keuangan disimpan. Ada jaringan kontainer (Kubernetes), DevOps, jaringan cloud yang terhubung melalui VPN, misalnya, dari IVS. Ada banyak aturan - itu menyakitkan.


Model jaringan dan metode isolasi pada tahun 2018.

Untuk isolasi kami menggunakan: VLAN dengan ACL pada L2, VRF dengan ACL pada L3, VPN dan banyak lagi. Terlalu banyak.

Masalah


Semua orang hidup dengan ACL dan VLAN. Apa yang umumnya salah? Harold, menyembunyikan rasa sakit, akan menjawab pertanyaan ini.



Ada banyak masalah, tetapi ada lima masalah besar.

  • Kenaikan harga geometris untuk aturan baru . Setiap aturan baru ditambahkan lebih lama dari yang sebelumnya, karena Anda harus terlebih dahulu melihat apakah sudah ada aturan seperti itu.
  • Tidak ada firewall di dalam segmen . Segmen entah bagaimana dipisahkan satu sama lain, di dalamnya sudah tidak ada sumber daya yang cukup.
  • Aturan sudah diterapkan sejak lama. Tangan satu operator aturan lokal bisa menulis dalam satu jam. Global membutuhkan waktu beberapa hari.
  • Kesulitan dengan audit aturan . Lebih tepatnya, itu tidak mungkin. Aturan pertama ditulis kembali pada tahun 2010, dan sebagian besar penulis mereka tidak lagi bekerja untuk perusahaan.
  • Tingkat kontrol yang rendah terhadap infrastruktur . Ini adalah masalah utama - kami tidak tahu apa yang terjadi dengan kami.

Ini adalah apa yang tampak seperti insinyur jaringan pada tahun 2018 ketika dia mendengar: "Kami membutuhkan lebih banyak ACL."



Solusi


Pada awal 2018, diputuskan untuk melakukan sesuatu tentang hal itu.

Harga integrasi terus tumbuh. Titik awalnya adalah bahwa pusat data yang besar tidak lagi mendukung VLAN dan ACL yang terisolasi, karena memori pada perangkat habis.

Solusi: menghilangkan faktor manusia dan mengotomatiskan penyediaan akses secara maksimal.

Aturan baru berlaku untuk waktu yang lama. Solusi: mempercepat penerapan aturan, membuatnya terdistribusi dan paralel. Untuk melakukan ini, Anda memerlukan sistem terdistribusi sehingga aturan dikirimkan sendiri, tanpa rsync atau SFTP per seribu sistem.

Kurangnya firewall di dalam segmen.Firewall di dalam segmen mulai terbang kepada kami ketika berbagai layanan muncul dalam jaringan yang sama. Solusi: gunakan firewall berbasis host. Hampir di mana-mana kita memiliki Linux, dan iptables ada di mana-mana, ini bukan masalah.

Kesulitan dengan audit aturan. Solusi: simpan semua aturan di satu tempat untuk ditinjau dan dikelola, sehingga kami dapat mengaudit semuanya.

Tingkat kontrol yang rendah terhadap infrastruktur. Solusi: lakukan inventarisasi semua layanan dan akses di antara mereka.

Ini lebih merupakan proses administrasi daripada yang teknis. Terkadang kami memiliki 200-300 rilis baru per minggu, terutama selama promosi dan pada hari libur. Namun, ini hanya untuk satu tim DevOps kami. Dengan begitu banyak rilis, tidak mungkin untuk melihat port, IP, integrasi apa yang dibutuhkan. Karena itu, kami membutuhkan manajer layanan terlatih khusus yang mewawancarai tim: "Apa yang ada di sana dan mengapa Anda membesarkannya?"

Setelah semua yang kami luncurkan, insinyur jaringan pada 2019 mulai terlihat seperti ini.



Konsul


Kami memutuskan bahwa kami akan meletakkan semua yang kami temukan dengan bantuan manajer layanan di Konsul dan dari sana kami akan menulis aturan iptables.

Bagaimana kami memutuskan untuk melakukan ini?

  • Kami mengumpulkan semua layanan, jaringan, dan pengguna.
  • Mari kita membuat aturan iptables berdasarkan pada mereka.
  • Kontrol otomatis.
  • ...
  • KEUNTUNGAN.

Konsul bukan API jarak jauh, ia dapat bekerja pada setiap node dan menulis ke iptables. Tetap hanya muncul dengan kontrol otomatis yang akan membersihkan kelebihan, dan sebagian besar masalah akan terpecahkan! Kami akan menyelesaikan sisanya dalam proses.

Mengapa konsul?


Mapan. Pada 2014-15, kami menggunakannya sebagai backend untuk Vault, tempat kami menyimpan kata sandi.

Tidak kehilangan data . Selama penggunaan, Konsul tidak kehilangan data dalam kecelakaan apa pun. Ini merupakan nilai tambah besar untuk sistem manajemen firewall.

Komunikasi P2P mempercepat penyebaran perubahan . Dengan P2P, semua perubahan datang dengan cepat, tidak perlu menunggu berjam-jam.

API SISA Nyaman. Kami juga mempertimbangkan Apache ZooKeeper, tetapi tidak memiliki API REST, Anda harus meletakkan kruk.

Ini berfungsi sebagai keystore (KV), dan sebagai direktori (Service Discovery) . Anda dapat segera menyimpan layanan, katalog, pusat data. Ini nyaman tidak hanya bagi kami, tetapi juga untuk tim tetangga, karena ketika membangun layanan global, kami berpikir besar.

Ditulis dalam Go, yang merupakan bagian dari tumpukan Wargaming. Kami menyukai bahasa ini, kami memiliki banyak pengembang Go.

Sistem ACL yang kuat. Di Konsul, Anda dapat menggunakan ACL untuk mengelola siapa dan apa yang harus ditulis. Kami menjamin bahwa aturan firewall tidak akan tumpang tindih dengan hal lain dan kami tidak akan mengalami masalah dengan ini.

Tetapi Konsul memiliki kekurangannya.

  • Itu tidak skala dalam pusat data, jika Anda tidak memiliki versi bisnis. Itu hanya diskalakan oleh federasi.
  • Sangat tergantung pada kualitas jaringan dan beban server. Konsul tidak akan berfungsi secara normal sebagai server di server yang sibuk jika ada kelambatan dalam jaringan, misalnya, kecepatan tidak rata. Ini karena koneksi P2P dan memperbarui model distribusi.
  • Kesulitan dengan pemantauan aksesibilitas . Dalam status Konsul dapat mengatakan bahwa semuanya baik-baik saja, tetapi ia telah lama mati.

Kami memecahkan sebagian besar masalah ini selama pengoperasian Konsul, jadi kami memilihnya. Perusahaan memiliki rencana untuk backend alternatif, tetapi kami telah belajar bagaimana menghadapi masalah dan masih hidup dengan Konsul.

Bagaimana Konsul Bekerja


Di pusat data bersyarat, kami memasang server - mulai dari tiga hingga lima. Satu atau dua server tidak akan berfungsi: mereka tidak akan dapat mengatur kuorum dan memutuskan siapa yang benar, siapa yang salah, ketika data tidak cocok. Lebih dari lima tidak masuk akal, kinerja akan turun.



Klien terhubung dalam urutan apa pun ke server: agen yang sama, hanya dengan bendera server = false.



Setelah itu, klien menerima daftar koneksi P2P dan membangun koneksi di antara mereka.



Di tingkat global, kami menghubungkan beberapa pusat data. Mereka juga menghubungkan P2P dan berkomunikasi.



Saat kami ingin mengumpulkan data dari pusat data lain, permintaan berpindah dari server ke server. Skema semacam itu disebut protokol Serf . Protokol Budak, seperti Konsul, dikembangkan oleh HashiCorp.

Beberapa Fakta Penting Tentang Konsul


Konsul memiliki dokumentasi yang menjelaskan karyanya. Saya hanya akan memberikan fakta terpilih yang layak diketahui.

Server konsul memilih master dari kalangan pemilih . Konsul memilih wizard dari daftar server untuk setiap pusat data, dan semua permintaan hanya pergi ke sana, terlepas dari jumlah server. Hanging the wizard tidak mengarah pada pemilihan ulang. Jika wizard tidak dipilih, permintaan tidak dilayani oleh siapa pun.
Apakah Anda ingin penskalaan horizontal? Maaf tapi tidak.
Permintaan ke pusat data lain berjalan dari master ke master, terlepas dari server mana ia datang. Master yang dipilih menerima 100% dari beban, kecuali untuk beban pada permintaan penerusan. Semua server pusat data memiliki salinan data terbaru, tetapi hanya satu jawaban.
Satu-satunya cara untuk menskala adalah mengaktifkan mode basi pada klien.
Dalam mode basi, Anda dapat merespons tanpa kuorum. Ini adalah mode di mana kami menolak konsistensi data, tetapi kami membaca sedikit lebih cepat dari biasanya dan server mana pun merespons. Secara alami, perekaman hanya melalui master.

Konsul tidak menyalin data antara pusat data . Saat mengumpulkan federasi, setiap server hanya akan memiliki data sendiri. Bagi yang lain, dia selalu beralih ke orang lain.

Atomicity operasi tidak dijamin di luar transaksi . Ingatlah bahwa tidak hanya Anda yang dapat mengubah sesuatu. Jika Anda menginginkannya berbeda, lakukan transaksi dengan kunci.

Operasi pemblokiran tidak menjamin pemblokiran . Permintaan beralih dari master ke master, dan tidak secara langsung, sehingga tidak ada jaminan bahwa kunci akan berfungsi ketika Anda mengunci, misalnya, di pusat data lain.

ACL juga tidak menjamin akses (dalam banyak kasus) . ACL mungkin tidak berfungsi karena disimpan di satu pusat data federasi - di pusat data ACL (Primer DC). Jika DC tidak menjawab Anda, ACL tidak akan berfungsi.

Seorang penyihir yang sedang melayang akan membekukan seluruh federasi . Misalnya, dalam federasi ada 10 pusat data, dan di satu ada jaringan yang buruk, dan satu master jatuh. Setiap orang yang berkomunikasi dengannya terjebak dalam lingkaran: permintaan sedang dibuat, tidak ada jawaban untuk itu, utasnya hang. Tidak akan mungkin untuk mengetahui kapan ini akan terjadi, hanya dalam satu atau dua jam seluruh federasi akan jatuh. Anda tidak bisa berbuat apa-apa.

Status, kuorum, dan pemilihan diproses dalam utas terpisah. Seleksi ulang tidak akan terjadi, status tidak akan menunjukkan apa-apa. Anda berpikir bahwa Anda memiliki Konsul langsung, Anda bertanya, dan tidak ada yang terjadi - tidak ada jawaban. Apalagi statusnya menunjukkan bahwa semuanya baik-baik saja.

Kami menghadapi masalah ini, kami harus membangun kembali bagian-bagian pusat data tertentu untuk menghindarinya.

Versi bisnis dari Consul Enterprise tidak memiliki beberapa kekurangan di atas . Ini memiliki banyak fungsi yang berguna: suara, distribusi, penskalaan. Hanya ada satu "tetapi" - sistem lisensi untuk sistem terdistribusi sangat mahal.

Retas seumur hidup: rm -rf /var/lib/consul- obat untuk semua penyakit agen. Jika sesuatu tidak berhasil untuk Anda, cukup hapus data Anda dan unduh data dari salinan. Kemungkinan besar, Konsul akan bekerja.

Befw


Sekarang mari kita bicara tentang apa yang kita tambahkan ke Konsul.

BEFW - singkatan dari Bed and ack E nd the F ire of the W all. Itu perlu entah bagaimana memberi nama produk ketika saya membuat repositori untuk melakukan tes pertama yang dilakukan. Nama ini tetap ada.

Templat Aturan


Aturan ditulis dalam sintaks iptables.

  • -N BEFW
  • -P DROP INPUT
  • -A INPUT -m state - state TERKAIT, DIDIRIKAN -j MENERIMA
  • INPUT -A lo -j MENERIMA
  • INPUT -J BEFW

Kita semua pergi ke rantai BEFW, kecuali ESTABLISHED, RELATEDdan localhost. Template dapat berupa apa saja, ini hanya sebuah contoh.

Apa gunanya BEFW?

Jasa


Kami memiliki layanan, selalu memiliki port, simpul tempat kerjanya. Dari simpul kami, kami dapat secara lokal bertanya kepada agen dan mengetahui bahwa kami memiliki semacam layanan. Anda juga dapat menaruh tag.



Setiap layanan yang berjalan dan terdaftar dengan Konsul berubah menjadi aturan iptables. Kami memiliki SSH - port terbuka 22. Skrip bash sederhana: ikal dan iptables, tidak ada lagi yang diperlukan.

Pelanggan


Bagaimana cara membuka akses bukan untuk semua orang, tetapi secara selektif? Dengan nama layanan, tambahkan daftar IP ke repositori KV.



Misalnya, kami ingin semua orang dari jaringan kesepuluh dapat mengakses layanan SSH_TCP_22. Tambahkan satu bidang TTL kecil? dan sekarang kami memiliki izin sementara, misalnya, selama sehari.

Akses


Kami menghubungkan layanan dan pelanggan: kami memiliki layanan, untuk setiap penyimpanan KV siap. Sekarang kami memberikan akses bukan kepada semua orang, tetapi secara selektif.



Grup


Jika setiap kali kita menulis ribuan IP untuk diakses, kita akan lelah. Mari kita datang dengan pengelompokan - subset terpisah di KV. Kami akan menyebutnya Alias ​​(atau grup) dan kami akan menyimpan grup di sana sesuai dengan prinsip yang sama.



Connect: sekarang kita dapat membuka SSH tidak secara khusus pada P2P, tetapi pada seluruh grup atau beberapa grup. Demikian pula, ada TTL - Anda dapat menambahkan ke grup dan menghapus dari grup sementara.



Integrasi


Masalah kita adalah faktor manusia dan otomatisasi. Sejauh ini kami telah menyelesaikannya seperti itu.



Kami bekerja dengan Wayang, dan mentransfer semua yang terkait dengan sistem (kode aplikasi) ke sana. Puppetdb (PostgreSQL biasa) menyimpan daftar layanan yang berjalan di sana, Anda dapat menemukannya berdasarkan jenis sumber daya. Di sana Anda dapat menemukan siapa yang pergi ke mana. Kami juga memiliki permintaan tarik dan menggabungkan sistem permintaan untuk ini.

Kami menulis befw-sync, solusi paling sederhana yang membantu mentransfer data. Pertama, sinkronisasi cookie ke puppetdb. HTTP API dikonfigurasi di sana: kami bertanya layanan apa yang kami miliki, apa yang perlu dilakukan. Kemudian mereka membuat permintaan ke Konsul.

Apakah ada integrasi? Ya: mereka menulis aturan, diizinkan untuk menerima Permintaan Tarik. Perlu beberapa port atau menambahkan host ke beberapa grup? Tarik Permintaan, tinjau - tidak lebih "Cari 200 ACL lain dan coba lakukan sesuatu."

Optimasi


Ping localhost dengan rantai aturan kosong membutuhkan waktu 0,075 ms.



Tambahkan 10.000 iptables ke rantai ini. Akibatnya, ping akan meningkat 5 kali: iptables benar-benar linier, memproses setiap alamat membutuhkan waktu.



Untuk firewall, tempat kami memigrasikan ribuan ACL, kami memiliki banyak aturan, dan ini menyebabkan penundaan. Untuk protokol game, ini buruk.

Tetapi jika kita menempatkan 10.000 alamat di ping ipset bahkan akan berkurang.



Intinya adalah bahwa "O" (kompleksitas algoritma) untuk ipset selalu 1, tidak peduli berapa banyak aturan yang ada. Benar, ada batasan - tidak boleh ada lebih dari 65535 aturan Untuk saat ini, kita hidup dengan ini: Anda dapat menggabungkannya, memperluasnya, membuat dua ipset dalam satu.

Penyimpanan


Kelanjutan logis dari proses iterasi adalah penyimpanan informasi pelanggan untuk layanan di ipset.



Sekarang kami memiliki SSH yang sama, dan kami tidak segera menulis 100 IP, tetapi kami menetapkan nama ipset untuk berkomunikasi, dan aturan berikut DROP. Anda dapat mengulang aturan "Siapa yang tidak di sini, itu DROP", tetapi lebih jelas.

Sekarang kami memiliki aturan dan set. Tugas utama adalah membuat set sebelum menulis aturan, karena jika tidak, iptables tidak akan menulis aturan.

Skema umum


Dalam bentuk diagram, semua yang saya katakan terlihat seperti ini.



Berkomitmen untuk Wayang, semuanya dikirim ke tuan rumah, layanan ada di sini, ipset ada di sana, dan siapa pun yang tidak terdaftar di sana tidak diperbolehkan.

Memungkinkan menyangkal


Untuk menyelamatkan dunia dengan cepat atau mematikan seseorang, di awal semua rantai kami membuat dua ipset: rules_allowdan rules_deny. Bagaimana itu bekerja?

Misalnya, seseorang dengan bot menciptakan muatan di Web kami. Sebelumnya, perlu untuk menemukan IP-nya dengan log, merujuknya ke insinyur jaringan sehingga mereka dapat menemukan sumber lalu lintas dan melarangnya. Sekarang terlihat berbeda.



Kami mengirim ke Konsul, tunggu 2,5 s, dan Anda selesai. Karena Konsul cepat mendistribusikan melalui P2P, ia bekerja di mana saja, di mana saja di dunia.

Setelah saya entah bagaimana benar-benar menghentikan WOT, membuat kesalahan dengan firewall. rules_allow- Ini adalah asuransi kami terhadap kasus-kasus seperti itu. Jika kami membuat kesalahan dengan firewall di suatu tempat, ada sesuatu yang diblokir di suatu tempat, kami selalu dapat mengirim persyaratan 0.0/0untuk dengan cepat meningkatkan semuanya. Maka kita akan memperbaiki semuanya dengan tangan kita.

Set lainnya


Anda dapat menambahkan set lain di ruang angkasa $IPSETS$.



Untuk apa? Kadang-kadang seseorang membutuhkan ipset, misalnya, untuk meniru pemutusan beberapa bagian cluster. Setiap orang dapat membawa set, memanggil mereka dan mereka akan diambil dari Konsul. Pada saat yang sama, set dapat berpartisipasi dalam aturan iptables dan menjadi seperti tim NOOP: konsistensi akan didukung oleh daemon.

Pengguna


Dulu seperti ini: pengguna yang terhubung ke jaringan dan menerima parameter melalui domain. Hingga generasi firewall berikutnya, Cisco tidak dapat memahami di mana pengguna berada dan di mana IP tersebut. Oleh karena itu, akses diberikan hanya melalui mesin hostname.

Apa yang telah kita lakukan? Terjepit pada saat menerima alamat. Biasanya itu dot1x, Wi-Fi atau VPN - semuanya berjalan melalui RADIUS. Untuk setiap pengguna, buat grup dengan nama pengguna dan masukkan IP dengan TTL di dalamnya, yang sama dengan dhcpnya. Silakan - segera setelah habis masa berlakunya, aturan akan hilang.



Sekarang kita dapat membuka akses ke layanan, serta ke grup lain, dengan nama pengguna. Kami menghilangkan rasa sakit dengan nama host ketika mereka berubah, dan mengambil beban dari insinyur jaringan karena mereka tidak lagi membutuhkan Cisco. Sekarang, para insinyur sendiri meresepkan akses ke server mereka.

Isolasi


Secara paralel, kami mulai membongkar isolasi. Manajer layanan mengambil inventaris, dan kami menganalisis semua jaringan kami. Kami menguraikan mereka ke dalam kelompok yang sama, dan pada server yang diperlukan kelompok ditambahkan, misalnya, untuk ditolak. Sekarang pementasan isolasi yang sama masuk ke rules_deny dalam produksi, tetapi tidak dalam produksi itu sendiri.



Skema ini bekerja dengan cepat dan sederhana: menghapus semua ACL dari server, membongkar perangkat keras, mengurangi jumlah VLAN yang terisolasi.

Kontrol integritas


Sebelumnya, pemicu khusus bekerja untuk kami, yang memberi tahu ketika seseorang mengubah aturan firewall dengan tangan mereka. Saya menulis pemeriksa aturan firewall yang besar, sulit. Sekarang integritas mengontrol BEFW. Dia dengan penuh semangat memastikan bahwa aturan yang dia buat tidak berubah. Jika seseorang mengubah aturan firewall, ia akan mengembalikan semuanya kembali. β€œSaya dengan cepat mengangkat proxy di sini untuk bekerja dari rumah” - tidak ada opsi seperti itu lagi.

BEFW mengontrol ipset dari layanan dan daftar di befw.conf, aturan layanan dalam rantai BEFW. Tetapi tidak mengikuti rantai dan aturan lain dan ipset lainnya.

Perlindungan kecelakaan


BEFW selalu menyimpan negara sukses terakhir secara langsung dalam struktur biner state.bin. Jika terjadi kesalahan, selalu kembali ke kondisi ini.bin.



Ini adalah asuransi Konsul yang tidak stabil ketika ia tidak mengirim data atau seseorang melakukan kesalahan dan menggunakan aturan yang tidak dapat diterapkan. Agar kita tidak dibiarkan tanpa firewall, BEFW akan kembali ke keadaan terakhir jika terjadi kesalahan pada tahap tertentu.

Dalam situasi kritis, ini adalah jaminan bahwa kami akan tetap menggunakan firewall yang berfungsi. Kami membuka semua jaringan abu-abu dengan harapan admin akan datang dan memperbaikinya. Suatu hari saya akan mengeluarkannya di konfigurasi, tetapi sekarang kami hanya memiliki tiga jaringan abu-abu: 10/8, 172/12 dan 192.168 / 16. Sebagai bagian dari Konsul kami, ini adalah fitur penting yang membantu mengembangkan lebih lanjut.

: - BEFW. . GitHub.


Saya akan memberi tahu Anda tentang bug yang kami temui.

ipset tambahkan set 0.0.0.0/0. Apa yang terjadi jika Anda menambahkan ke ipset 0.0.0.0/0? Apakah semua IP akan ditambahkan? Apakah akses Internet akan dibuka?

Tidak, kami mendapatkan bug yang menghabiskan waktu dua jam untuk kami. Selain itu, bug belum berfungsi sejak 2016, itu terletak di RedHat Bugzilla di bawah nomor # 1297092, tetapi kami menemukannya secara tidak sengaja - dari laporan pengembang.

Sekarang BEFW memiliki aturan ketat, yang 0.0.0.0/0berubah menjadi dua alamat: 0.0.0.0/1dan 128.0.0.0/1.

ipset restore set <file. Apa yang dilakukan ipset saat Anda memberi tahu restore? Apakah Anda pikir ini berfungsi seperti iptables? Pulihkan data?

Tidak ada yang semacam itu - ia melakukan penggabungan, dan alamat lama tidak hilang, Anda tidak menutup akses.

Kami menemukan bug ketika kami menguji isolasi. Sekarang ada sistem yang agak rumit - bukannya restoredilakukan create temp, dulu restore flush tempdan kemudian restore temp. Pada akhir swap: untuk atomicity, karena jika Anda pertama kali melakukan flushdan pada saat itu beberapa paket tiba, itu akan dibuang dan ada sesuatu yang salah. Karena itu, ada sedikit ilmu hitam.

consul kv get -datacenter = lainnya. Seperti yang saya katakan, kami berpikir bahwa kami meminta beberapa data, tetapi kami akan mendapatkan data atau kesalahan. Kita dapat melakukan ini melalui Konsul secara lokal, tetapi dalam kasus ini keduanya akan hang.

Klien Konsul lokal adalah pembungkus API HTTP. Tapi itu hanya hang dan tidak menjawab Ctrl + C, atau Ctrl + Z, tidak peduli apa, hanyakill -9di konsol yang berdekatan. Kami menemukan ini ketika kami sedang membangun sebuah cluster besar. Tapi kami masih belum punya solusi, kami sedang bersiap untuk memperbaiki kesalahan ini di Konsul.

Pemimpin konsul tidak merespons. Master kami di pusat data tidak merespons, kami berpikir: "Mungkin, algoritma seleksi ulang akan berfungsi sekarang?"

Tidak, itu tidak akan bekerja, dan pemantauan tidak akan menunjukkan apa-apa: Konsul akan mengatakan bahwa ada indeks komitmen, seorang pemimpin telah ditemukan, semuanya baik-baik saja.

Bagaimana kita melawan ini? service consul restartdi cron setiap jam. Jika Anda memiliki 50 server - bukan masalah besar. Ketika akan ada 16.000, Anda akan mengerti cara kerjanya.

Kesimpulan


Hasilnya, kami mendapat keuntungan sebagai berikut:

  • Cakupan 100% dari semua mesin Linux.
  • Kecepatan.
  • Otomatisasi
  • Insinyur besi dan jaringan dibebaskan dari perbudakan.
  • Ada peluang integrasi yang hampir tak ada habisnya: bahkan dengan Kubernetes, bahkan dengan Ansible, bahkan dengan Python.

Cons : Consul, dengan siapa kita hidup sekarang, dan harga kesalahan yang sangat tinggi. Sebagai contoh, pada jam 6 sore (jam tayang utama di Rusia), saya memutuskan sesuatu dalam daftar jaringan. Kami membangun isolasi di BEFW saat itu. Saya keliru di suatu tempat, sepertinya, saya menunjukkan topeng yang salah, tetapi semuanya jatuh dalam dua detik. Memantau menyala, petugas jaga datang: "Semuanya ada pada kita!" Kepala departemen berubah abu-abu ketika dia menjelaskan kepada bisnis mengapa ini terjadi.

Harga kesalahan sangat tinggi sehingga kami membuat prosedur profilaksis rumit kami sendiri. Jika Anda akan menerapkannya pada produksi besar, Anda tidak perlu memberikan token utama kepada Konsul kepada semua orang. Itu akan berakhir dengan buruk.

Biaya.Saya menulis kode selama 400 jam sendirian. Untuk mendukung tim saya yang terdiri dari 4 orang menghabiskan 10 jam sebulan sama sekali. Dibandingkan dengan harga firewall generasi baru, gratis.

Rencana. Rencana jangka panjang adalah mencari transportasi alternatif sebagai imbalan atau sebagai tambahan untuk Konsul. Mungkin itu akan Kafka atau semacamnya. Tetapi di tahun-tahun mendatang kita akan hidup di Konsul.

Rencana segera: integrasi dengan Fail2ban, dengan pemantauan, dengan nftables, mungkin dengan distribusi lain, metrik, pemantauan lanjutan, optimisasi. Dukungan Kubernetes juga ada di suatu rencana, karena saat ini kami memiliki beberapa kluster dan keinginan.

Rencana lainnya:

  • mencari anomali lalu lintas;
  • manajemen peta jaringan;
  • Dukungan Kubernetes;
  • perakitan paket untuk semua sistem;
  • UI web

Kami terus berupaya memperluas konfigurasi, meningkatkan metrik, dan mengoptimalkan.

Bergabunglah dengan proyek ini. Proyek itu ternyata keren, tapi, sayangnya, ini masih proyek satu orang. Datanglah ke GitHub dan coba lakukan sesuatu: komit, tes, tawarkan sesuatu, berikan penilaian Anda.

Sementara itu, kami bersiap-siap untuk Saint HighLoad ++ , yang akan diadakan pada tanggal 6 dan 7 April di St. Petersburg, dan kami mengundang pengembang sistem yang sarat muatan untuk mengajukan laporan . Pembicara yang berpengalaman sudah tahu apa yang harus dilakukan, dan kami menyarankan agar pendatang baru untuk pidato setidaknya mencoba . Berpartisipasi dalam konferensi sebagai pembicara memiliki beberapa keunggulan. Yang mana, Anda dapat membaca, misalnya, di akhir artikel ini .

Source: https://habr.com/ru/post/undefined/


All Articles