Şirket 2010 yılında 50 sunucu ve basit bir ağ modeli vardı: arka uç, ön uç ve güvenlik duvarı. Sunucu sayısı arttı, model daha karmaşık hale geldi: hazırlama, ACL'li izole VLAN'lar, ardından VRF'li VPN'ler, L2'de ACL'li VLAN'lar, L3'te ACL'li VRF'ler. Başın mı dönüyor? Sonrası daha eğlenceli olacak.
16 sunucu olunca bu kadar çok heterojen segmentle gözyaşı dökmeden çalışmak imkansız hale geldi. Bu yüzden başka bir çözüm bulduk. Netfilter yığınını aldık, veri kaynağı olarak Consul'u ekledik ve hızlı dağıtılan bir güvenlik duvarına sahip olduk. Yönlendiricilerdeki ACL'leri değiştirdiler ve bunları harici ve dahili güvenlik duvarı olarak kullandılar. Aracı dinamik olarak yönetmek için, ürün ağına kullanıcı erişimini yönetmekten ağ segmentlerini birbirinden ayırmaya kadar her yerde kullanılan BEFW sistemini geliştirdik.
Size her şeyin nasıl çalıştığını ve neden bu sisteme daha yakından bakmanız gerektiğini anlatacak. Ivan Agarkov () şirketin Minsk geliştirme merkezindeki Bakım bölümünün altyapı güvenlik grubunun başkanıdır. Ivan bir SELinux hayranı, Perl'ü seviyor ve kod yazıyor. Bilgi güvenliği grubunun başkanı olarak Wargaming'i bilgisayar korsanlarından korumak ve şirketteki tüm oyun sunucularının çalışmasını sağlamak için düzenli olarak günlükler, yedeklemeler ve Ar-Ge ile çalışıyor.
Tarihsel bilgi
Bunu nasıl yaptığımızı anlatmadan önce, bu noktaya nasıl geldiğimizi ve buna neden ihtiyaç duyulduğunu anlatacağım. Bunu yapmak için 9 yıl öncesine gidelim: 2010, World of Tanks yeni ortaya çıktı. Wargaming'in yaklaşık 50 sunucusu vardı.
Şirket sunucusu büyüme tablosu.
Bir ağ modelimiz vardı. O zaman için optimaldi.
2010'daki ağ modeli.
Ön tarafta bizi kırmak isteyen kötü adamlar var ama orada bir güvenlik duvarı var. Arka uçta güvenlik duvarı yok ama orada 50 tane sunucu var, hepsini biliyoruz. Her şey iyi çalışıyor.
4 yıl içinde sunucu filosu 100 kat artarak 5000'e çıktı. İlk yalıtılmış ağlar ortaya çıktı - aşamalandırma: üretime geçemediler ve orada genellikle tehlikeli olabilecek şeyler çalışıyordu.
2014'daki ağ modeli.
Atalet nedeniyle aynı donanım parçalarını kullandık ve tüm çalışmalar izole edilmiş VLAN'lar üzerinde gerçekleştirildi: ACL'ler, bir tür bağlantıya izin veren veya reddeden VLAN'lara yazıldı.
2016 yılında sunucu sayısı 8000'e ulaştı, Wargaming diğer stüdyoları bünyesine kattı ve ek ortaklık ağları ortaya çıktı. Bizimmiş gibi görünüyorlar ama tam olarak değil: VLAN çoğu zaman ortaklar için işe yaramıyor, VRF ile VPN kullanmanız gerekiyor, izolasyon daha karmaşık hale geliyor. ACL yalıtım karışımı büyüdü.
2016'daki ağ modeli.
2018 yılı başında makine filosu 16'e çıktı, 000 segment vardı ve finansal verilerin saklandığı kapalı olanlar dahil geri kalanını saymadık. Konteyner ağları (Kubernetes), DevOps, örneğin bir IVS'den VPN aracılığıyla bağlanan bulut ağları ortaya çıktı. Pek çok kural vardı; acı vericiydi.
2018'de ağ modeli ve izolasyon yöntemleri.
Yalıtım için şunları kullandık: L2'de ACL'li VLAN, L3'te ACL'li VRF, VPN ve çok daha fazlası. Çok fazla.
Sorunları
Herkes ACL ve VLAN ile yaşıyor. Sorun nedir? Bu sorunun cevabını acısını gizleyen Harold verecektir.
Pek çok sorun vardı ama beş büyük sorun vardı.
- Yeni kurallar için geometrik fiyat artışı. Her yeni kuralın eklenmesi bir öncekinden daha uzun sürdü çünkü öncelikle böyle bir kuralın olup olmadığını görmek gerekiyordu.
- Segmentlerin içinde güvenlik duvarı yok. Segmentler bir şekilde birbirinden ayrılmıştı ve zaten içeride yeterli kaynak yoktu.
- Kurallar uzun süre uygulandı. Operatörler bir yerel kuralı elle bir saat içinde yazabilirler. Küresel olan birkaç gün sürdü.
- Denetim kurallarındaki zorluklar. Daha doğrusu mümkün değildi. İlk kurallar 2010 yılında yazıldı ve yazarlarının çoğu artık şirkette çalışmıyordu.
- Düşük seviyede altyapı kontrolü. Esas sorun da bu; ülkemizde neler olup bittiğini pek bilmiyorduk.
Bir ağ mühendisi 2018'de şunu duyduğunda böyle görünüyordu: "Biraz daha ACL'ye ihtiyacımız var."
Çözümler
2018 yılının başında bu konuda bir şeyler yapılmasına karar verildi.
Entegrasyonların fiyatı sürekli artıyor. Başlangıç noktası, cihazların belleğinin tükenmesi nedeniyle büyük veri merkezlerinin yalıtılmış VLAN'ları ve ACL'leri desteklemeyi bırakmasıydı.
Çözüm: İnsan faktörünü ortadan kaldırdık ve maksimum erişim sağlamayı otomatik hale getirdik.
Yeni kuralların uygulanması uzun zaman alıyor. Çözüm: Kuralların uygulanmasını hızlandırın, dağıtılmış ve paralel hale getirin. Bu, kuralların rsync veya SFTP olmadan binlerce sisteme kendiliğinden iletilebilmesi için dağıtılmış bir sistem gerektirir.
Segmentlerin içinde güvenlik duvarı yok. Aynı ağ içerisinde farklı servisler ortaya çıkınca segmentler halinde bir güvenlik duvarı bize gelmeye başladı. Çözüm: Ana bilgisayar düzeyinde bir güvenlik duvarı (ana bilgisayar tabanlı güvenlik duvarları) kullanın. Hemen hemen her yerde Linux'umuz var ve her yerde iptables'ımız var, bu bir sorun değil.
Denetim kurallarıyla ilgili zorluklar. Çözüm: Tüm kuralları inceleme ve yönetim için tek bir yerde saklayın, böylece her şeyi denetleyebiliriz.
Altyapı üzerinde düşük düzeyde kontrol. Çözüm: Tüm hizmetlerin ve bunlar arasındaki erişimlerin envanterini çıkarın.
Bu teknik olmaktan çok idari bir süreçtir. Bazen, özellikle promosyonlar ve tatiller sırasında haftada 200-300 yeni yayınımız oluyor. Üstelik bu, DevOps'umuzdan yalnızca bir ekip için geçerlidir. Bu kadar çok sürüm varken hangi bağlantı noktalarına, IP'lere ve entegrasyonlara ihtiyaç duyulduğunu görmek imkansız. Bu nedenle ekiplere şunu soracak özel eğitimli servis yöneticilerine ihtiyacımız vardı: "Bu arada ne var ve bunu neden gündeme getirdiniz?"
Başlattığımız onca şeyden sonra 2019 yılında bir ağ mühendisi böyle görünmeye başladı.
konsolos
Servis yöneticilerinin yardımıyla bulduğumuz her şeyi Consul'a koymaya ve oradan iptables kurallarını yazmaya karar verdik.
Bunu yapmaya nasıl karar verdik?
- Tüm hizmetleri, ağları ve kullanıcıları toplayacağız.
- Bunları temel alarak iptables kuralları oluşturalım.
- Kontrolü otomatikleştiriyoruz.
- ....
- KAR.
Consul uzak bir API değildir, her düğümde çalışabilir ve iptables'a yazabilir. Geriye kalan tek şey gereksiz şeyleri temizleyecek otomatik kontroller bulmaktır ve sorunların çoğu çözülecektir! Gerisini giderken hallederiz.
Neden Konsolos?
Kendini iyi kanıtladı. 2014-15'te bunu Vault için şifreleri sakladığımız bir arka uç olarak kullandık.
Veri kaybetmez. Kullanım süresi boyunca Consul tek bir kazada bile veri kaybı yaşamadı. Bu bir güvenlik duvarı yönetim sistemi için büyük bir artıdır.
P2P bağlantıları değişimin yayılmasını hızlandırır. P2P ile tüm değişiklikler hızlı bir şekilde gerçekleşir, saatlerce beklemeye gerek yoktur.
Kullanışlı REST API. Ayrıca Apache ZooKeeper'ı da düşündük, ancak REST API'si yok, bu yüzden koltuk değneği takmanız gerekecek.
Hem Anahtar Kasası (KV) hem de Dizin (Hizmet Keşfi) olarak çalışır. Hizmetleri, katalogları ve veri merkezlerini aynı anda depolayabilirsiniz. Bu sadece bizim için değil, komşu ekipler için de uygundur, çünkü küresel bir hizmet oluştururken büyük düşünürüz.
Wargaming yığınının bir parçası olan Go'da yazılmıştır. Bu dili seviyoruz, birçok Go geliştiricimiz var.
Güçlü ACL sistemi. Consul'da kimin ne yazdığını kontrol etmek için ACL'leri kullanabilirsiniz. Güvenlik duvarı kurallarının başka hiçbir şeyle çakışmayacağını ve bu konuda sorun yaşamayacağımızı garanti ediyoruz.
Ancak Consul'un dezavantajları da var.
- İşletme sürümünüz olmadığı sürece veri merkezi içinde ölçeklenmez. Yalnızca federasyon tarafından ölçeklenebilir.
- Ağın kalitesine ve sunucu yüküne çok bağlıdır. Ağda düzensiz hız gibi herhangi bir gecikme varsa Consul, yoğun bir sunucuda sunucu olarak düzgün çalışmayacaktır. Bunun nedeni P2P bağlantıları ve güncelleme dağıtım modelleridir.
- Kullanılabilirliği izleme zorluğu. Konsoloslukta her şeyin yolunda olduğunu söyleyebilir ama o çok uzun zaman önce öldü.
Bu sorunların çoğunu Consul'u kullanırken çözdük, bu yüzden onu seçtik. Şirketin alternatif bir arka uç planı var ama biz sorunlarla başa çıkmayı öğrendik ve şu anda Consul'la yaşıyoruz.
Konsolos nasıl çalışır?
Koşullu bir veri merkezine üç ila beş sunucu kuracağız. Bir veya iki sunucu çalışmayacaktır: Veriler eşleşmediğinde yeterli çoğunluğu oluşturamayacak ve kimin haklı kimin haksız olduğuna karar veremeyeceklerdir. Beşten fazlasının hiçbir anlamı yok, üretkenlik düşecek.
İstemciler sunuculara herhangi bir sırayla bağlanır: aynı aracılar, yalnızca bayrakla server = false.
Bundan sonra istemciler P2P bağlantılarının bir listesini alır ve kendi aralarında bağlantılar kurarlar.
Küresel düzeyde birçok veri merkezini birbirine bağlıyoruz. Ayrıca P2P'ye bağlanıp iletişim kurarlar.
Başka bir veri merkezinden veri almak istediğimizde istek sunucudan sunucuya gider. Bu şema denir Serf protokolü. Serf protokolü de Consul gibi HashiCorp tarafından geliştirilmiştir.
Konsolos hakkında bazı önemli gerçekler
Consul'un nasıl çalıştığını açıklayan belgeleri var. Yalnızca bilinmeye değer seçilmiş gerçekleri vereceğim.
Konsolos sunucuları seçmenler arasından bir usta seçiyor. Consul, her veri merkezi için sunucu listesinden bir ana öğe seçer ve sunucu sayısına bakılmaksızın tüm istekler yalnızca ona gider. Ustalığın dondurulması yeniden seçime yol açmaz. Master seçilmezse isteklere kimse tarafından hizmet verilmez.
Yatay ölçeklendirme mi istediniz? Üzgünüm, hayır.
Başka bir veri merkezine yapılan istek, hangi sunucuya geldiğine bakılmaksızın ana bilgisayardan ana bilgisayara gider. Seçilen master, ileri isteklerdeki yük hariç, yükün %100'ünü alır. Veri merkezindeki tüm sunucularda verilerin güncel bir kopyası bulunur ancak yalnızca bir tanesi yanıt verir.
Ölçeklendirmenin tek yolu istemcide eski modu etkinleştirmektir.
Eski modda, çoğunluk olmadan yanıt verebilirsiniz. Bu, veri tutarlılığından vazgeçtiğimiz ancak normalden biraz daha hızlı okuduğumuz ve herhangi bir sunucunun yanıt verdiği bir moddur. Doğal olarak yalnızca master aracılığıyla kayıt yapılıyor.
Konsolos veri merkezleri arasında veri kopyalamaz. Bir federasyon kurulduğunda her sunucunun yalnızca kendi verileri olacaktır. Bazıları için ise daima başka birine yönelir.
İşlemlerin atomikliği bir işlem dışında garanti edilmez. Bir şeyleri değiştirebilecek tek kişinin siz olmadığınızı unutmayın. Farklı istiyorsanız kilitle işlem yapın.
Engelleme işlemleri kilitlemeyi garanti etmez. İstek, doğrudan değil, yöneticiden yöneticiye gider; bu nedenle, örneğin başka bir veri merkezinde engelleme yaptığınızda engellemenin işe yarayacağının garantisi yoktur.
ACL ayrıca erişimi garanti etmez (çoğu durumda). ACL, bir federasyon veri merkezinde - ACL veri merkezinde (Birincil DC) depolandığı için çalışmayabilir. DC size yanıt vermezse ACL çalışmayacaktır.
Donmuş bir usta tüm federasyonun donmasına neden olacak. Örneğin, bir federasyonda 10 veri merkezi var ve birinin ağı kötü, bir ana bilgisayar arızalanıyor. Onunla iletişim kuran herkes bir daire içinde sıkışıp kalacak: Bir istek var, ona cevap yok, konu donuyor. Bunun ne zaman olacağını bilmenin bir yolu yok, yalnızca bir veya iki saat içinde federasyonun tamamı düşecek. Bu konuda yapabileceğin hiçbir şey yok.
Statü, yeter sayı ve seçimler ayrı bir başlıkta ele alınır. Yeniden seçim olmayacak, durum hiçbir şey göstermeyecek. Canlı bir Konsolosunuz olduğunu düşünüyorsunuz, soruyorsunuz ve hiçbir şey olmuyor - cevap yok. Aynı zamanda durum her şeyin yolunda olduğunu gösteriyor.
Bu sorunla karşılaştık ve bundan kaçınmak için veri merkezlerinin belirli bölümlerini yeniden inşa etmek zorunda kaldık.
Consul Enterprise'ın ticari versiyonu yukarıdaki dezavantajların bir kısmına sahip değildir. Pek çok yararlı işlevi vardır: seçmen seçme, dağıtım, ölçeklendirme. Tek bir "ama" var - dağıtılmış bir sistem için lisanslama sistemi çok pahalıdır.
Hayat kesmek: rm -rf /var/lib/consul - Etkenin tüm hastalıklarına çare. Bir şey işinize yaramazsa verilerinizi silin ve verileri bir kopyadan indirin. Büyük olasılıkla Konsolos çalışacaktır.
BEFW
Şimdi Consul'a neler eklediklerimizden bahsedelim.
için bir kısaltmadır BackEndFöfkeWTümü. İlk test taahhütlerini içine koymak için depoyu oluşturduğumda ürüne bir şekilde isim vermem gerekiyordu. Bu isim kaldı.
Kural şablonları
Kurallar iptables sözdiziminde yazılmıştır.
- -N ÖNCE
- -P GİRİŞ DÜŞMESİ
- -A GİRİŞ -m durumu—durum İLGİLİ, KURULU -j KABUL
- -A GİRDİ -i lo -j KABUL
- -A GİRİŞ -j ÖNCE
Her şey BEFW zincirine giriyor, hariç ESTABLISHED, RELATED ve localhost. Şablon herhangi bir şey olabilir, bu sadece bir örnektir.
BEFW nasıl faydalıdır?
Hizmetler
Bir hizmetimiz var, her zaman üzerinde çalıştığı bir bağlantı noktası, bir düğüm var. Düğümümüzden yerel olarak temsilciye sorabilir ve bir tür hizmetimiz olduğunu öğrenebiliriz. Ayrıca etiket de koyabilirsiniz.
Consul'da çalışan ve kayıtlı her hizmet iptables kuralına dönüşür. SSH'miz var - 22 numaralı bağlantı noktasını açın. Bash betiği basittir: curl ve iptables, başka hiçbir şeye gerek yoktur.
istemciler
Herkese değil seçici olarak erişim nasıl açılır? Hizmet adına göre KV depolama alanına IP listeleri ekleyin.
Örneğin onuncu ağdaki herkesin SSH_TCP_22 hizmetine erişebilmesini istiyoruz. Küçük bir TTL alanı eklensin mi? ve artık örneğin bir günlük geçici izinlerimiz var.
Erişimler
Hizmetleri ve müşterileri birbirine bağlıyoruz: bir hizmetimiz var, her biri için KV depolama alanı hazır. Artık herkese değil seçici olarak erişim sağlıyoruz.
Grup
Her seferinde erişim için binlerce IP yazarsak yoruluruz. Gruplandırmaları bulalım - KV'de ayrı bir alt küme. Buna Alias (veya gruplar) adını verelim ve grupları aynı prensibe göre orada saklayalım.
Bağlanalım: Artık SSH'yi özellikle P2P için değil, tüm grup veya birkaç grup için açabiliriz. Aynı şekilde TTL de var; bir gruba ekleyebilir ve gruptan geçici olarak kaldırabilirsiniz.
bütünleşme
Bizim sorunumuz insan faktörü ve otomasyon. Şu ana kadar bu şekilde çözdük.
Puppet ile çalışıyoruz ve sistemle ilgili her şeyi (uygulama kodunu) onlara aktarıyoruz. Puppetdb (normal PostgreSQL), orada çalışan hizmetlerin bir listesini saklar; bunlar kaynak türüne göre bulunabilir. Orada kimin nereye başvurduğunu öğrenebilirsiniz. Bunun için de çekme isteği ve birleştirme isteği sistemimiz var.
Veri aktarımına yardımcı olan basit bir çözüm olan fw-sync'i yazdık. İlk olarak senkronizasyon çerezlerine puppetdb tarafından erişilir. Orada bir HTTP API yapılandırılıyor: Hangi hizmetlere sahip olduğumuzu, ne yapılması gerektiğini talep ediyoruz. Daha sonra Konsolos'a talepte bulunurlar.
Entegrasyon var mı? Evet: kuralları yazdılar ve Çekme İsteklerinin kabul edilmesine izin verdiler. Belirli bir bağlantı noktasına mı ihtiyacınız var veya bir gruba ana bilgisayar mı eklemeniz gerekiyor? Çekme İsteği, inceleme - artık "Diğer 200 ACL bulun ve bu konuda bir şeyler yapmaya çalışın."
Optimizasyon
Boş bir kural zinciriyle localhost'a ping atmak 0,075 ms sürer.
Bu zincire 10 iptables adresi ekleyelim. Sonuç olarak ping 000 kat artacaktır: iptables tamamen doğrusaldır, her adresin işlenmesi biraz zaman alır.
Binlerce ACL'yi taşıdığımız bir güvenlik duvarı için çok sayıda kuralımız var ve bu da gecikmeye neden oluyor. Bu oyun protokolleri için kötüdür.
Ama eğer koyarsak ipset'te 10 adres Ping daha da düşecektir.
Önemli olan şu ki, ipset için "O" (algoritma karmaşıklığı), ne kadar kural olursa olsun her zaman 1'e eşittir. Doğru, bir sınırlama var - 65535'ten fazla kural olamaz Şimdilik bununla yaşıyoruz: bunları birleştirebilir, genişletebilir, bir arada iki ipset oluşturabilirsiniz.
Depolama
Yineleme sürecinin mantıksal bir devamı, hizmete ilişkin istemciler hakkındaki bilgilerin ipset'te saklanmasıdır.
Artık aynı SSH'ye sahibiz ve aynı anda 100 IP yazmıyoruz, iletişim kurmamız gereken ipset'in adını ve aşağıdaki kuralı belirliyoruz DROP. Tek bir kurala dönüştürülebilir: "Kim burada değil, DROP" ama daha net.
Artık kurallarımız ve setlerimiz var. Asıl görev, kuralı yazmadan önce bir set oluşturmaktır, çünkü aksi takdirde iptables kuralı yazmayacaktır.
Genel şema
Diyagram şeklinde söylediğim her şey buna benziyor.
Puppet'a taahhütte bulunuyoruz, her şey ana bilgisayara gönderiliyor, hizmetler burada, ipset orada ve orada kayıtlı olmayan hiç kimsenin girmesine izin verilmiyor.
Reddetmesine izin ver
Dünyayı hızlı bir şekilde kurtarmak veya birini hızlı bir şekilde devre dışı bırakmak için tüm zincirlerin başında iki ipset oluşturduk: rules_allow и rules_deny... Nasıl çalışır?
Mesela birisi Web'imize botlarla yük oluşturuyor. Daha önce, trafiğin kaynağını bulup onu yasaklayabilmeleri için IP'sini günlüklerden bulmanız ve ağ mühendislerine götürmeniz gerekiyordu. Şimdi farklı görünüyor.
Konsolosluğa gönderiyoruz, 2,5 saniye bekliyoruz ve işlem tamam. Consul P2P üzerinden hızlı bir şekilde dağıtım yaptığından dünyanın her yerinde her yerde çalışır.
Bir keresinde güvenlik duvarındaki bir hata nedeniyle WOT'u bir şekilde tamamen durdurdum. rules_allow - bu gibi durumlara karşı sigortamız budur. Güvenlik duvarında bir yerde hata yaptıysak, bir yerde bir şey engellendiyse, her zaman koşullu mesaj gönderebiliriz. 0.0/0her şeyi hızlı bir şekilde almak için. Daha sonra her şeyi elle düzelteceğiz.
Diğer setler
Uzaya başka setler ekleyebilirsiniz $IPSETS$.
Ne için? Bazen birisinin örneğin kümenin bir kısmının kapanmasını taklit etmek için ipset'e ihtiyacı vardır. Herkes istediği seti getirebilir, isimlendirebilir ve bunlar Konsolos'tan teslim alınacaktır. Aynı zamanda setler iptables kurallarına katılabilir veya takım olarak hareket edebilir. NOOP: Tutarlılık arka plan programı tarafından korunacaktır.
Üyeler
Önceden durum şöyleydi: Kullanıcı ağa bağlanıyor ve etki alanı üzerinden parametreler alıyordu. Yeni nesil güvenlik duvarları ortaya çıkmadan önce Cisco, kullanıcının nerede olduğunu ve IP'nin nerede olduğunu nasıl anlayacağını bilmiyordu. Bu nedenle erişime yalnızca makinenin ana bilgisayar adı aracılığıyla izin verildi.
Biz ne yaptık? Adresi aldığımız anda sıkışıp kaldık. Genellikle bu dot1x, Wi-Fi veya VPN'dir - her şey RADIUS üzerinden geçer. Her kullanıcı için, kullanıcı adına göre bir grup oluştururuz ve içine dhcp.lease değerine eşit bir TTL'ye sahip bir IP yerleştiririz - süresi dolduğunda kural kaybolur.
Artık diğer gruplar gibi hizmetlere kullanıcı adına göre erişim açabiliyoruz. Ana bilgisayar adları değiştiğinde sıkıntıyı ortadan kaldırdık ve artık Cisco'ya ihtiyaç duymadıkları için ağ mühendislerinin yükünü de aldık. Artık mühendisler sunucularına erişimi kendileri kaydediyorlar.
Yalıtım
Aynı zamanda izolasyonu da sökmeye başladık. Servis yöneticileri bir envanter çıkardı ve biz de tüm ağlarımızı analiz ettik. Onları aynı gruplara ayıralım ve gerekli sunuculara gruplar eklendi, örneğin reddetmek için. Şimdi aynı sahneleme izolasyonu, yapımın kurallarının reddedilmesinde sona eriyor, ancak yapımın kendisinde değil.
Plan hızlı ve basit bir şekilde çalışıyor: tüm ACL'leri sunuculardan kaldırıyoruz, donanımı kaldırıyoruz ve yalıtılmış VLAN'ların sayısını azaltıyoruz.
Bütünlük kontrolü
Daha önce birisi güvenlik duvarı kuralını manuel olarak değiştirdiğinde bunu bildiren özel bir tetikleyicimiz vardı. Güvenlik duvarı kurallarını kontrol etmek için büyük bir linter yazıyordum, zordu. Bütünlük artık BEFW tarafından kontrol ediliyor. Koyduğu kuralların değişmemesini gayretle sağlar. Birisi güvenlik duvarı kurallarını değiştirirse, bu her şeyi eski haline döndürecektir. "Evden çalışabilmek için hızlı bir şekilde proxy kurdum"; artık bu tür seçenekler yok.
BEFW, hizmetlerden ipset'i ve BEFW zincirindeki hizmetlerin kuralları olan befw.conf'daki listeyi kontrol eder. Ancak diğer zincirleri, kuralları ve diğer ipsetleri izlemez.
Çarpma koruması
BEFW her zaman bilinen son iyi durumu doğrudan state.bin ikili yapısında saklar. Bir şeyler ters giderse, her zaman bu state.bin'e geri döner.
Bu, Consul'ün veri göndermemesi veya birisinin hata yapması ve uygulanamayacak kurallar kullanması durumunda istikrarsız Consul operasyonuna karşı bir sigortadır. Güvenlik duvarı olmadan kalmamamızı sağlamak için, herhangi bir aşamada bir hata oluşması durumunda BEFW en son duruma geri dönecektir.
Kritik durumlarda bu, çalışan bir güvenlik duvarıyla kalacağımızın garantisidir. Yöneticinin gelip düzeltmesi umuduyla tüm gri ağları açıyoruz. Bir gün bunu yapılandırmalara koyacağım ama artık yalnızca üç gri ağımız var: 10/8, 172/12 ve 192.168/16. Konsolosumuz bünyesinde bu, daha da gelişmemize yardımcı olan önemli bir özelliktir.
Demo: Rapor sırasında Ivan, BEFW'nin demo modunu gösteriyor. Gösteriyi izlemek daha kolay . Demo kaynak kodu mevcut .
Tuzaklar
Sizlere karşılaştığımız buglardan bahsedeceğim.
ipset ekleme seti 0.0.0.0/0. İpset'e 0.0.0.0/0 eklerseniz ne olur? Tüm IP'ler eklenecek mi? İnternet erişimi mümkün olacak mı?
Hayır, bize iki saatlik kesintiye mal olacak bir hatayla karşılaşacağız. Üstelik hata 2016'dan beri çalışmıyor, RedHat Bugzilla'da #1297092 numarasıyla bulunuyor ve bunu bir geliştiricinin raporundan tesadüfen bulduk.
Artık BEFW'de katı bir kuraldır: 0.0.0.0/0 iki adrese dönüşür: 0.0.0.0/1 и 128.0.0.0/1.
ipset geri yükleme seti < dosya. ipset'e bunu söylediğinizde ne yapar? restore? İptables ile aynı şekilde çalıştığını mı düşünüyorsunuz? Verileri kurtaracak mı?
Böyle bir şey yok; birleştirme gerçekleşir ve eski adresler hiçbir yere gitmez, erişimi engellemezsiniz.
İzolasyonu test ederken bir hata bulduk. Artık oldukça karmaşık bir sistem var. restore yapılan create tempo zaman restore flush temp и restore temp. Takasın sonunda: atomiklik için, çünkü eğer bunu ilk önce yaparsanız flush ve şu anda bir paket geldiğinde atılacak ve bir şeyler ters gidecek. Yani orada biraz kara büyü var.
consul kv get -datacenter=other. Dediğim gibi bir veri istediğimizi sanıyoruz ama ya veri alacağız ya da hata vereceğiz. Bunu yerel olarak Consul aracılığıyla yapabiliriz ancak bu durumda her ikisi de donacaktır.
Yerel Consul istemcisi, HTTP API'si üzerinde bir sarmalayıcıdır. Ancak kilitleniyor ve yalnızca Ctrl+C'ye veya Ctrl+Z'ye veya herhangi bir şeye yanıt vermiyor kill -9 sonraki konsolda. Büyük bir küme oluştururken bununla karşılaştık. Ama henüz bir çözümümüz yok, Consul’da bu hatayı düzeltmeye hazırlanıyoruz.
Konsolos lideri yanıt vermiyor. Veri merkezindeki ustamız yanıt vermiyor, şöyle düşünüyoruz: "Belki de yeniden seçim algoritması artık işe yarar?"
Hayır, işe yaramayacak ve izleme hiçbir şey göstermeyecek: Konsolos bir bağlılık endeksinin olduğunu, bir liderin bulunduğunu, her şeyin yolunda olduğunu söyleyecek.
Bununla nasıl başa çıkacağız? service consul restart her saat cron cinsinden. 50 sunucunuz varsa sorun değil. 16 adet olunca nasıl çalıştığını anlayacaksınız.
Sonuç
Sonuç olarak aşağıdaki avantajları elde ettik:
- Tüm Linux makinelerinin %100 kapsamı.
- Hız.
- Otomasyon.
- Donanım ve ağ mühendislerini kölelikten kurtardık.
- Neredeyse sınırsız entegrasyon olanakları ortaya çıktı: Kubernetes'le, Ansible'la, Python'la bile.
Eksileri: Artık birlikte yaşamak zorunda olduğumuz konsolos ve hatanın maliyeti çok yüksek. Örnek olarak, akşam 6'da (Rusya'nın prime time'ında) ağ listelerinde bir şeyler düzenliyordum. O zamanlar BEFW'de sadece izolasyon inşa ediyorduk. Bir yerde hata yaptım, yanlış maskeyi işaret etmişim gibi ama iki saniyede her şey düştü. İzleme ışığı yanıyor, görevdeki destek görevlisi koşarak geliyor: "Her şeye sahibiz!" Bölüm başkanı, işletmeye bunun neden olduğunu açıkladığında griye döndü.
Hatanın maliyeti o kadar yüksek ki, kendi karmaşık önleme prosedürümüzü geliştirdik. Eğer bunu büyük bir üretim sahasında uygularsanız, herkese Consul üzerinden master token vermenize gerek kalmaz. Bunun sonu kötü olacak.
Maliyet. Tek başıma 400 saat boyunca kod yazdım. 4 kişilik ekibim ayda 10 saatini herkese destek için harcıyor. Herhangi bir yeni nesil güvenlik duvarının fiyatıyla karşılaştırıldığında ücretsizdir.
Planlar. Uzun vadeli plan, Konsolos'un yerine geçecek veya onu tamamlayacak alternatif ulaşım bulmaktır. Belki Kafka ya da buna benzer bir şey olacaktır. Ama önümüzdeki yıllarda Konsoloslukta yaşayacağız.
Acil planlar: Fail2ban ile entegrasyon, izleme, nftable'lar, muhtemelen diğer dağıtımlar, ölçümler, gelişmiş izleme, optimizasyon ile. Kubernetes desteği de planların bir yerinde çünkü artık birkaç kümemiz ve isteğimiz var.
Planlardan daha fazlası:
- trafikteki anormallikleri aramak;
- ağ haritası yönetimi;
- Kubernetes desteği;
- tüm sistemler için paketlerin birleştirilmesi;
- Web arayüzü.
Yapılandırmayı genişletmek, metrikleri ve optimizasyonu artırmak için sürekli çalışıyoruz.
Projeye katılın. Proje harika çıktı ama maalesef hala tek kişilik bir proje. Gel ve bir şeyler yapmaya çalışın: taahhütte bulunun, test edin, bir şeyler önerin, değerlendirmenizi yapın.
Bu arada biz hazırlanıyoruz 6 ve 7 Nisan'da St. Petersburg'da gerçekleşecek ve yüksek yüklü sistem geliştiricilerini davet ediyoruz . Deneyimli konuşmacılar ne yapmaları gerektiğini zaten biliyor ancak konuşmaya yeni başlayanlar için en azından şunu öneriyoruz: . Konferansa konuşmacı olarak katılmanın birçok avantajı var. Hangileri olduğunu örneğin sonunda okuyabilirsiniz. .
Kaynak: habr.com