کنسول + iptables = :3

در سال 2010 این شرکت بازی جنگی 50 سرور و یک مدل شبکه ساده وجود داشت: Backend، Frontend و Firewall. تعداد سرورها افزایش یافت، مدل پیچیده تر شد: مرحله بندی، VLAN های ایزوله با ACL، سپس VPN با VRF، VLAN با ACL در L2، VRF با ACL در L3. سر در حال چرخش است؟ بعدا سرگرم کننده تر می شود.

وقتی 16 سرور وجود داشت، کار بدون اشک با این همه بخش ناهمگن غیرممکن شد. بنابراین ما به راه حل دیگری رسیدیم. ما پشته Netfilter را گرفتیم، Consul را به عنوان منبع داده به آن اضافه کردیم و یک فایروال سریع توزیع شدیم. آنها ACL ها را در روترها جایگزین کردند و از آنها به عنوان فایروال خارجی و داخلی استفاده کردند. برای مدیریت پویا ابزار، سیستم BEFW را توسعه دادیم که در همه جا مورد استفاده قرار گرفت: از مدیریت دسترسی کاربر به شبکه محصول تا جداسازی بخش‌های شبکه از یکدیگر.

او به شما خواهد گفت که چگونه همه چیز کار می کند و چرا باید نگاه دقیق تری به این سیستم بیندازید. ایوان آگارکوف (annmuor) رئیس گروه امنیت زیرساخت بخش تعمیر و نگهداری در مرکز توسعه مینسک این شرکت است. ایوان یکی از طرفداران SELinux است، عاشق پرل است و کد می نویسد. به عنوان رئیس گروه امنیت اطلاعات، او به طور منظم با لاگ ها، پشتیبان گیری و تحقیق و توسعه برای محافظت از Wargaming در برابر هکرها و اطمینان از عملکرد تمام سرورهای بازی در شرکت کار می کند.

اطلاعات تاریخی

قبل از اینکه به شما بگویم چگونه این کار را انجام دادیم، به شما می گویم که در وهله اول چگونه به این کار رسیدیم و چرا به آن نیاز بود. برای انجام این کار، اجازه دهید به 9 سال قبل برگردیم: 2010، World of Tanks به تازگی ظاهر شد. Wargaming تقریباً 50 سرور داشت.

نمودار رشد سرور شرکت

ما مدل شبکه داشتیم. برای آن زمان بهینه بود.

مدل شبکه در سال 2010.

در قسمت جلو افراد بدی وجود دارند که می خواهند ما را بشکنند، اما دیوار آتش دارد. هیچ فایروال در باطن وجود ندارد، اما 50 سرور در آنجا وجود دارد، ما همه آنها را می شناسیم. همه چیز به خوبی کار می کند.

در 4 سال، ناوگان سرورها 100 برابر افزایش یافت و به 5000 رسید. اولین شبکه های ایزوله ظاهر شدند - صحنه سازی: آنها نمی توانستند به سمت تولید بروند، و اغلب چیزهایی در آنجا در حال اجرا بودند که می توانند خطرناک باشند.

مدل شبکه در سال 2014.

با اینرسی، ما از همان قطعات سخت افزاری استفاده کردیم، و تمام کارها روی VLAN های ایزوله انجام شد: ACL ها روی VLAN ها نوشته می شوند، که نوعی اتصال را مجاز یا رد می کنند.

در سال 2016، تعداد سرورها به 8000 رسید. Wargaming استودیوهای دیگر را جذب کرد و شبکه های وابسته اضافی ظاهر شدند. به نظر می رسد که آنها مال ما هستند، اما نه کاملاً: VLAN اغلب برای شرکا کار نمی کند، شما باید از VPN با VRF استفاده کنید، جداسازی پیچیده تر می شود. مخلوط عایق ACL رشد کرد.

مدل شبکه در سال 2016.

تا ابتدای سال 2018، ناوگان ماشین‌آلات به 16 دستگاه افزایش یافت. 000 بخش وجود داشت و ما بقیه را از جمله موارد بسته که داده‌های مالی در آن ذخیره می‌شد، حساب نکردیم. شبکه های کانتینری (Kubernetes)، DevOps، شبکه های ابری متصل شده از طریق VPN، به عنوان مثال، از یک IVS، ظاهر شده اند. قوانین زیادی وجود داشت - دردناک بود.

مدل شبکه و روش های جداسازی در سال 2018

برای جداسازی از: VLAN با ACL در L2، VRF با ACL در L3، VPN و موارد دیگر استفاده کردیم. خیلی زیاد.

مشکلات

همه با ACL و VLAN زندگی می کنند. مشکل چیه؟ این سوال را هارولد با پنهان کردن درد پاسخ خواهد داد.

مشکلات زیادی وجود داشت، اما پنج مورد بزرگ وجود داشت.

• افزایش قیمت هندسی برای قوانین جدید. اضافه کردن هر قانون جدید بیشتر از قانون قبلی طول می کشد، زیرا ابتدا باید ببینیم که آیا قبلاً چنین قانونی وجود دارد یا خیر.
• بدون فایروال در داخل سگمنت ها. بخش ها به نوعی از یکدیگر جدا شده بودند و منابع کافی در داخل وجود نداشت.
• قوانین برای مدت طولانی اعمال می شد. اپراتورها می توانند یک قانون محلی را در عرض یک ساعت با دست بنویسند. جهانی چند روز طول کشید.
• مشکلات با قوانین حسابرسی. به عبارت دقیق تر، امکان پذیر نبود. اولین قوانین در سال 2010 نوشته شد و بسیاری از نویسندگان آنها دیگر برای شرکت کار نمی کردند.
• سطح پایین کنترل زیرساخت. این مشکل اصلی است - ما به خوبی نمی دانستیم در کشور ما چه می گذرد.

این چیزی است که یک مهندس شبکه در سال 2018 وقتی شنید: "به ACL بیشتری نیاز دارید."

راه حل ها

در ابتدای سال 2018 تصمیم گرفته شد که کاری برای آن انجام شود.

قیمت ادغام ها به طور مداوم در حال رشد است. نقطه شروع این بود که مراکز داده بزرگ از VLAN ها و ACL های ایزوله پشتیبانی نکردند زیرا حافظه دستگاه ها تمام شد.

راه حل: ما عامل انسانی را حذف کردیم و ارائه حداکثر دسترسی را خودکار کردیم.

اعمال قوانین جدید زمان زیادی می برد. راه حل: سرعت بخشیدن به اعمال قوانین، توزیع و موازی آن. این امر مستلزم یک سیستم توزیع شده است تا قوانین بدون rsync یا SFTP به هزار سیستم تحویل داده شوند.

بدون فایروال در داخل سگمنت ها. زمانی که سرویس‌های مختلف در یک شبکه ظاهر شدند، یک فایروال درون بخش‌ها به سراغ ما آمد. راه حل: از فایروال در سطح میزبان استفاده کنید - فایروال های مبتنی بر میزبان. تقریباً در همه جا که لینوکس داریم و هر جا که iptable داریم، این مشکلی نیست.

مشکلات با قوانین حسابرسی راه حل: همه قوانین را برای بررسی و مدیریت در یک مکان نگه دارید تا بتوانیم همه چیز را حسابرسی کنیم.

سطح پایین کنترل بر زیرساخت. راه حل: فهرستی از تمام خدمات و دسترسی های بین آنها تهیه کنید.

این بیشتر یک فرآیند اداری است تا فنی. گاهی اوقات ما 200-300 نسخه جدید در هفته داریم، مخصوصاً در هنگام تبلیغات و تعطیلات. علاوه بر این، این فقط برای یک تیم از DevOps ما است. با نسخه های بسیار زیاد، نمی توان دید به چه پورت ها، IP ها و ادغام هایی نیاز است. بنابراین، ما به مدیران خدمات آموزش دیده ای نیاز داشتیم که از تیم ها بپرسند: "به هر حال چه چیزی وجود دارد و چرا آن را مطرح کردید؟"

بعد از همه چیزهایی که راه اندازی کردیم، یک مهندس شبکه در سال 2019 شروع به اینگونه کرد.

کنسول

ما تصمیم گرفتیم که هر چیزی را که با کمک مدیران خدمات پیدا کردیم در کنسول قرار دهیم و از آنجا قوانین iptables را بنویسیم.

چگونه تصمیم گرفتیم این کار را انجام دهیم؟

• ما تمام خدمات، شبکه ها و کاربران را جمع آوری خواهیم کرد.
• بیایید قوانین iptables را بر اساس آنها ایجاد کنیم.
• ما کنترل را به صورت خودکار انجام می دهیم.
• ....
• سود.

Consul یک API راه دور نیست، می تواند روی هر گره اجرا شود و در iptables بنویسد. تنها چیزی که باقی می ماند این است که با کنترل های خودکار بیایید که چیزهای غیر ضروری را تمیز می کند و بیشتر مشکلات حل می شود! بقیه را در حین حرکت بررسی می کنیم.

چرا کنسول؟

خودش را به خوبی ثابت کرده است. در سال‌های 2014-15، ما از آن به عنوان یک Backend برای Vault استفاده کردیم، که در آن رمزهای عبور را ذخیره می‌کنیم.

داده ها را از دست نمی دهد. در طول زمان استفاده، کنسول اطلاعات را در طول یک تصادف از دست نداد. این یک مزیت بزرگ برای سیستم مدیریت فایروال است.

اتصالات P2P گسترش تغییرات را تسریع می کند. با P2P، همه تغییرات به سرعت انجام می شود، بدون نیاز به ساعت ها صبر کردن.

API راحت REST. ما همچنین Apache ZooKeeper را در نظر گرفتیم، اما API REST ندارد، بنابراین باید عصا را نصب کنید.

هم به عنوان یک صندوق کلید (KV) و هم به عنوان دایرکتوری (کشف سرویس) کار می کند.. می توانید خدمات، کاتالوگ ها و مراکز داده را به طور همزمان ذخیره کنید. این نه تنها برای ما، بلکه برای تیم های همسایه نیز راحت است، زیرا هنگام ساخت یک سرویس جهانی، ما بزرگ فکر می کنیم.

نوشته شده در Go، که بخشی از پشته Wargaming است. ما عاشق این زبان هستیم، توسعه دهندگان Go زیادی داریم.

سیستم قدرتمند ACL در Consul، می توانید از ACL برای کنترل اینکه چه کسی چه چیزی می نویسد استفاده کنید. ما تضمین می کنیم که قوانین فایروال با هیچ چیز دیگری همپوشانی نخواهد داشت و در این مورد مشکلی نخواهیم داشت.

اما کنسول معایبی هم دارد.

• در مرکز داده مقیاس نمی شود مگر اینکه نسخه تجاری داشته باشید. فقط توسط فدراسیون مقیاس پذیر است.
• بسیار به کیفیت شبکه و بار سرور بستگی دارد. اگر لگ هایی در شبکه وجود داشته باشد، مثلاً سرعت نامناسب، کنسول به عنوان یک سرور روی سرور شلوغ به درستی کار نمی کند. این به دلیل اتصالات P2P و مدل های توزیع به روز است.
• مشکل نظارت بر در دسترس بودن. در وضعیت کنسولی او می تواند بگوید که همه چیز خوب است، اما او مدت ها پیش درگذشت.

ما اکثر این مشکلات را با استفاده از Consul حل کردیم و به همین دلیل آن را انتخاب کردیم. این شرکت برنامه هایی برای یک باطن جایگزین دارد، اما ما یاد گرفته ایم که با مشکلات کنار بیاییم و در حال حاضر با کنسول زندگی می کنیم.

نحوه کار کنسول

ما سه تا پنج سرور را در یک مرکز داده مشروط نصب خواهیم کرد. یک یا دو سرور کار نخواهند کرد: آنها نمی توانند حد نصاب را سازماندهی کنند و تصمیم بگیرند که چه کسی درست است و چه کسی اشتباه می کند وقتی داده ها مطابقت ندارند. بیش از پنج معنی ندارد، بهره وری کاهش می یابد.

مشتریان به هر ترتیبی به سرورها متصل می شوند: همان عوامل، فقط با پرچم server = false.

پس از این، مشتریان لیستی از اتصالات P2P را دریافت می کنند و بین خود اتصال ایجاد می کنند.

در سطح جهانی، ما چندین مرکز داده را به هم متصل می کنیم. آنها همچنین P2P را متصل می کنند و ارتباط برقرار می کنند.

وقتی می خواهیم داده ها را از مرکز داده دیگری بازیابی کنیم، درخواست از سروری به سرور دیگر می رود. این طرح نامیده می شود پروتکل سرف. پروتکل Serf نیز مانند Consul توسط HashiCorp توسعه یافته است.

چند نکته مهم در مورد کنسول

کنسول مدارکی دارد که نحوه عملکرد آن را توضیح می دهد. من فقط حقایق برگزیده ای را ارائه خواهم داد که ارزش دانستن دارند.

سرورهای کنسول یک استاد را از میان رای دهندگان انتخاب می کنند. کنسول یک استاد را از لیست سرورها برای هر مرکز داده انتخاب می کند و تمام درخواست ها صرف نظر از تعداد سرورها فقط به آن می رود. انجماد استاد منجر به انتخاب مجدد نمی شود. اگر مستر انتخاب نشود، درخواست‌ها توسط کسی سرویس نمی‌شوند.

آیا مقیاس افقی می خواستید؟ متاسفم، نه

درخواست به مرکز داده دیگر، صرف نظر از اینکه به کدام سرور رسیده است، از اصلی به اصلی دیگر می رود. استاد انتخاب شده 100٪ بار را دریافت می کند، به جز بار در درخواست های فوروارد. همه سرورها در مرکز داده یک نسخه به روز از داده ها دارند، اما فقط یکی پاسخ می دهد.

تنها راه برای مقیاس، فعال کردن حالت بیات روی مشتری است.

در حالت بیات، می توانید بدون حد نصاب پاسخ دهید. این حالتی است که در آن از ثبات داده صرف نظر می کنیم، اما کمی سریعتر از حد معمول می خوانیم و هر سروری پاسخ می دهد. به طور طبیعی، ضبط فقط از طریق استاد.

کنسول داده ها را بین مراکز داده کپی نمی کند. هنگامی که یک فدراسیون مونتاژ می شود، هر سرور فقط داده های خود را خواهد داشت. برای دیگران، او همیشه به شخص دیگری روی می آورد.

اتمی بودن عملیات خارج از یک معامله تضمین نمی شود. به یاد داشته باشید که شما تنها کسی نیستید که می توانید اوضاع را تغییر دهید. اگر شما آن را متفاوت می خواهید، یک معامله با یک قفل انجام دهید.

عملیات مسدود کردن قفل را تضمین نمی کند. درخواست از Master به Master می رود، و نه مستقیم، بنابراین هیچ تضمینی وجود ندارد که وقتی مسدود می کنید، به عنوان مثال، در مرکز داده دیگری، مسدود کردن کار می کند.

ACL همچنین دسترسی را تضمین نمی کند (در بسیاری از موارد). ACL ممکن است کار نکند زیرا در یک مرکز داده فدراسیون - در مرکز داده ACL (DC اولیه) ذخیره می شود. اگر DC به شما پاسخ ندهد، ACL کار نخواهد کرد.

یک استاد فریز باعث یخ زدن کل فدراسیون می شود. مثلاً در یک فدراسیون 10 مرکز داده وجود دارد که یکی شبکه بدی دارد و یکی مستر از کار می افتد. هر کسی که با او ارتباط برقرار می کند در یک دایره گیر می کند: یک درخواست وجود دارد، هیچ پاسخی برای آن وجود ندارد، موضوع یخ می زند. هیچ راهی وجود ندارد که بدانیم چه زمانی این اتفاق می افتد، فقط یکی دو ساعت دیگر کل فدراسیون سقوط می کند. هیچ کاری نمی توانید در مورد آن انجام دهید.

وضعیت، حد نصاب و انتخابات توسط یک موضوع جداگانه بررسی می شود. انتخاب مجدد اتفاق نخواهد افتاد، وضعیت چیزی نشان نخواهد داد. شما فکر می کنید که یک کنسول زنده دارید، می پرسید، و هیچ اتفاقی نمی افتد - هیچ پاسخی وجود ندارد. در عین حال، وضعیت نشان می دهد که همه چیز خوب است.

ما با این مشکل مواجه شده‌ایم و مجبور شدیم بخش‌های خاصی از مراکز داده را بازسازی کنیم تا از آن جلوگیری کنیم.

نسخه تجاری Consul Enterprise برخی از معایب بالا را ندارد. این کارکردهای مفید بسیاری دارد: انتخاب رأی دهندگان، توزیع، مقیاس بندی. تنها یک "اما" وجود دارد - سیستم صدور مجوز برای یک سیستم توزیع شده بسیار گران است.

هک زندگی: rm -rf /var/lib/consul - درمان تمام بیماری های عامل. اگر چیزی برای شما کار نمی کند، فقط داده های خود را حذف کنید و داده ها را از یک نسخه دانلود کنید. به احتمال زیاد کنسول کار خواهد کرد.

BEFW

حالا بیایید در مورد آنچه به کنسول اضافه کرده ایم صحبت کنیم.

BEFW مخفف است BACKEndFخشمWهمه. وقتی مخزن را ایجاد کردم مجبور شدم محصول را به نحوی نام ببرم تا اولین تعهدات آزمایشی را در آن قرار دهم. این نام باقی می ماند.

الگوهای قوانین

قوانین در نحو iptables نوشته شده است.

• -N BEFW
• -P INPUT DROP
• -A INPUT -m حالت—حالت RELATED,ESTABLISHED -j ACCEPT
• -A INPUT -i lo -j ACCEPT
• -A INPUT -j BEFW

همه چیز به زنجیره BEFW می رود، به جز ESTABLISHED, RELATED و لوکال هاست قالب می تواند هر چیزی باشد، این فقط یک مثال است.

BEFW چگونه مفید است؟

خدمات

ما یک سرویس داریم، همیشه یک پورت دارد، یک گره که روی آن اجرا می شود. از گره خود می توانیم به صورت محلی از نماینده بپرسیم و متوجه شویم که نوعی سرویس داریم. شما همچنین می توانید برچسب ها را قرار دهید.

هر سرویسی که در حال اجرا و ثبت در کنسول باشد به قانون iptables تبدیل می شود. ما SSH داریم - پورت 22 باز است. اسکریپت Bash ساده است: curl و iptables، هیچ چیز دیگری لازم نیست.

مشتریان

چگونه دسترسی را نه برای همه، بلکه به صورت انتخابی باز کنیم؟ لیست های IP را با نام سرویس به ذخیره سازی KV اضافه کنید.

به عنوان مثال، ما می خواهیم همه افراد در شبکه دهم بتوانند به سرویس SSH_TCP_22 دسترسی داشته باشند. یک فیلد کوچک TTL اضافه کنید؟ و الان مجوزهای موقت مثلاً یک روزه داریم.

دسترسی ها

ما خدمات و مشتریان را به هم متصل می کنیم: ما یک سرویس داریم، ذخیره سازی KV برای هر کدام آماده است. اکنون ما دسترسی را نه به همه، بلکه به صورت انتخابی می دهیم.

گروه

اگر هر بار هزاران آی پی برای دسترسی بنویسیم، خسته می شویم. بیایید با گروه بندی ها بیاییم - یک زیر مجموعه جداگانه در KV. بیایید آن را مستعار (یا گروه ها) بنامیم و گروه ها را طبق همان اصل در آنجا ذخیره کنیم.

بیایید وصل شویم: اکنون می توانیم SSH را نه به طور خاص برای P2P، بلکه برای یک گروه کامل یا چندین گروه باز کنیم. به همین ترتیب، TTL وجود دارد - می توانید به یک گروه اضافه کنید و به طور موقت از گروه حذف کنید.

ادغام

مشکل ما عامل انسانی و اتوماسیون است. تا الان اینجوری حلش کردیم

ما با Puppet کار می کنیم و هر چیزی که به سیستم (کد برنامه) مربوط می شود را به آنها منتقل می کنیم. Puppetdb (PostgreSQL معمولی) لیستی از سرویس هایی را که در آنجا اجرا می شوند ذخیره می کند، آنها را می توان بر اساس نوع منبع پیدا کرد. در آنجا می توانید بفهمید چه کسی کجا درخواست می دهد. ما همچنین یک سیستم درخواست کشش و ادغام برای این کار داریم.

ما befw-sync را نوشتیم، یک راه حل ساده که به انتقال داده ها کمک می کند. ابتدا، کوکی‌های همگام‌سازی توسط puppetdb قابل دسترسی هستند. یک HTTP API در آنجا پیکربندی شده است: ما درخواست می‌کنیم که چه خدماتی داریم، چه کارهایی باید انجام شود. سپس از کنسول درخواست می کنند.

آیا ادغام وجود دارد؟ بله: آنها قوانین را نوشتند و اجازه دادند درخواست های کششی پذیرفته شود. آیا به پورت خاصی نیاز دارید یا میزبانی را به گروهی اضافه کنید؟ درخواست بکشید، بررسی کنید - دیگر نه "200 ACL دیگر پیدا کنید و سعی کنید کاری در مورد آن انجام دهید."

بهینه سازی

پینگ کردن لوکال هاست با یک زنجیره قانون خالی 0,075 میلی ثانیه طول می کشد.

بیایید 10 آدرس iptable را به این زنجیره اضافه کنیم. در نتیجه، پینگ 000 برابر افزایش می یابد: iptables کاملاً خطی است، پردازش هر آدرس مدتی طول می کشد.

برای یک فایروال که در آن هزاران ACL را مهاجرت می کنیم، قوانین زیادی داریم و این باعث ایجاد تاخیر می شود. این برای پروتکل های بازی بد است.

اما اگر قرار دهیم 10 آدرس در ipset پینگ حتی کاهش می یابد.

نکته این است که "O" (پیچیدگی الگوریتم) برای ipset همیشه برابر با 1 است، مهم نیست که چند قانون وجود دارد. درست است، یک محدودیت وجود دارد - نمی تواند بیش از 65535 قانون وجود داشته باشد. در حال حاضر ما با این زندگی می کنیم: می توانید آنها را ترکیب کنید، آنها را گسترش دهید، دو ipset را در یک بسازید.

ذخیره سازی

ادامه منطقی فرآیند تکرار، ذخیره اطلاعات مربوط به مشتریان برای سرویس در ipset است.

حالا ما همان SSH را داریم و 100 IP را همزمان نمی نویسیم، بلکه نام ipset را که باید با آن ارتباط برقرار کنیم و قانون زیر را تنظیم می کنیم. DROP. می توان آن را به یک قانون تبدیل کرد "چه کسی اینجا نیست، رها کنید"، اما واضح تر است.

حالا ما قوانین و مجموعه هایی داریم. وظیفه اصلی این است که قبل از نوشتن قانون یک مجموعه بسازید، زیرا در غیر این صورت iptables قانون را نمی نویسد.

طرح کلی

به صورت نمودار هرچی گفتم اینجوریه.

ما به Puppet متعهد می شویم، همه چیز برای هاست ارسال می شود، سرویس ها در اینجا، ipset در آنجا و هرکسی که در آنجا ثبت نام نکرده باشد مجاز نیست.

اجازه و رد

برای نجات سریع دنیا یا غیرفعال کردن سریع کسی، در ابتدای همه زنجیره‌ها دو آیپست ساختیم: rules_allow и rules_deny. چگونه کار می کند؟

به عنوان مثال، شخصی در حال ایجاد یک بار در وب ما با ربات ها است. قبلا باید IP او را از لاگ ها پیدا می کردید، آن را به مهندسان شبکه می بردید تا منبع ترافیک را پیدا کنند و او را تحریم کنند. الان متفاوت به نظر می رسد.

ما آن را برای کنسول می فرستیم، 2,5 ثانیه صبر می کنیم و کار تمام می شود. از آنجایی که Consul به سرعت از طریق P2P توزیع می کند، در همه جا و در هر نقطه از جهان کار می کند.

یک بار به دلیل اشتباه با فایروال، WOT را کاملا متوقف کردم. rules_allow - این بیمه ما در برابر چنین مواردی است. اگر در جایی با فایروال اشتباه کردیم، چیزی در جایی مسدود شده است، همیشه می توانیم یک مشروط ارسال کنیم. 0.0/0تا به سرعت همه چیز را جمع آوری کند. بعداً همه چیز را با دست درست می کنیم.

مجموعه های دیگر

می توانید هر مجموعه دیگری را در فضا اضافه کنید $IPSETS$.

برای چی؟ گاهی اوقات شخصی به ipset نیاز دارد، برای مثال، برای شبیه سازی خاموش شدن بخشی از خوشه. هرکسی می‌تواند هر مجموعه‌ای را بیاورد، نامش را بگذارد و از کنسول گرفته می‌شود. در همان زمان، ست ها می توانند در قوانین iptables شرکت کنند یا به عنوان یک تیم عمل کنند NOOP: ثبات توسط دیمون حفظ خواهد شد.

کاربران

قبلاً به این صورت بود: کاربر به شبکه متصل شد و پارامترها را از طریق دامنه دریافت کرد. قبل از ظهور فایروال‌های نسل جدید، سیسکو نمی‌دانست چگونه بفهمد کاربر کجاست و IP کجاست. بنابراین، دسترسی فقط از طریق نام میزبان دستگاه اعطا شد.

چه کار کردیم؟ در لحظه دریافت آدرس گیر کردیم. معمولاً این dot1x، Wi-Fi یا VPN است - همه چیز از طریق RADIUS می گذرد. برای هر کاربر، یک گروه با نام کاربری ایجاد می کنیم و یک IP با یک TTL برابر با dhcp.lease آن در آن قرار می دهیم - به محض اینکه منقضی شود، قانون از بین می رود.

اکنون می توانیم دسترسی به سرویس ها را مانند سایر گروه ها با نام کاربری باز کنیم. ما دردسر را از نام هاست‌ها در هنگام تغییر برداشته‌ایم و بار مهندسین شبکه را برداشته‌ایم زیرا آنها دیگر نیازی به سیسکو ندارند. اکنون خود مهندسان دسترسی به سرورهای خود را ثبت می کنند.

عایق

در همان زمان، ما شروع به از بین بردن عایق کردیم. مدیران خدمات یک موجودی تهیه کردند و ما تمام شبکه های خود را تجزیه و تحلیل کردیم. بیایید آنها را به همان گروه ها تقسیم کنیم و در سرورهای لازم گروه ها اضافه شدند، مثلاً برای رد کردن. حالا همان انزوای صحنه‌سازی به قوانین_انکار تولید ختم می‌شود، اما نه در خود تولید.

این طرح به سرعت و به سادگی کار می کند: ما تمام ACL ها را از سرورها حذف می کنیم، سخت افزار را تخلیه می کنیم و تعداد VLAN های ایزوله را کاهش می دهیم.

کنترل یکپارچگی

پیش از این، ما یک راه‌انداز ویژه داشتیم که زمانی را گزارش می‌داد که فردی یک قانون فایروال را به صورت دستی تغییر می‌داد. من داشتم یک لنگر بزرگ برای بررسی قوانین فایروال می نوشتم، سخت بود. یکپارچگی اکنون توسط BEFW کنترل می شود. او با غیرت تضمین می کند که قوانینی که وضع می کند تغییر نکنند. اگر کسی قوانین فایروال را تغییر دهد، همه چیز را دوباره تغییر خواهد داد. "من به سرعت یک پروکسی راه اندازی کردم تا بتوانم از خانه کار کنم" - دیگر چنین گزینه هایی وجود ندارد.

BEFW ipset را از سرویس ها و لیست موجود در befw.conf، قوانین خدمات در زنجیره BEFW، کنترل می کند. اما سایر زنجیره ها و قوانین و سایر ipset ها را زیر نظر نمی گیرد.

حفاظت در برابر تصادف

BEFW همیشه آخرین وضعیت خوب شناخته شده را مستقیماً در ساختار باینری state.bin ذخیره می کند. اگر مشکلی پیش بیاید، همیشه به این state.bin برمی‌گردد.

این بیمه در برابر عملیات ناپایدار کنسول است، زمانی که داده ها را ارسال نکرد یا شخصی اشتباه کرد و از قوانینی استفاده کرد که قابل اعمال نیستند. برای اطمینان از اینکه ما بدون فایروال نمی مانیم، اگر در هر مرحله خطایی رخ دهد BEFW به آخرین وضعیت برمی گردد.

در شرایط بحرانی، این تضمینی است که ما با یک فایروال در حال کار باقی خواهیم ماند. همه شبکه های خاکستری را باز می کنیم به امید اینکه ادمین بیاید و درستش کند. روزی این را در تنظیمات قرار خواهم داد، اما اکنون ما فقط سه شبکه خاکستری داریم: 10/8، 172/12 و 192.168/16. در کنسول ما، این یک ویژگی مهم است که به ما کمک می کند تا بیشتر پیشرفت کنیم.

دمو: در طول گزارش، ایوان حالت دمو BEFW را نشان می دهد. تماشای تظاهرات آسان تر است تصویری. کد منبع نسخه ی نمایشی موجود است در GitHub.

مشکلات

من به شما در مورد اشکالاتی که با آنها برخورد کردیم می گویم.

ipset add set 0.0.0.0/0. اگر 0.0.0.0/0 را به ipset اضافه کنید چه اتفاقی می افتد؟ آیا همه IP ها اضافه می شوند؟ آیا دسترسی به اینترنت در دسترس خواهد بود؟

نه، ما با یک اشکال مواجه خواهیم شد که برای ما دو ساعت از کار افتادن هزینه دارد. علاوه بر این، این باگ از سال 2016 کار نکرده است، در RedHat Bugzilla با شماره #1297092 قرار دارد، و ما آن را به طور تصادفی پیدا کردیم - از گزارش یک توسعه دهنده.

اکنون این یک قانون سختگیرانه در BEFW است که 0.0.0.0/0 تبدیل به دو آدرس می شود: 0.0.0.0/1 и 128.0.0.0/1.

ipset restore set < فایل. وقتی ipset بهش میگی چیکار میکنه restore? به نظر شما مانند iptables کار می کند؟ آیا اطلاعات را بازیابی می کند؟

هیچ چیز مشابهی وجود ندارد - ادغام می شود، و آدرس های قدیمی به جایی نمی رسند، دسترسی را مسدود نمی کنید.

هنگام آزمایش جداسازی، یک اشکال پیدا کردیم. اکنون یک سیستم نسبتاً پیچیده وجود دارد - به جای آن restore برگزار شد create tempسپس restore flush temp и restore temp. در پایان مبادله: برای اتمی بودن، زیرا اگر ابتدا آن را انجام دهید flush و در این لحظه بسته ای می رسد، دور انداخته می شود و مشکلی پیش می آید. بنابراین کمی جادوی سیاه در آنجا وجود دارد.

کنسول kv get -datacenter=other. همانطور که گفتم، ما فکر می کنیم که مقداری داده می خواهیم، ​​اما یا داده می گیریم یا خطا. ما می توانیم این کار را از طریق کنسول محلی انجام دهیم، اما در این صورت هر دو مسدود می شوند.

مشتری Consul محلی یک پوشش بر روی HTTP API است. اما فقط هنگ می کند و به Ctrl+C یا Ctrl+Z یا هر چیز دیگری پاسخ نمی دهد، فقط kill -9 در کنسول بعدی زمانی که در حال ساختن یک خوشه بزرگ بودیم با آن مواجه شدیم. اما ما هنوز راه حلی نداریم؛ ما در حال آماده شدن برای رفع این خطا در کنسول هستیم.

رهبر کنسول پاسخی نمی دهد. استاد ما در مرکز داده پاسخ نمی دهد، ما فکر می کنیم: "شاید الگوریتم انتخاب مجدد اکنون کار کند؟"

نه، کار نخواهد کرد، و نظارت چیزی را نشان نخواهد داد: کنسول خواهد گفت که یک شاخص تعهد وجود دارد، یک رهبر پیدا شده است، همه چیز خوب است.

چگونه با این موضوع کنار بیاییم؟ service consul restart در کرون هر ساعت اگر 50 سرور دارید، مشکلی نیست. وقتی تعداد آنها 16 باشد، متوجه خواهید شد که چگونه کار می کند.

نتیجه

در نتیجه، ما مزایای زیر را دریافت کردیم:

• پوشش 100% تمامی ماشین های لینوکس.
• سرعت
• اتوماسیون.
• ما مهندسان سخت افزار و شبکه را از بردگی آزاد کردیم.
• امکانات یکپارچه سازی ظاهر شده است که تقریباً نامحدود است: حتی با Kubernetes، حتی با Ansible، حتی با Python.

منفی: کنسولی که الان باید باهاش ​​زندگی کنیم و هزینه بسیار بالای خطا. به عنوان مثال، یک بار در ساعت 6 بعد از ظهر (زمان اصلی روسیه) در حال ویرایش چیزی در لیست شبکه ها بودم. ما در آن زمان فقط در BEFW مشغول ساخت عایق بودیم. من یک جایی اشتباه کردم، به نظر می رسد که ماسک اشتباهی را نشان داده ام، اما همه چیز در دو ثانیه سقوط کرد. مانیتور روشن می شود، فرد پشتیبانی که در حال انجام وظیفه است می دود: "ما همه چیز داریم!" رئیس بخش وقتی به شرکت توضیح داد که چرا این اتفاق افتاده است خاکستری شد.

هزینه خطا آنقدر زیاد است که ما روش پیچیده پیشگیری خود را ارائه کرده ایم. اگر این را در یک سایت تولیدی بزرگ پیاده‌سازی می‌کنید، نیازی نیست که یک توکن اصلی برای کنسول به همه بدهید. این پایان بدی خواهد داشت.

هزینه 400 ساعت به تنهایی کد نوشتم. تیم 4 نفره من 10 ساعت در ماه را صرف پشتیبانی از همه می کند. در مقایسه با قیمت هر فایروال نسل جدید، رایگان است.

طرح ها. برنامه بلندمدت یافتن حمل و نقل جایگزین برای جایگزینی یا تکمیل کنسول است. شاید کافکا یا چیزی شبیه آن باشد. اما در سال های آینده ما روی کنسول زندگی خواهیم کرد.

برنامه های فوری: ادغام با Fail2ban، با نظارت، با nftables، احتمالاً با سایر توزیع ها، معیارها، نظارت پیشرفته، بهینه سازی. پشتیبانی Kubernetes نیز جایی در برنامه است، زیرا اکنون ما چندین خوشه و تمایل داریم.

اطلاعات بیشتر از طرح ها:

• جستجوی ناهنجاری در ترافیک؛
• مدیریت نقشه شبکه؛
• پشتیبانی Kubernetes؛
• مونتاژ بسته ها برای همه سیستم ها؛
• Web-UI.

ما دائماً روی گسترش پیکربندی، افزایش معیارها و بهینه سازی کار می کنیم.

به پروژه بپیوندید. این پروژه عالی بود، اما، متاسفانه، هنوز یک پروژه یک نفره است. آمدن به GitHub و سعی کنید کاری انجام دهید: متعهد شوید، آزمایش کنید، چیزی پیشنهاد کنید، ارزیابی خود را ارائه دهید.

در ضمن ما در حال آماده شدن برای Saint HighLoad++که در تاریخ 6 و 7 آوریل در سن پترزبورگ برگزار می شود و از توسعه دهندگان سیستم های بار بالا دعوت می کنیم. درخواست گزارش. سخنرانان باتجربه از قبل می دانند چه کاری باید انجام دهند، اما برای کسانی که تازه صحبت می کنند حداقل توصیه می کنیم تلاش كردن. شرکت در کنفرانس به عنوان سخنران مزایای زیادی دارد. می تونید مثلا در آخر کدوم رو بخونید از این مقاله.

منبع: www.habr.com