Pada tahun 2010 syarikat itu terdapat 50 pelayan dan model rangkaian mudah: hujung belakang, bahagian hadapan dan tembok api. Bilangan pelayan bertambah, model menjadi lebih kompleks: pementasan, VLAN terpencil dengan ACL, kemudian VPN dengan VRF, VLAN dengan ACL pada L2, VRF dengan ACL pada L3. Kepala berpusing? Lebih seronok nanti.
Apabila terdapat 16 pelayan, ia menjadi mustahil untuk berfungsi tanpa air mata dengan begitu banyak segmen heterogen. Jadi kami datang dengan penyelesaian lain. Kami mengambil timbunan Netfilter, menambah Konsul padanya sebagai sumber data dan kami mendapat tembok api yang diedarkan dengan pantas. Mereka menggantikan ACL pada penghala dan menggunakannya sebagai tembok api luaran dan dalaman. Untuk mengurus alat secara dinamik, kami membangunkan sistem BEFW, yang digunakan di mana-mana: daripada mengurus akses pengguna kepada rangkaian produk kepada mengasingkan segmen rangkaian antara satu sama lain.
Dia akan memberitahu anda bagaimana semuanya berfungsi dan mengapa anda perlu melihat dengan lebih dekat sistem ini. Ivan Agarkov () ialah ketua kumpulan keselamatan infrastruktur bahagian Penyelenggaraan di pusat pembangunan Minsk syarikat. Ivan ialah peminat SELinux, suka Perl, dan menulis kod. Sebagai ketua kumpulan keselamatan maklumat, beliau kerap bekerja dengan log, sandaran dan R&D untuk melindungi Wargaming daripada penggodam dan memastikan operasi semua pelayan permainan dalam syarikat.
Maklumat sejarah
Sebelum saya memberitahu anda bagaimana kami melakukannya, saya akan memberitahu anda bagaimana kami mencapai perkara ini pada mulanya dan mengapa ia diperlukan. Untuk melakukan ini, mari kita kembali ke 9 tahun: 2010, World of Tanks baru sahaja muncul. Wargaming mempunyai kira-kira 50 pelayan.
Carta pertumbuhan pelayan syarikat.
Kami mempunyai model rangkaian. Untuk masa itu ia adalah optimum.
Model rangkaian pada tahun 2010.
Terdapat orang jahat di bahagian hadapan yang ingin memecahkan kami, tetapi ia mempunyai tembok api. Tiada tembok api di bahagian belakang, tetapi terdapat 50 pelayan di sana, kami tahu semuanya. Semuanya berfungsi dengan baik.
Dalam 4 tahun, armada pelayan meningkat 100 kali ganda, kepada 5000. Rangkaian terpencil pertama muncul - pementasan: mereka tidak dapat pergi ke pengeluaran, dan sering terdapat perkara yang berjalan di sana yang boleh berbahaya.
Model rangkaian pada tahun 2014.
Dengan inersia, kami menggunakan kepingan perkakasan yang sama, dan semua kerja telah dijalankan pada VLAN terpencil: ACL ditulis kepada VLAN, yang membenarkan atau menafikan beberapa jenis sambungan.
Pada tahun 2016, bilangan pelayan mencapai 8000. Wargaming menyerap studio lain, dan rangkaian gabungan tambahan muncul. Mereka nampaknya milik kita, tetapi tidak cukup: VLAN selalunya tidak berfungsi untuk rakan kongsi, anda perlu menggunakan VPN dengan VRF, pengasingan menjadi lebih rumit. Campuran penebat ACL berkembang.
Model rangkaian pada tahun 2016.
Menjelang awal tahun 2018, kumpulan mesin telah berkembang kepada 16. Terdapat 000 segmen, dan kami tidak mengira yang lain, termasuk segmen tertutup di mana data kewangan disimpan. Rangkaian kontena (Kubernetes), DevOps, rangkaian awan yang disambungkan melalui VPN, contohnya, daripada IVS, telah muncul. Terdapat banyak peraturan - ia menyakitkan.
Model rangkaian dan kaedah pengasingan pada 2018.
Untuk pengasingan 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 salahnya Soalan ini akan dijawab oleh Harold, menyembunyikan kesakitan.
Terdapat banyak masalah, tetapi terdapat lima masalah besar.
- Kenaikan harga geometri untuk peraturan baharu. Setiap peraturan baharu mengambil masa yang lebih lama untuk ditambah berbanding peraturan sebelumnya, kerana anda perlu melihat dahulu sama ada peraturan sedemikian sudah ada.
- Tiada tembok api di dalam segmen. Segmen itu entah bagaimana dipisahkan antara satu sama lain, dan sudah tidak ada sumber yang mencukupi di dalamnya.
- Peraturan itu digunakan untuk masa yang lama. Operator boleh menulis satu peraturan tempatan dengan tangan dalam satu jam. Yang global mengambil masa beberapa hari.
- Kesukaran dengan peraturan pengauditan. Lebih tepat lagi, ia tidak mungkin. Peraturan pertama telah ditulis pada tahun 2010, dan kebanyakan pengarang mereka tidak lagi bekerja untuk syarikat itu.
- Tahap kawalan infrastruktur yang rendah. Ini adalah masalah utama - kami tidak tahu apa yang berlaku di negara kami.
Beginilah rupa seorang jurutera rangkaian pada tahun 2018 apabila dia mendengar: "Memerlukan ACL lagi."
Penyelesaian
Pada awal tahun 2018, ia telah memutuskan untuk melakukan sesuatu mengenainya.
Harga integrasi sentiasa meningkat. Titik permulaan ialah pusat data yang besar berhenti menyokong VLAN dan ACL terpencil kerana peranti kehabisan memori.
Penyelesaian: kami mengalih keluar faktor manusia dan mengautomasikan penyediaan akses kepada maksimum.
Peraturan baharu mengambil masa yang lama untuk digunakan. Penyelesaian: percepatkan penggunaan peraturan, jadikan ia diedarkan dan selari. Ini memerlukan sistem yang diedarkan supaya peraturan dihantar sendiri, tanpa rsync atau SFTP kepada seribu sistem.
Tiada tembok api di dalam segmen. Firewall dalam segmen mula datang kepada kami apabila perkhidmatan berbeza muncul dalam rangkaian yang sama. Penyelesaian: gunakan tembok api di peringkat hos - tembok api berasaskan hos. Hampir di mana-mana kita mempunyai Linux, dan di mana-mana sahaja kita mempunyai iptables, ini tidak menjadi masalah.
Kesukaran dengan peraturan pengauditan. Penyelesaian: Simpan semua peraturan di satu tempat untuk semakan dan pengurusan, supaya kami boleh mengaudit segala-galanya.
Tahap kawalan rendah ke atas infrastruktur. Penyelesaian: ambil inventori semua perkhidmatan dan akses antara mereka.
Ini lebih kepada proses pentadbiran berbanding teknikal. Kadangkala kami mempunyai 200-300 keluaran baharu seminggu, terutamanya semasa promosi dan cuti. Selain itu, ini hanya untuk satu pasukan DevOps kami. Dengan begitu banyak keluaran, adalah mustahil untuk melihat port, IP dan penyepaduan yang diperlukan. Oleh itu, kami memerlukan pengurus perkhidmatan terlatih khas yang bertanya kepada pasukan: "Apa yang ada dan mengapa anda mengemukakannya?"
Selepas semua yang kami lancarkan, seorang jurutera rangkaian pada 2019 mula kelihatan seperti ini.
Konsul
Kami memutuskan bahawa kami akan meletakkan semua yang kami temui dengan bantuan pengurus perkhidmatan ke dalam Konsul dan dari situ kami akan menulis peraturan iptables.
Bagaimanakah kami memutuskan untuk melakukan ini?
- Kami akan mengumpul semua perkhidmatan, rangkaian dan pengguna.
- Mari buat peraturan iptables berdasarkan peraturan tersebut.
- Kami mengautomasikan kawalan.
- ....
- UNTUNG.
Consul bukan API jauh, ia boleh berjalan pada setiap nod dan menulis kepada iptables. Apa yang tinggal ialah menghasilkan kawalan automatik yang akan membersihkan perkara yang tidak perlu, dan kebanyakan masalah akan diselesaikan! Selebihnya akan kami selesaikan semasa kami pergi.
Kenapa Konsul?
Telah membuktikan dirinya dengan baik. Pada 2014-15, kami menggunakannya sebagai bahagian belakang untuk Vault, di mana kami menyimpan kata laluan.
Tidak kehilangan data. Semasa masa penggunaan, Consul tidak kehilangan data semasa satu kemalangan. Ini adalah tambahan yang besar untuk sistem pengurusan firewall.
Sambungan P2P mempercepatkan penyebaran perubahan. Dengan P2P, semua perubahan datang dengan cepat, tidak perlu menunggu berjam-jam.
API REST yang mudah. Kami juga menganggap Apache ZooKeeper, tetapi ia tidak mempunyai API REST, jadi anda perlu memasang tongkat.
Berfungsi sebagai Key Vault (KV) dan Direktori (Service Discovery). Anda boleh menyimpan perkhidmatan, katalog dan pusat data sekaligus. Ini mudah bukan sahaja untuk kami, tetapi juga untuk pasukan jiran, kerana apabila membina perkhidmatan global, kami berfikir besar.
Ditulis dalam Go, yang merupakan sebahagian daripada timbunan Wargaming. Kami menyukai bahasa ini, kami mempunyai ramai pembangun Go.
Sistem ACL yang berkuasa. Dalam Konsul, anda boleh menggunakan ACL untuk mengawal siapa yang menulis apa. Kami menjamin bahawa peraturan tembok api tidak akan bertindih dengan perkara lain dan kami tidak akan menghadapi masalah dengan ini.
Tetapi Konsul juga mempunyai kelemahannya.
- Tidak skala dalam pusat data melainkan anda mempunyai versi perniagaan. Ia hanya boleh skala oleh persekutuan.
- Sangat bergantung pada kualiti rangkaian dan beban pelayan. Konsul tidak akan berfungsi dengan betul sebagai pelayan pada pelayan yang sibuk jika terdapat sebarang ketinggalan dalam rangkaian, contohnya, kelajuan tidak sekata. Ini disebabkan oleh sambungan P2P dan mengemas kini model pengedaran.
- Kesukaran memantau ketersediaan. Dalam status Konsul, dia boleh mengatakan semuanya baik-baik saja, tetapi dia sudah lama meninggal dunia.
Kami menyelesaikan kebanyakan masalah ini semasa menggunakan Konsul, itulah sebabnya kami memilihnya. Syarikat itu mempunyai rancangan untuk bahagian belakang alternatif, tetapi kami telah belajar menangani masalah dan kini tinggal bersama Konsul.
Bagaimana Konsul berfungsi
Kami akan memasang tiga hingga lima pelayan di pusat data bersyarat. Satu atau dua pelayan tidak akan berfungsi: mereka tidak akan dapat mengatur kuorum dan memutuskan siapa yang betul dan siapa yang salah apabila data tidak sepadan. Lebih daripada lima tidak masuk akal, produktiviti akan menurun.
Pelanggan menyambung ke pelayan dalam sebarang susunan: ejen yang sama, hanya dengan bendera server = false.
Selepas ini, pelanggan menerima senarai sambungan P2P dan membina sambungan sesama mereka.
Di peringkat global, kami menghubungkan beberapa pusat data. Mereka juga menghubungkan P2P dan berkomunikasi.
Apabila kami ingin mendapatkan semula data dari pusat data lain, permintaan pergi dari pelayan ke pelayan. Skim ini dipanggil Protokol hamba. Protokol Serf, seperti Konsul, dibangunkan oleh HashiCorp.
Beberapa fakta penting tentang Konsul
Konsul mempunyai dokumentasi yang menerangkan cara ia berfungsi. Saya hanya akan memberikan fakta terpilih yang patut diketahui.
Pelayan konsul memilih tuan daripada kalangan pengundi. Konsul memilih induk daripada senarai pelayan untuk setiap pusat data, dan semua permintaan pergi hanya kepadanya, tanpa mengira bilangan pelayan. Pembekuan induk tidak membawa kepada pemilihan semula. Jika tuan tidak dipilih, permintaan tidak dilayan oleh sesiapa.
Adakah anda mahu penskalaan mendatar? Maaf, tidak.
Permintaan ke pusat data lain pergi dari induk ke induk, tanpa mengira pelayan mana ia datang. Induk yang dipilih menerima 100% daripada beban, kecuali untuk beban pada permintaan hadapan. Semua pelayan di pusat data mempunyai salinan data yang terkini, tetapi hanya satu yang bertindak balas.
Satu-satunya cara untuk membuat skala adalah dengan mendayakan mod basi pada klien.
Dalam mod basi, anda boleh membalas tanpa korum. Ini ialah mod di mana kami melepaskan konsistensi data, tetapi membaca sedikit lebih cepat daripada biasa, dan mana-mana pelayan bertindak balas. Sememangnya, rakaman hanya melalui tuan.
Konsul tidak menyalin data antara pusat data. Apabila persekutuan dipasang, setiap pelayan hanya akan mempunyai datanya sendiri. Bagi orang lain, dia sentiasa beralih kepada orang lain.
Atomiti operasi tidak dijamin di luar transaksi. Ingat bahawa anda bukan satu-satunya yang boleh mengubah keadaan. Jika anda mahukannya secara berbeza, lakukan transaksi dengan kunci.
Operasi menyekat tidak menjamin penguncian. Permintaan pergi dari induk ke induk, dan bukan secara langsung, jadi tiada jaminan bahawa penyekatan akan berfungsi apabila anda menyekat, contohnya, di pusat data lain.
ACL juga tidak menjamin akses (dalam banyak kes). ACL mungkin tidak berfungsi kerana ia disimpan dalam satu pusat data persekutuan - dalam pusat data ACL (DC Utama). Jika DC tidak menjawab anda, ACL tidak akan berfungsi.
Seorang tuan beku akan menyebabkan seluruh persekutuan menjadi beku. Sebagai contoh, terdapat 10 pusat data dalam persekutuan, dan satu mempunyai rangkaian yang buruk, dan satu induk gagal. Setiap orang yang berkomunikasi dengannya akan terperangkap dalam bulatan: ada permintaan, tidak ada jawapan kepadanya, benang membeku. Tidak ada cara untuk mengetahui bila ini akan berlaku, hanya dalam satu atau dua jam seluruh persekutuan akan tumbang. Tiada apa yang boleh anda lakukan mengenainya.
Status, kuorum dan pilihan raya dikendalikan oleh urutan yang berasingan. Pemilihan semula tidak akan berlaku, status tidak akan menunjukkan apa-apa. Anda fikir anda mempunyai Konsul langsung, anda bertanya, dan tiada apa yang berlaku - tiada jawapan. Pada masa yang sama, status menunjukkan bahawa semuanya baik-baik saja.
Kami telah menghadapi masalah ini dan terpaksa membina semula bahagian tertentu pusat data untuk mengelakkannya.
Versi perniagaan Consul Enterprise tidak mempunyai beberapa kelemahan di atas. Ia mempunyai banyak fungsi berguna: memilih pengundi, pengedaran, penskalaan. Terdapat hanya satu "tetapi" - sistem pelesenan untuk sistem yang diedarkan sangat mahal.
Penggodaman hayat: rm -rf /var/lib/consul - penawar segala penyakit ejen. Jika sesuatu tidak berfungsi untuk anda, hanya padamkan data anda dan muat turun data daripada salinan. Kemungkinan besar, Konsul akan bekerja.
BEFW
Sekarang mari kita bercakap tentang perkara yang telah kami tambahkan kepada Konsul.
ialah akronim untuk BackEndFkemarahanWsemua. Saya terpaksa menamakan produk itu entah bagaimana apabila saya mencipta repositori untuk meletakkan ujian pertama yang dilakukan ke dalamnya. Nama ini kekal.
Templat peraturan
Peraturan ditulis dalam sintaks iptables.
- -N BEFW
- -P INPUT DROP
- -A INPUT -m negeriβnegeri BERKAITAN, DIBUAT -j TERIMA
- -A INPUT -i lo -j TERIMA
- -A INPUT -j BEFW
Semuanya masuk ke rantai BEFW, kecuali ESTABLISHED, RELATED dan localhost. Templat boleh jadi apa sahaja, ini hanya contoh.
Bagaimanakah BEFW berguna?
Perkhidmatan
Kami mempunyai perkhidmatan, ia sentiasa mempunyai port, nod di mana ia berjalan. Daripada nod kami, kami boleh meminta ejen secara tempatan dan mengetahui bahawa kami mempunyai beberapa jenis perkhidmatan. Anda juga boleh meletakkan tag.
Sebarang perkhidmatan yang sedang berjalan dan berdaftar dengan Konsul bertukar menjadi peraturan iptables. Kami mempunyai SSH - port terbuka 22. Skrip Bash adalah mudah: curl dan iptables, tiada apa-apa lagi yang diperlukan.
Pelanggan
Bagaimana untuk membuka akses bukan kepada semua orang, tetapi secara terpilih? Tambahkan senarai IP ke storan KV mengikut nama perkhidmatan.
Sebagai contoh, kami mahu semua orang di rangkaian kesepuluh dapat mengakses perkhidmatan SSH_TCP_22. Tambahkan satu medan TTL kecil? dan sekarang kami mempunyai permit sementara, contohnya, untuk sehari.
Akses
Kami menghubungkan perkhidmatan dan pelanggan: kami mempunyai perkhidmatan, storan KV sedia untuk setiap satu. Kini kami tidak memberikan akses kepada semua orang, tetapi secara terpilih.
Kumpulan
Jika kita menulis beribu-ribu IP untuk akses setiap kali, kita akan menjadi letih. Mari kita buat kumpulan - subset berasingan dalam KV. Mari kita panggil Alias ββββ(atau kumpulan) dan simpan kumpulan di sana mengikut prinsip yang sama.
Mari sambung: kini kita boleh membuka SSH bukan khusus untuk P2P, tetapi untuk keseluruhan kumpulan atau beberapa kumpulan. Dengan cara yang sama, terdapat TTL - anda boleh menambah pada kumpulan dan mengalih keluar daripada kumpulan buat sementara waktu.
Integrasi
Masalah kita ialah faktor manusia dan automasi. Setakat ini kami telah menyelesaikannya dengan cara ini.
Kami bekerja dengan Puppet, dan memindahkan semua yang berkaitan dengan sistem (kod aplikasi) kepada mereka. Puppetdb (PostgreSQL biasa) menyimpan senarai perkhidmatan yang dijalankan di sana, ia boleh didapati mengikut jenis sumber. Di sana anda boleh mengetahui siapa yang memohon di mana. Kami juga mempunyai permintaan tarik dan sistem permintaan gabungan untuk ini.
Kami menulis befw-sync, penyelesaian mudah yang membantu memindahkan data. Pertama, kuki penyegerakan diakses oleh puppetdb. API HTTP dikonfigurasikan di sana: kami meminta perkhidmatan yang kami ada, perkara yang perlu dilakukan. Kemudian mereka membuat permintaan kepada Konsul.
Adakah terdapat integrasi? Ya: mereka menulis peraturan dan membenarkan Permintaan Tarik diterima. Adakah anda memerlukan port tertentu atau menambah hos pada beberapa kumpulan? Permintaan Tarik, semak - tiada lagi "Cari 200 ACL lain dan cuba lakukan sesuatu mengenainya."
Pengoptimuman
Ping localhost dengan rantai peraturan kosong mengambil masa 0,075 ms.
Mari tambahkan 10 alamat iptables pada rantaian ini. Akibatnya, ping akan meningkat 000 kali ganda: iptables adalah linear sepenuhnya, memproses setiap alamat mengambil sedikit masa.
Untuk tembok api tempat kami memindahkan beribu-ribu ACL, kami mempunyai banyak peraturan, dan ini memperkenalkan kependaman. Ini tidak baik untuk protokol permainan.
Tetapi jika kita meletakkan 10 alamat dalam ipset Ping juga akan berkurangan.
Intinya ialah "O" (kerumitan algoritma) untuk ipset sentiasa sama dengan 1, tidak kira berapa banyak peraturan yang ada. Benar, terdapat had - tidak boleh ada lebih daripada 65535 peraturan. Buat masa ini kita hidup dengan ini: anda boleh menggabungkannya, mengembangkannya, membuat dua ipset dalam satu.
Penyimpanan
Kesinambungan logik proses lelaran adalah menyimpan maklumat tentang pelanggan untuk perkhidmatan dalam ipset.
Sekarang kami mempunyai SSH yang sama, dan kami tidak menulis 100 IP sekaligus, tetapi tetapkan nama ipset yang kami perlukan untuk berkomunikasi, dan peraturan berikut DROP. Ia boleh ditukar kepada satu peraturan "Siapa yang tiada di sini, DROP", tetapi ia lebih jelas.
Sekarang kita mempunyai peraturan dan set. Tugas utama adalah membuat set sebelum menulis peraturan, kerana jika tidak iptables tidak akan menulis peraturan.
Skim am
Dalam bentuk rajah, semua yang saya katakan kelihatan seperti ini.
Kami komited dengan Puppet, semuanya dihantar kepada hos, perkhidmatan di sini, ipset sana, dan sesiapa yang tidak berdaftar di sana tidak dibenarkan.
Benarkan & tolak
Untuk menyelamatkan dunia dengan cepat atau melumpuhkan seseorang dengan cepat, pada permulaan semua rantaian kami membuat dua ipset: rules_allow ΠΈ rules_deny. Bagaimana ia berfungsi?
Sebagai contoh, seseorang sedang membuat beban di Web kami dengan bot. Sebelum ini, anda perlu mencari IPnya dari log, bawa ke jurutera rangkaian, supaya mereka dapat mencari sumber trafik dan mengharamkannya. Ia kelihatan berbeza sekarang.
Kami menghantarnya kepada Konsul, tunggu 2,5 saat, dan ia selesai. Memandangkan Konsul mengedarkan dengan cepat melalui P2P, ia berfungsi di mana-mana, di mana-mana bahagian dunia.
Sebaik sahaja saya entah bagaimana berhenti sepenuhnya WOT kerana kesilapan dengan firewall. rules_allow - ini adalah insurans kami terhadap kes sedemikian. Jika kami membuat kesilapan di suatu tempat dengan tembok api, sesuatu disekat di suatu tempat, kami sentiasa boleh menghantar bersyarat 0.0/0untuk cepat mengambil semuanya. Nanti kita baiki semuanya dengan tangan.
Set lain
Anda boleh menambah mana-mana set lain dalam ruang $IPSETS$.
Untuk apa? Kadangkala seseorang memerlukan ipset, sebagai contoh, untuk meniru penutupan beberapa bahagian kluster. Sesiapa sahaja boleh membawa mana-mana set, namakannya, dan mereka akan diambil daripada Konsul. Pada masa yang sama, set boleh sama ada mengambil bahagian dalam peraturan iptables atau bertindak sebagai satu pasukan NOOP: Konsistensi akan dikekalkan oleh daemon.
Ahli
Sebelum ini, ia adalah seperti ini: pengguna disambungkan ke rangkaian dan menerima parameter melalui domain. Sebelum kemunculan tembok api generasi baharu, Cisco tidak tahu bagaimana untuk memahami di mana pengguna berada dan di mana IP berada. Oleh itu, akses diberikan hanya melalui nama hos mesin.
Apa yang kami buat? Kami terperangkap pada masa kami menerima alamat itu. Biasanya ini ialah dot1x, Wi-Fi atau VPN - semuanya melalui RADIUS. Untuk setiap pengguna, kami membuat kumpulan mengikut nama pengguna dan meletakkan IP di dalamnya dengan TTL yang sama dengan dhcp.leasenya - sebaik sahaja ia tamat tempoh, peraturan akan hilang.
Kini kami boleh membuka akses kepada perkhidmatan, seperti kumpulan lain, dengan nama pengguna. Kami telah menghilangkan rasa sakit daripada nama hos apabila ia berubah, dan kami telah mengurangkan beban jurutera rangkaian kerana mereka tidak lagi memerlukan Cisco. Kini jurutera sendiri mendaftarkan akses pada pelayan mereka.
Insulation
Pada masa yang sama, kami mula membongkar penebat. Pengurus perkhidmatan mengambil inventori dan kami menganalisis semua rangkaian kami. Mari bahagikan mereka kepada kumpulan yang sama, dan pada pelayan yang diperlukan kumpulan telah ditambahkan, sebagai contoh, untuk menafikan. Sekarang pengasingan pementasan yang sama berakhir dengan peraturan_penafian pengeluaran, tetapi tidak dalam pengeluaran itu sendiri.
Skim ini berfungsi dengan cepat dan ringkas: kami mengalih keluar semua ACL daripada pelayan, memunggah perkakasan dan mengurangkan bilangan VLAN terpencil.
Kawalan integriti
Sebelum ini, kami mempunyai pencetus khas yang melaporkan apabila seseorang menukar peraturan tembok api secara manual. Saya sedang menulis linter besar untuk menyemak peraturan firewall, ia sukar. Integriti kini dikawal oleh BEFW. Dia bersungguh-sungguh memastikan peraturan yang dibuatnya tidak berubah. Jika seseorang menukar peraturan firewall, ia akan mengubah semuanya kembali. "Saya segera menyediakan proksi supaya saya boleh bekerja dari rumah"βtiada lagi pilihan sedemikian.
BEFW mengawal ipset daripada perkhidmatan dan senaraikan dalam befw.conf, peraturan perkhidmatan dalam rantaian BEFW. Tetapi ia tidak memantau rantaian dan peraturan lain dan ipset lain.
Perlindungan ranap
BEFW sentiasa menyimpan keadaan baik terakhir yang diketahui secara langsung dalam struktur binari state.bin. Jika berlaku kesilapan, ia sentiasa bergolek kembali ke keadaan ini.bin.
Ini adalah insurans terhadap operasi Konsul yang tidak stabil, apabila ia tidak menghantar data atau seseorang membuat kesilapan dan menggunakan peraturan yang tidak boleh digunakan. Untuk memastikan kita tidak dibiarkan tanpa tembok api, BEFW akan kembali ke keadaan terkini jika ralat berlaku pada mana-mana peringkat.
Dalam situasi kritikal, ini adalah jaminan bahawa kita akan dibiarkan dengan tembok api yang berfungsi. Kami membuka semua rangkaian kelabu dengan harapan admin akan datang dan memperbaikinya. Suatu hari nanti saya akan meletakkan ini dalam konfigurasi, tetapi sekarang kita hanya mempunyai tiga rangkaian kelabu: 10/8, 172/12 dan 192.168/16. Dalam Konsul kami, ini adalah ciri penting yang membantu kami mengembangkan lagi.
Demo: semasa laporan, Ivan menunjukkan mod demo BEFW. Lebih mudah untuk menonton demonstrasi . Kod sumber demo tersedia .
Perangkap
Saya akan memberitahu anda tentang pepijat yang kami temui.
ipset add set 0.0.0.0/0. Apakah yang berlaku jika anda menambah 0.0.0.0/0 pada ipset? Adakah semua IP akan ditambah? Adakah akses Internet akan tersedia?
Tidak, kami akan mendapat pepijat yang memerlukan masa henti selama dua jam. Selain itu, pepijat itu tidak berfungsi sejak 2016, ia terletak di RedHat Bugzilla di bawah nombor #1297092, dan kami menemuinya secara tidak sengaja - daripada laporan pembangun.
Ia kini menjadi peraturan ketat di BEFW itu 0.0.0.0/0 bertukar menjadi dua alamat: 0.0.0.0/1 ΠΈ 128.0.0.0/1.
ipset restore set < file. Apakah yang ipset lakukan apabila anda memberitahunya restore? Adakah anda fikir ia berfungsi sama seperti iptables? Adakah ia akan memulihkan data?
Tiada seperti itu - ia menggabungkan, dan alamat lama tidak pergi ke mana-mana, anda tidak menyekat akses.
Kami menemui pepijat semasa menguji pengasingan. Kini terdapat sistem yang agak kompleks - bukannya restore yang diadakan create tempkemudian restore flush temp ΠΈ restore temp. Pada akhir swap: untuk atomicity, kerana jika anda melakukannya dahulu flush dan pada masa ini beberapa paket tiba, ia akan dibuang dan ada sesuatu yang tidak kena. Jadi ada sedikit ilmu hitam di sana.
konsul kv dapatkan -datacenter=lain. Seperti yang saya katakan, kami fikir kami meminta beberapa data, tetapi kami sama ada akan mendapat data atau ralat. Kita boleh melakukan ini melalui Konsul secara tempatan, tetapi dalam kes ini kedua-duanya akan membeku.
Pelanggan Konsul tempatan ialah pembalut pada API HTTP. Tetapi ia hanya tergantung dan tidak bertindak balas kepada Ctrl+C, atau Ctrl+Z, atau apa-apa sahaja, sahaja kill -9 dalam konsol seterusnya. Kami menemui ini semasa kami membina kelompok besar. Tetapi kami belum mempunyai penyelesaian lagi; kami sedang bersedia untuk membetulkan ralat ini di Konsul.
Pemimpin konsul tidak bertindak balas. Tuan kami di pusat data tidak bertindak balas, kami fikir: "Mungkin algoritma pemilihan semula akan berfungsi sekarang?"
Tidak, ia tidak akan berfungsi, dan pemantauan tidak akan menunjukkan apa-apa: Konsul akan mengatakan bahawa terdapat indeks komitmen, seorang pemimpin telah ditemui, semuanya baik-baik saja.
Bagaimana kita menangani perkara ini? service consul restart dalam cron setiap jam. Jika anda mempunyai 50 pelayan, bukan masalah besar. Apabila terdapat 16 daripadanya, anda akan faham bagaimana ia berfungsi.
Kesimpulan
Hasilnya, kami menerima kelebihan berikut:
- liputan 100% untuk semua mesin Linux.
- Kelajuan
- Automasi.
- Kami membebaskan jurutera perkakasan dan rangkaian daripada perhambaan.
- Kemungkinan integrasi telah muncul yang hampir tidak terhad: walaupun dengan Kubernetes, walaupun dengan Ansible, walaupun dengan Python.
Kekurangan: Konsul, yang kini kita perlu hidup, dan kos kesilapan yang sangat tinggi. Sebagai contoh, sekali pada pukul 6 petang (waktu utama di Rusia) saya sedang mengedit sesuatu dalam senarai rangkaian. Kami hanya membina penebat di BEFW pada masa itu. Saya membuat kesilapan di suatu tempat, nampaknya saya menunjukkan topeng yang salah, tetapi semuanya jatuh dalam dua saat. Pemantauan menyala, orang sokongan yang bertugas datang berlari: "Kami mempunyai segala-galanya!" Ketua jabatan menjadi kelabu apabila dia menjelaskan kepada perniagaan mengapa ini berlaku.
Kos kesilapan adalah sangat tinggi sehingga kami telah menghasilkan prosedur pencegahan kompleks kami sendiri. Jika anda melaksanakan ini di tapak pengeluaran yang besar, anda tidak perlu memberikan token induk ke atas Konsul kepada semua orang. Ini akan berakhir dengan teruk.
Kos Saya menulis kod selama 400 jam sahaja. Pasukan saya yang terdiri daripada 4 orang menghabiskan 10 jam sebulan untuk menyokong semua orang. Berbanding dengan harga mana-mana tembok api generasi baharu, ia adalah percuma.
Rancangan. Pelan jangka panjang adalah untuk mencari pengangkutan alternatif untuk menggantikan atau melengkapkan Konsul. Mungkin ia akan menjadi Kafka atau sesuatu yang serupa. Tetapi pada tahun-tahun akan datang kita akan tinggal di Konsul.
Pelan segera: penyepaduan dengan Fail2ban, dengan pemantauan, dengan nftables, mungkin dengan pengedaran lain, metrik, pemantauan lanjutan, pengoptimuman. Sokongan Kubernetes juga ada dalam rancangan, kerana kini kami mempunyai beberapa kluster dan keinginan.
Lagi daripada rancangan:
- mencari anomali dalam lalu lintas;
- pengurusan peta rangkaian;
- Sokongan Kubernetes;
- memasang pakej untuk semua sistem;
- Web-UI.
Kami sentiasa berusaha untuk mengembangkan konfigurasi, meningkatkan metrik dan pengoptimuman.
Sertai projek. Projek itu ternyata hebat, tetapi, malangnya, ia masih projek satu orang. Datang ke dan cuba lakukan sesuatu: beri komitmen, uji, cadangkan sesuatu, berikan penilaian anda.
Sementara itu kami sedang bersiap untuk , yang akan berlangsung pada 6 dan 7 April di St. Petersburg, dan kami menjemput pemaju sistem beban tinggi . Penceramah yang berpengalaman sudah tahu apa yang perlu dilakukan, tetapi bagi mereka yang baru bercakap, kami mengesyorkan sekurang-kurangnya . Menyertai persidangan sebagai penceramah mempunyai beberapa kelebihan. Anda boleh membaca yang mana, sebagai contoh, pada akhir .
Sumber: www.habr.com