په 2010 کې د شرکت دلته 50 سرورونه او د شبکې ساده ماډل شتون درلود: بیکینډ، فرنټ اینڈ او فائر وال. د سرورونو شمیر ډیر شو، ماډل ډیر پیچلی شو: سټینګ، د ACLs سره جلا شوي VLANs، بیا د VRFs سره VPNs، په L2 کې ACLs سره VLANs، په L3 کې ACLs سره VRFs. سر خوځیږي؟ دا به وروسته ډیر په زړه پوري وي.
کله چې 16 سرورونه شتون درلود، نو د ډیرو متفاوت برخو سره د اوښکو پرته کار کول ناممکن شول. نو موږ د بل حل سره راغلو. موږ د نیټ فلټر سټیک واخیست ، د ډیټا سرچینې په توګه دې ته قونسل اضافه کړ ، او موږ ګړندی توزیع شوی فایر وال ترلاسه کړ. دوی په روټرونو کې ACLs ځای په ځای کړل او دوی یې د بهرني او داخلي فائر وال په توګه وکارول. د وسیلې په متحرک ډول اداره کولو لپاره ، موږ د BEFW سیسټم رامینځته کړ ، کوم چې هرچیرې کارول کیده: د محصول شبکې ته د کارونکي لاسرسي اداره کولو څخه د شبکې برخې له یو بل څخه جلا کولو پورې.
هغه به تاسو ته ووایي چې دا ټول څنګه کار کوي او ولې تاسو باید دې سیسټم ته نږدې کتنه وکړئ. ایوان اګارکوف () د شرکت د مینسک پراختیایي مرکز کې د ساتنې برخې د زیربنا امنیت ګروپ مشر دی. ایوان د SELinux فین دی، پرل سره مینه لري، او کوډ لیکي. د معلوماتو امنیت ګروپ مشر په توګه، هغه په منظمه توګه د لاګ، بیک اپ او R&D سره کار کوي ترڅو وارګیمینګ د هیکرانو څخه خوندي کړي او په شرکت کې د ټولو لوبو سرورونو عملیات یقیني کړي.
تاریخي پس منظر
مخکې لدې چې زه تاسو ته ووایم چې موږ دا څنګه ترسره کړل، زه به تاسو ته ووایم چې موږ څنګه په لومړي ځای کې دې ته راغلو او ولې ورته اړتیا وه. د دې کولو لپاره، راځئ چې 9 کاله شاته لاړ شو: 2010، د ټانکونو نړۍ یوازې ښکاره شوه. وارګیمینګ شاوخوا 50 سرورونه درلودل.
د شرکت سرور وده چارټ.
موږ د شبکې ماډل درلود. د هغه وخت لپاره دا غوره وه.
د شبکې ماډل په 2010 کې.
په لومړي سر کې بد هلکان شتون لري چې غواړي موږ مات کړي، مګر دا د اور وژنې وال لري. په شاته کې هیڅ فایر وال شتون نلري ، مګر دلته 50 سرورونه شتون لري ، موږ دا ټول پیژنو. هر څه ښه کار کوي.
په 4 کلونو کې، د سرور بیړۍ 100 ځله، 5000 ته وده ورکړه. لومړی جلا جلا شبکې ښکاره شوې - سټینګ: دوی نشي کولی تولید ته لاړ شي، او ډیری وختونه هلته داسې شیان روان وو چې خطرناک کیدی شي.
د شبکې ماډل په 2014 کې.
د انارشیا په واسطه، موږ د هارډویر ورته ټوټې کارولې، او ټول کارونه په جلا VLANs کې ترسره شوي: ACLs VLANs ته لیکل شوي، کوم چې یو ډول ارتباط ته اجازه ورکوي یا ردوي.
په 2016 کې، د سرورونو شمیر 8000 ته ورسید. Wargaming نورې سټوډیوګانې جذب کړې، او اضافي وابسته شبکې راڅرګندې شوې. داسې ښکاري چې دوی زموږ دي، مګر په کافي اندازه نه: VLAN اکثرا د شریکانو لپاره کار نه کوي، تاسو باید د VRF سره VPN وکاروئ، جلا کول خورا پیچلي کیږي. د ACL موصلیت مخلوط وده وکړه.
د شبکې ماډل په 2016 کې.
د 2018 په پیل کې، د ماشینونو بیړۍ 16 ته وده کړې. 000 برخې وې، او موږ پاتې برخه نه شمیرو، په شمول د تړل شویو توکو په شمول چې مالي معلومات ذخیره شوي. د کانټینر شبکې (Kubernetes)، DevOps، د بادل شبکې د VPN له لارې وصل شوي، د بیلګې په توګه، د IVS څخه، ښکاره شوي. ډیری قواعد شتون درلود - دا دردناک و.
په 2018 کې د شبکې ماډل او د جلا کولو میتودونه.
د انزوا لپاره موږ وکاروو: VLAN په L2 کې ACL سره، VRF په L3 کې ACL سره، VPN او نور ډیر څه. خورا ډیر.
ستونزې
هرڅوک د ACL او VLAN سره ژوند کوي. څه ستونزه ده؟ دا پوښتنه به د هارولډ لخوا ځواب شي، درد پټوي.
ستونزې ډېرې وې، خو پنځه لویې وې.
- د نوي مقرراتو لپاره د جیومیټریک نرخ زیاتوالی. هر نوی قاعده د تیر په پرتله اضافه کولو لپاره ډیر وخت نیسي، ځکه چې دا اړینه وه چې لومړی وګورئ چې آیا دا ډول قاعده لا دمخه شتون لري.
- د برخو دننه هیڅ فایر وال نشته. برخې په یو څه ډول له یو بل څخه جلا شوې وې، او دننه کافي سرچینې شتون نلري.
- قواعد د اوږدې مودې لپاره پلي شوي. آپریټران کولی شي په یو ساعت کې د لاس په واسطه یو محلي قاعده ولیکي. نړیوال څو ورځې ونیولې.
- د پلټنې قواعدو سره ستونزې. ډیر دقیق، دا ممکنه نه وه. لومړی قواعد په 2010 کې بیرته لیکل شوي، او د دوی ډیری لیکوالان نور د شرکت لپاره کار نه کوي.
- د زیربنا کنټرول ټیټه کچه. دا اصلي ستونزه ده - موږ نه پوهیږو چې زموږ په هیواد کې څه تیریږي.
دا هغه څه دي چې د شبکې انجینر په 2018 کې ورته ښکاري کله چې هغه اوریدلي: "یو څه نور ACL ته اړتیا لرئ."
حلونه
د 2018 په پیل کې، پریکړه وشوه چې د دې په اړه یو څه وکړي.
د ادغام قیمت په دوامداره توګه وده کوي. د پیل ټکی دا و چې لوی ډیټا مرکزونو د جلا شوي VLANs او ACLs ملاتړ بند کړ ځکه چې وسایل له حافظې څخه وتلي.
حل: موږ انساني فاکتور لرې کړ او اعظمي حد ته د لاسرسي چمتو کول مو اتومات کړل.
نوي مقررات د پلي کیدو لپاره ډیر وخت نیسي. حل: د مقرراتو پلي کول ګړندي کړئ ، دا توزیع او موازي کړئ. دا یو توزیع شوي سیسټم ته اړتیا لري ترڅو مقررات پخپله تحویل شي، پرته له rsync یا SFTP څخه زرو سیسټمونو ته.
د برخو دننه هیڅ فایر وال نشته. په برخو کې د اور وژونکي موږ ته راغلل کله چې مختلف خدمات په ورته شبکه کې څرګند شول. حل: د کوربه په کچه د فائر وال وکاروئ - د کوربه میشته فایر وال. نږدې هرچیرې موږ لینکس لرو، او هرچیرې چې موږ iptables لرو، دا کومه ستونزه نده.
د پلټنې قواعدو سره ستونزې. حل: ټول قواعد د بیاکتنې او مدیریت لپاره په یو ځای کې وساتئ، نو موږ کولی شو هرڅه پلټنه وکړو.
په زیربنا باندې د کنټرول ټیټه کچه. حل: د دوی تر مینځ د ټولو خدماتو او لاسرسي لیست واخلئ.
دا د تخنیکي پروسې څخه ډیر اداري پروسه ده. ځینې وختونه موږ په اونۍ کې 200-300 نوي ریلیزونه لرو، په ځانګړې توګه د ترویجونو او رخصتیو په جریان کې. سربیره پردې ، دا یوازې زموږ د DevOps یوې ډلې لپاره دی. د ډیری ریلیزونو سره، دا ناشونې ده چې وګورئ کوم بندرونه، IPs، او ادغام ته اړتیا ده. له همدې امله، موږ د ځانګړو روزل شویو خدماتو مدیرانو ته اړتیا درلوده چې د ټیمونو څخه یې وپوښتل: "په هرصورت دلته څه دي او ولې یې راوړي؟"
د هرڅه وروسته چې موږ یې پیل کړ، په 2019 کې د شبکې انجنیر داسې ښکاري.
قونسل
موږ پریکړه وکړه چې موږ به هر هغه څه چې د خدماتو مدیرانو په مرسته مو موندلي قونسل ته وسپارو او له هغه ځایه به د iptables قواعد ولیکئ.
موږ څنګه پریکړه وکړه چې دا کار وکړو؟
- موږ به ټول خدمات، شبکې او کاروونکي راټول کړو.
- راځئ چې د دوی پر بنسټ د iptables قواعد رامینځته کړو.
- موږ کنټرول اتومات کوو.
- ....
- ګټه.
قونسل یو ریموټ API نه دی، دا کولی شي په هر نوډ کې وګرځي او iptables ته ولیکي. ټول هغه څه چې پاتې دي د اتوماتیک کنټرولونو سره راځي چې غیر ضروري شیان پاکوي، او ډیری ستونزې به حل شي! موږ به پاتې کار وکړو لکه څنګه چې موږ ځو.
ولې قونسل؟
ځان ښه ثابت کړی دی. په 2014-15 کې، موږ دا د والټ لپاره د شالید په توګه کارولی، په کوم کې چې موږ پاسورډونه ذخیره کوو.
ډاټا له لاسه نه ورکوي. د کارولو په وخت کې، قونسل د یوې حادثې په جریان کې ډاټا له لاسه نه ورکوي. دا د اور وژنې مدیریت سیسټم لپاره لوی پلس دی.
د P2P اړیکې د بدلون خپریدل ګړندي کوي. د P2P سره، ټول بدلونونه په چټکۍ سره راځي، د ساعتونو انتظار ته اړتیا نشته.
مناسب REST API. موږ د اپاچي زوکیپر هم په پام کې نیولی، مګر دا د REST API نلري، نو تاسو باید کرچونه نصب کړئ.
د کلیدي والټ (KV) او لارښود (د خدماتو کشف) په توګه کار کوي. تاسو کولی شئ په یوځل کې خدمات ، کتلاګ او د معلوماتو مرکزونه ذخیره کړئ. دا نه یوازې زموږ لپاره ، بلکه د ګاونډیو ټیمونو لپاره هم اسانه دی ، ځکه چې کله د نړیوال خدمت رامینځته کول ، موږ لوی فکر کوو.
په Go کې لیکل شوی، کوم چې د وارګیمینګ سټیک برخه ده. موږ د دې ژبې سره مینه لرو، موږ ډیری Go پراختیا کونکي لرو.
د ځواکمن ACL سیسټم. په قونسل کې، تاسو کولی شئ ACLs وکاروئ ترڅو کنټرول کړئ چې څوک څه لیکي. موږ تضمین کوو چې د اور وژونکي مقررات به د بل څه سره نه تیریږي او موږ به پدې کې ستونزې ونه لرو.
مګر قونسل هم خپل نیمګړتیاوې لري.
- د ډیټا مرکز کې اندازه نه کوي پرته لدې چې تاسو د سوداګرۍ نسخه ولرئ. دا یوازې د فدراسیون لخوا د توزیع وړ دی.
- د شبکې کیفیت او د سرور بار خورا پورې اړه لري. قونسل به په مصروف سرور کې د سرور په توګه په سمه توګه کار ونکړي که چیرې په شبکه کې کوم ځنډ شتون ولري، د بیلګې په توګه، غیر مساوي سرعت. دا د P2P ارتباطاتو او د توزیع ماډلونو تازه کولو له امله دی.
- د شتون څارنه ستونزمنه ده. د قونسل په حالت کې هغه کولی شي ووایي چې هرڅه سم دي، مګر هغه ډیر وخت مخکې مړ شو.
موږ د قونسل په کارولو سره ډیری دا ستونزې حل کړې، له همدې امله موږ دا غوره کړه. شرکت د بدیل پس منظر لپاره پلانونه لري، مګر موږ د ستونزو سره معامله کول زده کړل او اوس د قونسل سره ژوند کوو.
قونسل څنګه کار کوي
موږ به په مشروط ډیټا مرکز کې له دریو څخه تر پنځو سرورونو نصب کړو. یو یا دوه سرورونه به کار ونکړي: دوی به ونشي کولی چې کورم تنظیم کړي او پریکړه وکړي چې څوک سم دي او څوک غلط دي کله چې ډاټا سره سمون نه خوري. له پنځو څخه ډیر هیڅ معنی نلري، تولید به راټیټ شي.
پیرودونکي په هر ترتیب کې سرورونو سره وصل کیږي: ورته اجنټان ، یوازې د بیرغ سره server = false.
له دې وروسته، پیرودونکي د P2P اړیکو لیست ترلاسه کوي او په خپل منځ کې اړیکې رامینځته کوي.
په نړیواله کچه، موږ ډیری ډیټا مرکزونه وصل کوو. دوی هم د P2P سره نښلوي او اړیکه لري.
کله چې موږ غواړو د بل ډیټا مرکز څخه ډاټا بیرته ترلاسه کړو، غوښتنه له سرور څخه سرور ته ځي. دا سکیم ویل کیږي د خدمت پروتوکول. د سیرف پروتوکول، لکه قونسل، د HashiCorp لخوا رامینځته شوی.
د کونسلګرۍ په اړه ځینې مهم حقایق
قونسل اسناد لري چې دا تشریح کوي چې دا څنګه کار کوي. زه به یوازې غوره حقایق وړاندې کړم چې د پوهیدو وړ دي.
د قونسل سرورونه د رایه ورکوونکو څخه یو ماسټر غوره کوي. قونسل د هر ډیټا مرکز لپاره د سرورونو لیست څخه ماسټر غوره کوي ، او ټولې غوښتنې یوازې دې ته ځي ، پرته لدې چې د سرورونو شمیر په پام کې ونیول شي. د ماسټر کنګل کول د بیا ټاکنو لامل نه کیږي. که ماسټر نه وي ټاکل شوی، غوښتنې د چا لخوا نه خدمت کیږي.
ایا تاسو افقی اندازه کول غواړئ؟ بخښنه غواړم، نه.
د بل ډیټا مرکز ته غوښتنه له ماسټر څخه ماسټر ته ځي ، پرته لدې چې کوم سرور ته راشي. ټاکل شوی ماسټر 100٪ بار ترلاسه کوي، پرته له دې چې د مخکینیو غوښتنو بار بار وي. د معلوماتو په مرکز کې ټول سرورونه د معلوماتو تازه کاپي لري، مګر یوازې یو ځواب ورکوي.
د اندازه کولو یوازینۍ لار په پیرودونکي کې د سټیل حالت فعالول دي.
په زاړه حالت کې، تاسو کولی شئ پرته له کورم ځواب ورکړئ. دا یو حالت دی په کوم کې چې موږ د ډیټا ثبات پریږدو، مګر د معمول په پرتله یو څه چټک لوستل، او کوم سرور ځواب ورکوي. په طبیعي توګه، یوازې د ماسټر له لارې ثبت کول.
قونسل د معلوماتو مرکزونو ترمنځ ډاټا کاپي نه کوي. کله چې یو فدراسیون راټول شي، هر سرور به یوازې خپل معلومات ولري. د نورو لپاره، هغه تل د بل چا سره مخ کیږي.
د عملیاتو اتومیت د لیږد څخه بهر تضمین ندی. په یاد ولرئ چې تاسو یوازینی څوک نه یاست چې شیان بدلولی شئ. که تاسو دا په بل ډول غواړئ، د تالاشۍ سره معامله ترسره کړئ.
د بندولو عملیات د تالاشۍ تضمین نه کوي. غوښتنه له ماسټر څخه ماسټر ته ځي ، او مستقیم نه ، نو هیڅ تضمین شتون نلري چې بلاک کول به کار وکړي کله چې تاسو بلاک کړئ ، د مثال په توګه ، په بل ډیټا مرکز کې.
ACL هم د لاسرسي تضمین نه کوي (په ډیری مواردو کې). ACL ممکن کار ونکړي ځکه چې دا په یو فدراسیون ډیټا مرکز کې زیرمه شوی - د ACL ډیټا مرکز (لومړني DC) کې. که چیرې DC تاسو ته ځواب ونه وايي، ACL به کار ونکړي.
یو منجمد ماسټر به د ټول فدراسیون کنګل کیدو لامل شي. د مثال په توګه، په یو فدراسیون کې 10 د معلوماتو مرکزونه شتون لري، او یو یې خراب شبکه لري، او یو ماسټر ناکام دی. هرڅوک چې له هغه سره اړیکه ونیسي په یوه حلقه کې ودرول شي: یوه غوښتنه شتون لري، هیڅ ځواب نشته، تار کنګل کیږي. هیڅ لاره نشته چې پوه شي چې دا به کله پیښ شي ، یوازې په یو یا دوه ساعتونو کې به ټول فدراسیون سقوط وکړي. هیڅ شی نشته چې تاسو یې په اړه څه کولی شئ.
وضعیت، نصاب او ټاکنې د جلا تار په واسطه اداره کیږي. بیا ټاکنې به نه کیږي، دریځ به هیڅ ونه ښیې. تاسو فکر کوئ چې تاسو یو ژوندی قونسل لرئ، تاسو پوښتنه کوئ، او هیڅ شی نه کیږي - هیڅ ځواب نشته. په ورته وخت کې، وضعیت ښیي چې هرڅه سم دي.
موږ د دې ستونزې سره مخ شوي یو او باید د دې څخه مخنیوي لپاره د ډیټا مرکزونو ځانګړي برخې بیا جوړ کړو.
د قونسل تصدۍ سوداګرۍ نسخه پورته ځینې زیانونه نلري. دا ډیری ګټورې دندې لري: د رایې ورکوونکو انتخاب، ویش، اندازه کول. یوازې یو "مګر" شتون لري - د ویشل شوي سیسټم لپاره د جواز ورکولو سیسټم خورا ګران دی.
د ژوند هیکنگ: rm -rf /var/lib/consul - د ایجنټ د ټولو ناروغیو درملنه. که یو څه ستاسو لپاره کار نه کوي، یوازې خپل ډاټا حذف کړئ او د کاپي څخه ډاټا ډاونلوډ کړئ. ډیری احتمال، قونسل به کار وکړي.
BEFW
اوس راځئ چې د هغه څه په اړه وغږیږو چې موږ قونسل ته اضافه کړي دي.
لپاره لنډیز دی BackEndFدWټول ما باید په یو ډول محصول نوم ورکړم کله چې ما ذخیره جوړه کړه ترڅو لومړی ازموینې ژمنې پکې واچوم. دا نوم پاتې دی.
د قواعدو ټیمپلیټونه
قواعد په iptables ترکیب کې لیکل شوي.
- -N BEFW
- -P INPUT DROP
- - د داخلیدو یو ریاست— دولت پورې اړوند، تاسیس شوی - j منل
- -یو داخلیدنه -i lo -j ومنی
- -A INPUT -j BEFW
هرڅه د BEFW سلسله ته ځي، پرته له دې ESTABLISHED, RELATED او localhost. ټیمپلیټ هر څه کیدی شي، دا یوازې یو مثال دی.
BEFW څنګه ګټور دی؟
خدمتونه
موږ یو خدمت لرو، دا تل یو بندر لري، یو نوډ چې دا پرمخ ځي. زموږ د نوډ څخه، موږ کولی شو په محلي توګه د اجنټ څخه پوښتنه وکړو او معلومه کړو چې موږ یو ډول خدمت لرو. تاسو کولی شئ ټګونه هم واچوئ.
هر هغه خدمت چې روان وي او د قونسل سره راجستر وي د iptables په قاعده بدلیږي. موږ SSH لرو - خلاص پورټ 22. د بش سکریپټ ساده دی: curl او iptables، بل هیڅ شی ته اړتیا نشته.
مراجعین
څنګه د هرچا لپاره لاسرسی خلاص کړئ، مګر په انتخابي ډول؟ IP لیستونه د KV ذخیره کې د خدمت نوم سره اضافه کړئ.
د مثال په توګه، موږ غواړو چې په لسمه شبکه کې هرڅوک د SSH_TCP_22 خدمت ته د لاسرسي وړ وي. یو کوچنی TTL ساحه اضافه کړئ؟ او اوس موږ لنډمهاله جوازونه لرو، د بیلګې په توګه، د یوې ورځې لپاره.
لاسرسی
موږ خدمتونه او پیرودونکي وصل کوو: موږ یو خدمت لرو، د KV ذخیره د هر یو لپاره چمتو ده. اوس موږ ټولو ته لاسرسی نه ورکوو، مګر په انتخابي ډول.
ډلې
که موږ هر وخت د لاسرسي لپاره زرګونه IPs ولیکئ ، نو موږ به ستړي شو. راځئ چې د ګروپونو سره راشو - په KV کې یو جلا فرعي سیټ. راځئ چې دې ته الیاس (یا ډلې) ووایو او د ورته اصولو سره سم هلته ډلې ذخیره کړو.
راځئ چې وصل کړو: اوس موږ کولی شو SSH خلاص کړو په ځانګړي ډول د P2P لپاره نه ، مګر د ټولې ډلې یا څو ډلو لپاره. په ورته ډول، TTL شتون لري - تاسو کولی شئ یوې ډلې ته اضافه کړئ او په لنډمهاله توګه له ډلې څخه لرې کړئ.
ادغام
زموږ ستونزه انساني فکتور او اتومات دی. تر دې دمه موږ دا په دې ډول حل کړی دی.
موږ د پوپټ سره کار کوو، او هر هغه څه چې د سیسټم سره تړاو لري (د غوښتنلیک کوډ) دوی ته لیږدوو. Puppetdb (منظم PostgreSQL) د خدماتو لیست ذخیره کوي چې هلته روان دي، دوی د سرچینې ډول لخوا موندل کیدی شي. هلته تاسو کولی شئ معلومه کړئ چې څوک چیرته درخواست کوي. موږ د دې لپاره د پلې غوښتنې او ادغام غوښتنې سیسټم هم لرو.
موږ befw-sync لیکلي، یو ساده حل چې د معلوماتو لیږد کې مرسته کوي. لومړی، د ترکیب کوکیز د puppetdb لخوا لاسرسی کیږي. یو HTTP API هلته ترتیب شوی دی: موږ غوښتنه کوو چې کوم خدمتونه لرو، څه باید ترسره شي. بیا دوی قونسل ته غوښتنه کوي.
ایا ادغام شتون لري؟ هو: دوی مقررات لیکلي او اجازه یې ورکړې چې د غوښتنې غوښتنې ومنل شي. ایا تاسو یو ځانګړي بندر ته اړتیا لرئ یا ځینې ډلې ته کوربه اضافه کړئ؟ غوښتنه وکړئ، بیاکتنه وکړئ - نور نه "200 نور ACLs ومومئ او د دې په اړه یو څه کولو هڅه وکړئ."
اصلاح کول
د خالي قاعدې سلسلې سره د محلي هوسټ پینګ کول 0,075 ms اخلي.
راځئ چې دې سلسلې ته 10 iptables پتې اضافه کړو. د پایلې په توګه، پینګ به 000 ځله زیات شي: iptables په بشپړ ډول خطي دي، د هرې پتې پروسس کول یو څه وخت نیسي.
د اور وژنې لپاره چیرې چې موږ په زرګونو ACLs مهاجرت کوو، موږ ډیری مقررات لرو، او دا ځنډ معرفي کوي. دا د لوبو پروتوکولونو لپاره خراب دی.
مګر که موږ واچوو په ipset کې 10 پتې پینګ به حتی کم شي.
ټکی دا دی چې د ipset لپاره "O" (الګوریتم پیچلتیا) تل د 1 سره مساوي وي، پرته له دې چې څومره قواعد شتون ولري. ریښتیا، یو محدودیت شتون لري - د 65535 څخه ډیر قواعد شتون نلري، د اوس لپاره موږ د دې سره ژوند کوو: تاسو کولی شئ دوی یوځای کړئ، پراخ کړئ، په یو کې دوه ipsets جوړ کړئ.
زیرمه
د تکرار پروسې منطقي دوام په ipset کې د خدماتو لپاره د پیرودونکو په اړه معلومات ذخیره کول دي.
اوس موږ ورته SSH لرو، او موږ په یو وخت کې 100 IPs نه لیکو، مګر د هغه ipset نوم ټاکو چې موږ ورسره اړیکه ونیسو، او لاندې قاعده DROP. دا په یوه قاعده کې بدل کیدی شي "څوک دلته نه دی، DROP"، مګر دا ډیر روښانه دی.
اوس موږ مقررات او مقررات لرو. اصلي دنده دا ده چې د قاعدې لیکلو دمخه سیټ جوړ کړئ ، ځکه چې که نه نو iptables به قاعده ونه لیکي.
عمومي سکیم
د ډیاګرام په بڼه، هر څه چې ما وویل داسې ښکاري.
موږ ګوډاګی ته ژمن یو، هرڅه کوربه ته لیږل کیږي، دلته خدمتونه، هلته ipset، او هرڅوک چې هلته راجستر شوي ندي اجازه نلري.
اجازه ورکړئ او رد کړئ
د نړۍ ګړندي خوندي کولو یا یو څوک ژر غیر فعال کولو لپاره ، د ټولو زنځیرونو په پیل کې موږ دوه ipsets جوړ کړل: rules_allow и rules_deny. څنګه کار کوي؟
د مثال په توګه، یو څوک زموږ په ویب کې د بوټونو سره بار جوړوي. مخکې، تاسو باید د هغه IP د لاګونو څخه ومومئ، د شبکې انجنیرانو ته یې واخلئ، ترڅو دوی د ټرافیک سرچینه ومومي او هغه یې منع کړي. دا اوس مختلف ښکاري.
موږ دا قونسل ته لیږو، 2,5 ثانیې انتظار وکړئ، او دا کار وشو. څرنګه چې قونسل د P2P له لارې په چټکۍ سره توزیع کوي، دا د نړۍ په هره برخه کې هرچیرې کار کوي.
یوځل چې ما یو څه په بشپړ ډول د فایر وال سره د غلطۍ له امله WOT بند کړ. rules_allow - دا د داسې قضیو په وړاندې زموږ بیمه ده. که موږ د فایر وال سره کوم ځای کې غلطي کړې وي، یو څه بل ځای بند شوی وي، موږ کولی شو تل یو مشروط واستوو 0.0/0ژر تر ژره هرڅه پورته کړئ. وروسته به موږ هر څه د لاس په واسطه تنظیم کړو.
نور سیټونه
تاسو کولی شئ په خلا کې نور سیټونه اضافه کړئ $IPSETS$.
د څه لپاره؟ ځینې وختونه یو څوک ipset ته اړتیا لري، د بیلګې په توګه، د کلستر ځینې برخې بندول تقلید کول. هر څوک کولی شي هر ډول سیټونه راوړي، نوم یې واخلي، او دوی به د قونسل څخه اخیستل کیږي. په ورته وخت کې، سیټونه کولی شي د iptables په قواعدو کې برخه واخلي یا د ټیم په توګه عمل وکړي NOOP: ثبات به د ډیمون لخوا ساتل کیږي.
کارونکي
پخوا، دا د دې په څیر و: کاروونکي د شبکې سره وصل او د ډومین له لارې پیرامیټونه ترلاسه کړل. د نوي نسل فایروالونو له راتګ دمخه، سیسکو نه پوهیده چې څنګه پوه شي چې کاروونکي چیرته و او IP چیرته و. له همدې امله، لاسرسی یوازې د ماشین کوربه نوم له لارې ورکړل شوی و.
موږ څه وکړل؟ موږ په داسې حال کې ودرېد چې پته مو ترلاسه کړه. معمولا دا dot1x، Wi-Fi یا VPN دی - هرڅه د RADIUS له لارې تیریږي. د هر کارونکي لپاره، موږ د کارن-نوم په واسطه یوه ډله جوړه کوو او په هغې کې د TTL سره یو IP ځای په ځای کوو چې د هغې dhcp.lease سره مساوي وي - هرڅومره ژر چې دا پای ته ورسیږي، قانون به ورک شي.
اوس موږ کولی شو خدماتو ته لاسرسی خلاص کړو، لکه د نورو ډلو په څیر، د کارن نوم په واسطه. موږ د کوربه نومونو څخه درد لرې کړی کله چې دوی بدل شي ، او موږ د شبکې انجینرانو څخه بار لرې کړی ځکه چې دوی نور سیسکو ته اړتیا نلري. اوس انجینران پخپله په خپلو سرورونو کې لاسرسی ثبتوي.
موصلیت
په ورته وخت کې، موږ د موصلیت له مینځه وړلو پیل وکړ. د خدماتو مدیرانو لیست اخیستی، او موږ زموږ ټولې شبکې تحلیل کړې. راځئ چې دوی په ورته ګروپونو وویشو، او په اړین سرورونو کې ډلې اضافه شوي، د بیلګې په توګه، رد کول. اوس د ورته مرحلې جلا کول د تولید په قواعدو کې پای ته رسیږي، مګر پخپله تولید کې نه.
سکیم ګړندی او په ساده ډول کار کوي: موږ ټول ACLs له سرورونو لرې کوو ، هارډویر پورته کوو ، او د جلا شوي VLANs شمیر کموو.
د بشپړتیا کنټرول
مخکې، موږ یو ځانګړی محرک درلود چې راپور یې ورکړ کله چې یو څوک په لاسي ډول د فایروال قواعد بدل کړي. ما د اور وژنې مقرراتو چک کولو لپاره یو لوی لینټر لیکلی و، دا ستونزمن و. بشپړتیا اوس د BEFW لخوا کنټرول کیږي. هغه په زور سره ډاډ ترلاسه کوي چې هغه مقررات چې هغه جوړوي بدلون نه کوي. که څوک د فایروال قواعد بدل کړي، دا به هرڅه بیرته بدل کړي. "ما په چټکۍ سره یو پراکسي جوړه کړه ترڅو زه د کور څخه کار وکړم" - نور داسې اختیارونه شتون نلري.
BEFW د خدماتو څخه ipset کنټرولوي او په befw.conf کې لیست کوي، د BEFW سلسله کې د خدماتو قواعد. مګر دا د نورو زنځیرونو او قواعدو او نورو ipsets څارنه نه کوي.
د حادثې محافظت
BEFW تل وروستی پیژندل شوی ښه حالت مستقیم په state.bin بائنری جوړښت کې ذخیره کوي. که یو څه غلط شي، دا تل بیرته دې حالت ته ځي.
دا د بې ثباته قونسلګرۍ عملیاتو پروړاندې بیمه ده ، کله چې دا معلومات ندي لیږلي یا یو څوک غلطي کړې او مقررات یې کارولي چې نشي پلي کیدی. د دې لپاره چې ډاډ ترلاسه شي چې موږ د فایر وال پرته نه پریږدو، BEFW به بیرته وروستي حالت ته وګرځي که چیرې په هره مرحله کې کومه تېروتنه رامنځته شي.
په نازکو حالاتو کې، دا یو تضمین دی چې موږ به د کاري فائر وال سره پاتې شو. موږ ټول خړ شبکې په دې هیله پرانیزو چې مدیر به راشي او سم به یې کړي. یوه ورځ به زه دا په تشکیلاتو کې واچوم ، مګر اوس موږ یوازې درې خړ شبکې لرو: 10/8، 172/12 او 192.168/16. زموږ د قونسلګرۍ دننه، دا یو مهم خصوصیت دی چې موږ سره مرسته کوي نور پرمختګ وکړي.
ډیمو: د راپور په جریان کې ، ایوان د BEFW ډیمو حالت ښیې. د مظاهرې لیدل اسانه دي . د ډیمو سرچینې کوډ شتون لري .
نخشه
زه به تاسو ته د هغه غلطیو په اړه ووایم چې موږ ورسره مخ شوي یو.
ipset اضافه کړئ سیټ 0.0.0.0/0. څه پیښیږي که تاسو 0.0.0.0/0 ipset ته اضافه کړئ؟ ایا ټول IPs به اضافه شي؟ ایا انټرنیټ ته لاسرسی به شتون ولري؟
نه، موږ به یو بګ ترلاسه کړو چې موږ ته دوه ساعته ځنډ وخت مصرفوي. سربیره پردې، بګ د 2016 راهیسې کار نه دی کړی، دا په RedHat Bugzilla کې د #1297092 شمیرې لاندې موقعیت لري، او موږ دا په ناڅاپي ډول وموندل - د پراختیا کونکي راپور څخه.
دا اوس په BEFW کې یو سخت قانون دی 0.0.0.0/0 په دوه ادرس بدلیږي: 0.0.0.0/1 и 128.0.0.0/1.
د ipset بیا رغونه سیټ < فایل. ipset څه کوي کله چې تاسو ورته ووایاست restore؟ ایا تاسو فکر کوئ چې دا د iptables په څیر کار کوي؟ ایا دا به ډاټا بیرته ترلاسه کړي؟
د دې په څیر هیڅ شی نه دی - دا یوځای کوي، او زاړه پتې هیڅ ځای ته نه ځي، تاسو لاسرسی بند نه کړئ.
موږ یو بګ وموندلو کله چې د انزوا معاینه کوو. اوس دلته یو پیچلی سیسټم شتون لري - پرځای یې restore نیول شوی create tempبیا restore flush temp и restore temp. د تبادلې په پای کې: د اتومیت لپاره، ځکه چې که تاسو دا لومړی کوئ flush او په دې وخت کې یو پیکټ راځي، دا به رد شي او یو څه به غلط شي. نو هلته یو څه تور جادو شتون لري.
قونسل kv get -datacenter=نور. لکه څنګه چې ما وویل، موږ فکر کوو چې موږ د ځینې معلوماتو غوښتنه کوو، مګر موږ به یا هم ډاټا یا تېروتنه ترلاسه کړو. موږ کولی شو دا په سیمه ایزه توګه د قونسل له لارې ترسره کړو، مګر پدې حالت کې دواړه به کنګل شي.
د ځایی قونسل پیرودونکی د HTTP API په اړه یو پوښ دی. مګر دا یوازې ځړول کیږي او Ctrl+C، یا Ctrl+Z، یا بل څه ته ځواب نه ورکوي، یوازې kill -9 په راتلونکي کنسول کې. موږ له دې سره مخ شو کله چې موږ یو لوی کلستر جوړوو. مګر موږ لاهم حل نه لرو؛ موږ په قونسل کې د دې تېروتنې د حل کولو لپاره چمتووالی نیسو.
د قونسل مشر ځواب نه ورکوي. د معلوماتو په مرکز کې زموږ ماسټر ځواب نه ورکوي، موږ فکر کوو: "شاید د بیا انتخاب الګوریتم به اوس کار وکړي؟"
نه، دا به کار ونکړي، او څارنه به هیڅ ونه ښیې: قونسل به ووایي چې د ژمنې شاخص شتون لري، یو مشر موندل شوی، هرڅه سم دي.
موږ څنګه له دې سره معامله کوو؟ service consul restart په هر ساعت کې په کرون کې. که تاسو 50 سرورونه لرئ، کومه لویه معامله نه ده. کله چې د دوی څخه 16 وي، تاسو به پوه شئ چې دا څنګه کار کوي.
پایلې
د پایلې په توګه، موږ لاندې ګټې ترلاسه کړې:
- د ټولو لینکس ماشینونو 100٪ پوښښ.
- سرعت.
- اتوماتیک.
- موږ هارډویر او د شبکې انجنیران د غلامۍ څخه آزاد کړل.
- د ادغام امکانات څرګند شوي چې تقریبا لامحدود دي: حتی د کوبرنیټس سره، حتی د ځواب وړ سره، حتی د پایتون سره.
Минусы: قونسل، سره چې موږ اوس د ژوند کولو، او د تېروتنې ډېر لوړ لګښت. د مثال په توګه، یو ځل د ماښام په 6 بجو (په روسیه کې لومړی وخت) زه د شبکو په لیست کې یو څه ترمیم وم. موږ په هغه وخت کې په BEFW کې یوازې موصلیت جوړوو. ما یو ځای خطا کړې ، داسې بریښي چې ما غلط ماسک ته اشاره کړې ، مګر هرڅه په دوه ثانیو کې راوتلي. نظارت روښانه کیږي ، د دندې ملاتړی کس په منډه راځي: "موږ هرڅه لرو!" د څانګې مشر خړ شو کله چې هغه سوداګر ته تشریح کړه چې ولې دا پیښ شوي.
د غلطۍ لګښت دومره لوړ دی چې موږ د خپل پیچلي مخنیوي پروسیجر سره راغلی یو. که تاسو دا په لوی تولید سایټ کې پلي کوئ ، تاسو اړتیا نلرئ هرچا ته د قونسل په اړه ماسټر نښه ورکړئ. دا به په بده توګه پای ته ورسیږي.
لګښت ما یوازې د 400 ساعتونو لپاره کوډ لیکلی. زما د 4 کسانو ټیم په میاشت کې 10 ساعته د هرچا په ملاتړ مصرفوي. د هر نوي نسل فایروال قیمت په پرتله، دا وړیا دی.
پلانونه. اوږدمهاله پلان دا دی چې د قونسل بدلولو یا بشپړولو لپاره بدیل ټرانسپورټ ومومي. شاید دا به کافکا وي یا ورته یو څه. مګر په راتلونکو کلونو کې به موږ په قونسل کې ژوند وکړو.
سمدستي پلانونه: د Fail2ban سره ادغام، د څارنې سره، د nftables سره، احتمالا د نورو توزیعونو سره، میټریکونه، پرمختللي څارنه، اصلاح کول. د Kubernetes ملاتړ هم په پلانونو کې یو ځای دی، ځکه چې اوس موږ ډیری کلسترونه او هیله لرو.
د پلانونو څخه نور:
- په ترافیک کې د بې نظمیو لټون؛
- د شبکې نقشه مدیریت؛
- د Kubernetes ملاتړ؛
- د ټولو سیسټمونو لپاره د کڅوړو راټولول؛
- ویب-UI.
موږ په دوامداره توګه د تشکیلاتو پراخولو، میټریکونو او اصلاح کولو لپاره کار کوو.
په پروژه کې ګډون وکړئ. پروژه ښه شوه، مګر، له بده مرغه، دا لاهم د یو کس پروژه ده. ته راشه او هڅه وکړئ یو څه وکړئ: ژمنه وکړئ، ازموینه وکړئ، یو څه وړاندیز وکړئ، خپل ارزونه ورکړئ.
په عین وخت کې موږ چمتووالی نیسو ، کوم چې به د اپریل په 6 او 7 په سینټ پیټرزبورګ کې ترسره شي ، او موږ د لوړ بار سیسټمونو پراختیا کونکو ته بلنه ورکوو . تجربه لرونکي وینا کونکي دمخه پوهیږي چې څه وکړي، مګر د هغو کسانو لپاره چې خبرې کوي موږ لږترلږه وړاندیز کوو . په کنفرانس کې د وینا کونکي په توګه برخه اخیستل یو شمیر ګټې لري. تاسو کولی شئ ولولئ چې کوم یو، د بیلګې په توګه، په پای کې .
سرچینه: www.habr.com