2010 онд тус компани 50 сервер, энгийн сүлжээний загвар байсан: backend, frontend, firewall. Серверүүдийн тоо нэмэгдэж, загвар нь илүү төвөгтэй болсон: үе шат, ACL-тай тусгаарлагдсан VLAN, дараа нь VRF-тэй VPN, L2 дээр ACL-тэй VLAN, L3 дээр ACL-тэй VRF. Толгой эргэх үү? Дараа нь илүү хөгжилтэй байх болно.
16 сервер байхад ийм олон янзын сегменттэй нулимсгүйгээр ажиллах боломжгүй болсон. Тиймээс бид өөр шийдэлд хүрсэн. Бид Netfilter стекийг авч, өгөгдлийн эх сурвалж болгон консулыг нэмж, хурдан тархсан галт ханатай болсон. Тэд чиглүүлэгчид ACL-ийг сольж, тэдгээрийг гадаад болон дотоод галт хана болгон ашигласан. Хэрэгслийг динамикаар удирдахын тулд бид BEFW системийг боловсруулсан бөгөөд үүнийг хаа сайгүй ашигладаг: бүтээгдэхүүний сүлжээнд хэрэглэгчийн хандалтыг удирдахаас эхлээд сүлжээний сегментүүдийг бие биенээсээ тусгаарлах хүртэл.
Энэ бүхэн хэрхэн ажилладаг, яагаад энэ системийг илүү нарийвчлан авч үзэх хэрэгтэйг тэр танд хэлэх болно. Иван Агарков () нь компанийн Минск хөгжлийн төвийн Засвар үйлчилгээний хэлтсийн дэд бүтцийн аюулгүй байдлын бүлгийн дарга юм. Иван бол SELinux-ийн шүтэн бишрэгч, Perl-д дуртай, код бичдэг. Мэдээллийн аюулгүй байдлын бүлгийн даргын хувьд Wargaming-ийг хакеруудаас хамгаалж, компанийн бүх тоглоомын серверийн ажиллагааг хангахын тулд бүртгэл, нөөцлөлт, судалгаа шинжилгээний ажилтай тогтмол ажилладаг.
Түүхэн үндэслэл
Үүнийг яаж хийснээ хэлэхээсээ өмнө анх яаж ийм байдалд хүрсэн, яагаад хэрэгтэй байсныг хэлье. Үүнийг хийхийн тулд 9 жилийг эргэн санацгаая: 2010 онд World of Tanks гарч ирсэн. Wargaming нь ойролцоогоор 50 сервертэй байсан.
Компанийн серверийн өсөлтийн график.
Бидэнд сүлжээний загвар байсан. Тэр үед энэ нь оновчтой байсан.
2010 оны сүлжээний загвар.
Урд талд биднийг эвдэхийг хүсдэг муу хүмүүс байдаг, гэхдээ энэ нь галт ханатай. Backend дээр галт хана байхгүй, гэхдээ тэнд 50 сервер байдаг, бид бүгдийг нь мэднэ. Бүх зүйл сайн ажилладаг.
4 жилийн дотор серверийн флот 100 дахин нэмэгдэж, 5000 болсон. Анхны тусгаарлагдсан сүлжээнүүд гарч ирэв - үе шат: тэд үйлдвэрлэлд явж чадахгүй байсан бөгөөд тэнд ихэвчлэн аюултай байж болох зүйлүүд ажиллаж байсан.
2014 оны сүлжээний загвар.
Инерцийн хувьд бид ижил төрлийн техник хангамжийг ашигласан бөгөөд бүх ажлыг тусгаарлагдсан VLAN-ууд дээр хийсэн: ACL-ууд нь VLAN-д бичигддэг бөгөөд энэ нь ямар нэгэн холболтыг зөвшөөрдөг эсвэл үгүйсгэдэг.
2016 онд серверийн тоо 8000-д хүрч Wargaming бусад студиудыг өөртөө шингээж, нэмэлт салбар сүлжээнүүд гарч ирэв. Тэдгээр нь биднийх юм шиг санагддаг, гэхдээ тийм ч сайн биш: VLAN нь түншүүдэд ихэвчлэн ажилладаггүй, та VRF-тэй VPN ашиглах хэрэгтэй, тусгаарлалт нь илүү төвөгтэй болдог. ACL тусгаарлагч хольц өссөн.
2016 оны сүлжээний загвар.
2018 оны эхээр машинуудын парк 16 болж өссөн. 000 сегмент байсан бөгөөд санхүүгийн мэдээлэл хадгалагдаж байсан хаалттай хэсгийг оруулаад бид үлдсэн хэсгийг нь тооцоогүй. Контейнер сүлжээ (Kubernetes), DevOps, VPN-ээр холбогдсон үүл сүлжээнүүд, жишээлбэл, IVS-ээс гарч ирэв. Маш олон дүрэм журам байсан - энэ нь өвдөлттэй байсан.
2018 онд сүлжээний загвар ба тусгаарлах аргууд.
Тусгаарлахын тулд бид ашигласан: L2 дээр ACL-тай VLAN, L3 дээр ACL-тай VRF, VPN ба бусад. Хэт их.
Асуудал
Хүн бүр ACL болон VLAN-тай амьдардаг. Юу болсон бэ? Энэ асуултад Харолд өвдөлтөө нууж хариулна.
Олон асуудал байсан ч таван том асуудал байсан.
- Шинэ дүрмийн геометрийн үнийн өсөлт. Шинэ дүрэм бүрийг нэмэхэд өмнөхөөсөө илүү удаан хугацаа шаардагддаг байсан, учир нь эхлээд ийм дүрэм байгаа эсэхийг шалгах шаардлагатай байв.
- Сегмент дотор галт хана байхгүй. Сегментүүд бие биенээсээ ямар нэгэн байдлаар тусгаарлагдсан бөгөөд дотор нь хангалттай нөөц байхгүй байв.
- Дүрмийг удаан хугацаанд хэрэглэж байсан. Операторууд нэг цагийн дотор орон нутгийн нэг дүрмийг гараар бичиж болно. Дэлхий дахинд хэд хоног үргэлжилсэн.
- Аудитын дүрэмтэй холбоотой бэрхшээлүүд. Бүр тодруулбал, боломжгүй байсан. Эхний дүрмийг 2010 онд бичсэн бөгөөд ихэнх зохиогчид тус компанид ажиллахаа больсон.
- Дэд бүтцийн хяналтын түвшин доогуур. Энэ бол гол асуудал юм - манай улсад юу болж байгааг бид сайн мэдэхгүй байсан.
Сүлжээний инженер 2018 онд "Дахиад ACL хэрэгтэй байна" гэж сонсоод ийм байдалтай байсан.
Шийдэл
2018 оны эхээр энэ талаар ямар нэгэн зүйл хийхээр болсон.
Интеграцийн үнэ байнга өсч байна. Эхлэх цэг нь төхөөрөмжүүдийн санах ой дууссан тул томоохон дата төвүүд тусгаарлагдсан VLAN болон ACL-ийг дэмжихээ больсон.
Шийдэл: бид хүний хүчин зүйлийг арилгаж, хамгийн дээд хэмжээнд хүрэх боломжийг автоматжуулсан.
Шинэ дүрмийг хэрэгжүүлэхэд нэлээд хугацаа шаардагдана. Шийдэл: дүрмийн хэрэглээг хурдасгах, тарааж, зэрэгцээ болгох. Энэ нь дүрэм журам нь rsync эсвэл SFTPгүйгээр мянга мянган системд хүргэдэг байхаар хуваарилагдсан системийг шаарддаг.
Сегмент дотор галт хана байхгүй. Нэг сүлжээнд өөр өөр үйлчилгээнүүд гарч ирэхэд сегмент дэх галт хана бидэнд ирж эхлэв. Шийдэл: хостын түвшинд галт ханыг ашиглах - хост дээр суурилсан галт хана. Бараг хаа сайгүй л Линукстэй, хаана ч iptables байдаг, энэ нь асуудал биш юм.
Аудитын дүрэмтэй холбоотой бэрхшээлүүд. Шийдэл: Бүх дүрмийг хянаж, удирдахын тулд нэг газар хадгалаарай, ингэснээр бид бүх зүйлийг шалгаж болно.
Дэд бүтцэд тавих хяналт бага. Шийдэл: бүх үйлчилгээ, тэдгээрийн хоорондох хандалтын тооллого хийх.
Энэ бол техникийн гэхээсээ илүү захиргааны үйл явц юм. Заримдаа бид долоо хоногт 200-300 шинэ хувилбар гаргадаг, ялангуяа урамшуулал, баяр ёслолын үеэр. Түүнээс гадна энэ нь зөвхөн манай DevOps-ийн нэг багт зориулагдсан. Ийм олон хувилбартай учраас ямар порт, IP, интеграцчилал хэрэгтэйг харах боломжгүй юм. Тиймээс бидэнд тусгайлан бэлтгэгдсэн үйлчилгээний менежерүүд хэрэгтэй байсан бөгөөд тэд багуудаас "Юу байгаа юм бэ, яагаад үүнийг гаргаж ирсэн бэ?"
Бидний эхлүүлсэн бүх зүйлийн дараа 2019 онд сүлжээний инженер ийм харагдаж эхэлсэн.
Консул
Бид үйлчилгээний менежерүүдийн тусламжтайгаар олсон бүх зүйлээ Консул руу хийж, тэндээс iptables дүрмийг бичихээр шийдсэн.
Бид яаж үүнийг хийхээр шийдсэн бэ?
- Бид бүх үйлчилгээ, сүлжээ, хэрэглэгчдийг цуглуулах болно.
- Тэдгээр дээр үндэслэн iptables дүрмийг бий болгоцгооё.
- Бид хяналтыг автоматжуулдаг.
- ....
- АШИГ.
Консул нь алсын API биш бөгөөд бүх цэг дээр ажиллаж, iptables руу бичих боломжтой. Шаардлагагүй зүйлсийг цэвэрлэх автомат удирдлага бий болгох л үлдэж, ихэнх асуудлууд шийдэгдэх болно! Үлдсэнийг нь бид явахдаа шийднэ.
Яагаад консул гэж?
Өөрийгөө сайн нотолсон. 2014-15 онд бид үүнийг нууц үгээ хадгалдаг Vault програмын арын хэсэг болгон ашигласан.
Өгөгдөл алдахгүй. Ашиглалтын хугацаанд Консул нэг удаагийн ослын үед мэдээллээ алдаагүй. Энэ нь галт ханын удирдлагын системийн хувьд маш том давуу тал юм.
P2P холболтууд нь өөрчлөлтийн тархалтыг хурдасгадаг. P2P-ийн тусламжтайгаар бүх өөрчлөлтүүд хурдан ирдэг, олон цаг хүлээх шаардлагагүй.
Тохиромжтой REST API. Бид мөн Apache ZooKeeper-ийг авч үзсэн боловч REST API байхгүй тул та таяг суулгах хэрэгтэй болно.
Key Vault (KV) болон лавлах (Үйлчилгээний нээлт) хоёулаа ажилладаг.. Та үйлчилгээ, каталог, дата төвөө нэг дор хадгалах боломжтой. Энэ нь зөвхөн бидэнд төдийгүй хөрш зэргэлдээх багуудад ч тохиромжтой, учир нь дэлхийн үйлчилгээг бий болгохдоо бид том зүйлийг боддог.
Wargaming стекийн нэг хэсэг болох Go дээр бичигдсэн. Бид энэ хэлэнд дуртай, бидэнд Go хөгжүүлэгч олон бий.
Хүчирхэг ACL систем. Консулд та ACL ашиглан хэн юу бичиж байгааг хянах боломжтой. Галт ханын дүрэм бусад зүйлтэй давхцахгүй бөгөөд үүнтэй холбоотой асуудал гарахгүй гэдгийг бид баталж байна.
Гэхдээ Консулд бас сул тал бий.
- Танд бизнесийн хувилбар байхгүй л бол дата төв дотор томрохгүй. Үүнийг зөвхөн холбооны хэмжээнд өргөжүүлэх боломжтой.
- Энэ нь сүлжээний чанар, серверийн ачааллаас ихээхэн хамаардаг. Сүлжээнд ямар нэгэн хоцрогдол, жишээлбэл, хурд жигд бус байвал консул завгүй сервер дээр серверийн хувьд зөв ажиллахгүй. Энэ нь P2P холболтууд болон түгээлтийн загваруудыг шинэчлэхтэй холбоотой юм.
- Боломжит байдлыг хянахад бэрхшээлтэй. Консулын статусын хувьд тэрээр бүх зүйл сайхан байна гэж хэлж чадна, гэхдээ тэр эрт нас баржээ.
Бид Консулаар үйлчлүүлэхдээ эдгээр асуудлуудын ихэнхийг нь шийдсэн тул үүнийг сонгосон. Тус компани өөр арын төлөвлөгөөтэй байгаа ч бид асуудлыг шийдэж сурсан бөгөөд одоогоор Консултай хамт амьдарч байна.
Консул хэрхэн ажилладаг
Бид нөхцөлт дата төвд гурваас таван сервер суулгана. Нэг эсвэл хоёр сервер ажиллахгүй: тэд чуулга зохион байгуулж, өгөгдөл нь таарахгүй байхад хэн нь зөв, хэн нь буруу болохыг шийдэж чадахгүй. Таваас дээш бол утгагүй, бүтээмж буурна.
Үйлчлүүлэгчид серверүүдтэй ямар ч дарааллаар холбогддог: ижил агентууд, зөвхөн тугтай server = false.
Үүний дараа үйлчлүүлэгчид P2P холболтын жагсаалтыг хүлээн авч, хоорондоо холболт үүсгэдэг.
Дэлхийн хэмжээнд бид хэд хэдэн дата төвийг холбодог. Тэд мөн P2P-г холбож, харилцдаг.
Бид өөр өгөгдлийн төвөөс мэдээлэл авахыг хүсэх үед хүсэлт серверээс сервер рүү шилждэг. Энэ схемийг нэрлэдэг Серфийн протокол. Консулын нэгэн адил Serf протоколыг HashiCorp боловсруулсан.
Консулын тухай зарим чухал баримтууд
Консулд энэ нь хэрхэн ажилладаг талаар баримт бичиг байдаг. Би зөвхөн мэдэх хэрэгтэй сонгосон баримтуудыг өгөх болно.
Консулын серверүүд сонгогчдын дундаас мастер сонгодог. Консул нь дата төв бүрийн серверүүдийн жагсаалтаас мастер сонгох бөгөөд бүх хүсэлт серверийн тооноос үл хамааран зөвхөн түүнд очдог. Мастер хөлдөөх нь дахин сонгогдохгүй. Хэрэв мастер сонгогдоогүй бол хүсэлтэд хэн ч үйлчлэхгүй.
Та хэвтээ масштабыг хүссэн үү? Уучлаарай, үгүй.
Өөр өгөгдлийн төвд хандах хүсэлт нь аль серверт ирсэнээс үл хамааран мастераас мастер руу дамждаг. Сонгосон мастер нь форвард хүсэлтийн ачааллаас бусад ачааллын 100% -ийг хүлээн авдаг. Дата төвийн бүх серверүүд өгөгдлийн шинэчилсэн хуулбартай боловч зөвхөн нэг нь хариу өгдөг.
Өргөтгөх цорын ганц арга бол үйлчлүүлэгч дээр хуучирсан горимыг идэвхжүүлэх явдал юм.
Хуучирсан горимд та ирц бүрдүүлэхгүйгээр хариу өгөх боломжтой. Энэ нь бид өгөгдлийн тууштай байдлаас татгалздаг горим юм, гэхдээ ердийнхөөс арай хурдан уншдаг бөгөөд ямар ч сервер хариу үйлдэл үзүүлдэг. Мэдээжийн хэрэг, зөвхөн мастераар дамжуулан бичлэг хийх.
Консул нь дата төвүүдийн хооронд өгөгдлийг хуулдаггүй. Холбоог угсрах үед сервер бүр зөвхөн өөрийн өгөгдөлтэй байх болно. Бусдын хувьд тэр үргэлж өөр хэн нэгэнд ханддаг.
Гүйлгээнээс гадуур үйл ажиллагааны атомын баталгаа байхгүй. Аливаа зүйлийг өөрчлөх чадвартай цорын ганц хүн биш гэдгийг санаарай. Хэрэв та өөрөөр хүсч байвал цоожтой гүйлгээ хий.
Блоклох үйл ажиллагаа нь түгжих баталгаа болохгүй. Хүсэлт нь шууд биш, мастераас мастер руу дамждаг тул, жишээлбэл, өөр мэдээллийн төвд блоклох үед блок ажиллах баталгаа байхгүй.
ACL нь хандалтыг баталгаажуулдаггүй (ихэнх тохиолдолд). ACL нь нэг холбооны мэдээллийн төвд - ACL мэдээллийн төвд (Анхдагч DC) хадгалагддаг тул ажиллахгүй байж магадгүй. Хэрэв DC танд хариу өгөхгүй бол ACL ажиллахгүй.
Нэг хөлдөөсөн мастер холбоог бүхэлд нь хөлдөхөд хүргэнэ. Тухайлбал, нэг холбоонд 10 дата төв байдгийн нэг нь сүлжээ муутай, нэг мастер доголдолтой байдаг. Түүнтэй харилцаж буй хүн бүр тойрогт гацах болно: хүсэлт байна, түүнд хариулт алга, утас нь хөлддөг. Хэзээ болохыг мэдэх арга алга, ганц хоёр цагийн дараа л холбоо бүхэлдээ унана. Та энэ талаар юу ч хийж чадахгүй.
Статус, чуулга, сонгуулийг тусдаа хэлхээгээр зохицуулдаг. Дахин сонгууль болохгүй, статус юу ч харуулахгүй. Та амьд консултай гэж бодож байна, та асууж, юу ч болоогүй - хариулт алга. Үүний зэрэгцээ статус нь бүх зүйл сайхан байгааг харуулж байна.
Бид ийм асуудалтай тулгарсан бөгөөд үүнээс зайлсхийхийн тулд дата төвийн тодорхой хэсгийг дахин бүтээх шаардлагатай болсон.
Consul Enterprise-ийн бизнесийн хувилбарт дээрх зарим сул тал байхгүй. Энэ нь сонгогчдыг сонгох, хуваарилах, хуваах зэрэг олон ашигтай функцтэй. Зөвхөн нэг "гэхдээ" байдаг - тархсан системийн лицензийн систем нь маш үнэтэй байдаг.
Амьдралыг хакердах: rm -rf /var/lib/consul - агентын бүх өвчнийг эмчлэх. Хэрэв ямар нэг зүйл танд тохирохгүй бол өгөгдлөө устгаад хуулбараас өгөгдлийг татаж аваарай. Консул ажиллах байх.
BEFW
Одоо Консулд юу нэмсэн талаар ярилцъя.
гэсэн үгийн товчлол юм BACKEndFцахилгаанWбүгд. Би агуулахыг бий болгохдоо анхны туршилтыг оруулахын тулд бүтээгдэхүүнийг ямар нэгэн байдлаар нэрлэх шаардлагатай болсон. Энэ нэр хэвээр байна.
Дүрмийн загварууд
Дүрмүүдийг iptables синтакс дээр бичсэн болно.
- -Н BEFW
- -P INPUT DROP
- -A INPUT -m төлөв-төр ХОЛБООТОЙ, БАЙГУУЛСАН -j ХҮЛЭЭН АВАХ
- -A INPUT -i lo -j CEPT
- -A INPUT -j BEFW
Бусад бүх зүйл BEFW гинжин хэлхээнд ордог ESTABLISHED, RELATED болон localhost. Загвар нь юу ч байж болно, энэ бол зүгээр л жишээ юм.
BEFW хэрхэн ашигтай вэ?
үйлчилгээ
Бидэнд үйлчилгээ байдаг, энэ нь үргэлж порттой, ажилладаг зангилаатай байдаг. Манай зангилаанаас бид орон нутгийн төлөөлөгчөөс асууж, бидэнд ямар нэгэн үйлчилгээ байгааг олж мэдэх боломжтой. Та мөн шошго тавьж болно.
Консулд бүртгэлтэй, ажиллаж байгаа аливаа үйлчилгээ iptables дүрэм болж хувирдаг. Бидэнд SSH байна - нээлттэй порт 22. Bash скрипт нь энгийн: curl болон iptables, өөр юу ч хэрэггүй.
Үйлчлүүлэгчид
Хэрхэн хүн бүрт биш, харин сонгон хандалтыг нээх вэ? IP жагсаалтыг үйлчилгээний нэрээр KV санах ойд нэмнэ үү.
Жишээлбэл, бид арав дахь сүлжээнд байгаа хүн бүрийг SSH_TCP_22 үйлчилгээнд хандах боломжтой байлгахыг хүсч байна. Нэг жижиг TTL талбар нэмэх үү? одоо бид түр зөвшөөрөлтэй, тухайлбал, нэг өдрийн хугацаатай.
Хандалтууд
Бид үйлчилгээ болон үйлчлүүлэгчдийг холбодог: бидэнд үйлчилгээ бий, КВ хадгалах газар тус бүрт бэлэн байна. Одоо бид хүн бүрт биш, харин сонгон ашиглах боломжийг олгодог.
Бүлгүүд
Хэрэв бид нэвтрэх болгондоо мянга мянган IP бичвэл бид ядрах болно. КВ дахь тусдаа дэд бүлэг болох бүлгүүдийг гаргацгаая. Үүнийг Alias (эсвэл бүлгүүд) гэж нэрлээд ижил зарчмын дагуу бүлгүүдийг хадгалъя.
Холбоцгооё: одоо бид SSH-г тусгайлан P2P-д зориулж биш, харин бүхэл бүтэн бүлэг эсвэл хэд хэдэн бүлгүүдэд нээж болно. Үүнтэй адил TTL байдаг - та бүлэгт нэмж, бүлгээс түр хасаж болно.
Интеграцчилал
Бидний асуудал бол хүний хүчин зүйл, автоматжуулалт юм. Одоогийн байдлаар бид үүнийг ингэж шийдсэн.
Бид Хүүхэлдэйтэй ажилладаг бөгөөд системтэй холбоотой бүх зүйлийг (програмын код) тэдэнд шилжүүлдэг. Puppetdb (ердийн PostgreSQL) тэнд ажиллаж байгаа үйлчилгээний жагсаалтыг хадгалдаг бөгөөд тэдгээрийг нөөцийн төрлөөр нь олж болно. Тэнд та хэн хаана өргөдөл гаргаж байгааг олж мэдэх боломжтой. Үүний тулд бид татах хүсэлт, нэгтгэх хүсэлтийн системтэй.
Бид өгөгдөл дамжуулахад тусалдаг энгийн шийдэл болох befw-sync бичсэн. Нэгдүгээрт, синхрончлолын күүкид puppetdb ханддаг. Тэнд HTTP API тохируулагдсан: бид ямар үйлчилгээтэй, юу хийх шаардлагатайг асуудаг. Дараа нь тэд консулд хүсэлт гаргадаг.
Интеграл бий юу? Тийм: тэд дүрмийг бичиж, татах хүсэлтийг хүлээн авахыг зөвшөөрсөн. Танд тодорхой порт хэрэгтэй юу эсвэл зарим бүлэгт хост нэмэх үү? Хүсэлтийг татах, хянан үзэх - "Өөр 200 ACL олж, энэ талаар ямар нэгэн зүйл хийхийг оролдоорой."
Оновчтой болгох
Хоосон дүрмийн гинжээр localhost-д ping хийх нь 0,075 мс болно.
Энэ хэлхээнд 10 iptables хаяг нэмье. Үүний үр дүнд ping 000 дахин нэмэгдэх болно: iptables нь бүрэн шугаман, хаяг бүрийг боловсруулахад хэсэг хугацаа шаардагдана.
Бид олон мянган ACL-г шилжүүлдэг галт ханын хувьд бидэнд маш олон дүрэм байдаг бөгөөд энэ нь хоцролтыг бий болгодог. Энэ нь тоглоомын протоколд муу.
Гэхдээ хэрэв бид тавьсан бол ipset-д 10 хаяг Пинг нь бүр буурах болно.
Гол нь ipset-ийн "O" (алгоритмын нарийн төвөгтэй байдал) нь хичнээн дүрэмтэй байсан ч үргэлж 1-тэй тэнцүү байдаг. Үнэн, хязгаарлалт байдаг - 65535-аас илүү дүрмүүд байж болохгүй. Одоогоор бид үүнийг дагаж мөрддөг: та тэдгээрийг нэгтгэж, өргөжүүлж, нэг дор хоёр ipset хийж болно.
Хадгалалт
Давталтын үйл явцын логик үргэлжлэл нь ipset-д үйлчилгээнд зориулсан үйлчлүүлэгчдийн мэдээллийг хадгалах явдал юм.
Одоо бид ижил SSH-тэй бөгөөд бид нэг дор 100 IP бичдэггүй, харин бидэнтэй харилцах шаардлагатай ipset-ийн нэрийг, дараах дүрмийг тогтооно. DROP. Үүнийг "Энд хэн байхгүй, DROP" гэсэн нэг дүрэм болгон хувиргаж болох ч энэ нь илүү ойлгомжтой юм.
Одоо бидэнд дүрэм, багц бий. Гол ажил бол дүрмийг бичихээс өмнө багц хийх явдал юм, учир нь өөрөөр хэлбэл iptables дүрмийг бичихгүй.
Ерөнхий схем
Диаграмм хэлбэрээр миний хэлсэн бүх зүйл иймэрхүү харагдаж байна.
Бид хүүхэлдэйг амлаж байна, бүх зүйл хост руу илгээгдсэн, энд үйлчилгээ, тэнд ipset, тэнд бүртгүүлээгүй хэнийг ч зөвшөөрөхгүй.
Зөвшөөрөх, татгалзах
Дэлхийг хурдан аврах эсвэл хэн нэгнийг хурдан идэвхгүй болгохын тулд бүх хэлхээний эхэнд бид хоёр ipset хийсэн. rules_allow и rules_deny. Хэрхэн ажилладаг?
Жишээлбэл, хэн нэгэн манай вэб дээр ботоор ачааллыг үүсгэж байна. Өмнө нь та түүний IP-г бүртгэлээс олж, сүлжээний инженерүүдэд аваачиж, траффикийн эх сурвалжийг олж, түүнийг хориглох ёстой байв. Одоо арай өөр харагдаж байна.
Бид үүнийг Консул руу илгээж, 2,5 секунд хүлээнэ үү. Консул нь P2P-ээр дамжуулан хурдан түгээдэг тул дэлхийн аль ч хэсэгт хаана ч ажилладаг.
Нэг удаа би галт ханын алдааны улмаас WOT-г бүрэн зогсоосон. rules_allow - Энэ бол ийм тохиолдлын эсрэг бидний даатгал юм. Хэрэв бид хаа нэгтээ галт хананд алдаа гаргасан бол хаа нэгтээ ямар нэг зүйл хаагдсан бол бид үргэлж болзол илгээж болно 0.0/0бүх зүйлийг хурдан авах. Дараа нь бид бүх зүйлийг гараар засах болно.
Бусад багц
Та орон зайд өөр ямар ч багц нэмж болно $IPSETS$.
Юуны төлөө? Заримдаа хэн нэгэнд ipset хэрэгтэй, жишээлбэл кластерын зарим хэсгийг унтрааж дуурайдаг. Хэн ч дурын иж бүрдэл авчирч, нэрлэж болно, Консулаас авах болно. Үүний зэрэгцээ багцууд iptables дүрэмд оролцох эсвэл баг болж ажиллах боломжтой NOOP: Тогтвортой байдлыг демон хадгална.
Хэрэглэгчид
Өмнө нь энэ нь иймэрхүү байсан: хэрэглэгч сүлжээнд холбогдож, домайнаар дамжуулан параметрүүдийг хүлээн авсан. Шинэ үеийн галт хана гарч ирэхээс өмнө Cisco хэрэглэгч хаана байгаа, IP хаана байгааг хэрхэн ойлгохоо мэддэггүй байв. Тиймээс, нэвтрэх эрхийг зөвхөн машины хостын нэрээр дамжуулан олгосон.
Бид юу хийсэн бэ? Бид хаягаа авах мөчид гацсан. Ихэвчлэн энэ нь dot1x, Wi-Fi эсвэл VPN юм - бүх зүйл RADIUS-ээр дамждаг. Хэрэглэгч бүрийн хувьд бид хэрэглэгчийн нэрээр бүлэг үүсгэж, түүнд dhcp.lease-тай тэнцэх TTL-тэй IP байрлуулдаг - хугацаа нь дуусмагц дүрэм алга болно.
Одоо бид бусад бүлгүүдийн нэгэн адил үйлчилгээний хандалтыг хэрэглэгчийн нэрээр нээх боломжтой. Бид хостын нэр солигдох үед зовлон зүдгүүрийг арилгаж, Cisco хэрэггүй болсон тул сүлжээний инженерүүдийн ачааллаас чөлөөлсөн. Одоо инженерүүд өөрсдөө сервер дээрээ хандалт бүртгүүлдэг.
Тусгаарлалтын
Үүний зэрэгцээ бид дулаалгыг буулгаж эхлэв. Үйлчилгээний менежерүүд тооллого авч, бид бүх сүлжээндээ дүн шинжилгээ хийсэн. Тэдгээрийг ижил бүлгүүдэд хувааж үзье, шаардлагатай серверүүд дээр бүлгүүдийг нэмсэн, жишээлбэл, үгүйсгэх. Одоо ижил түвшний тусгаарлалт нь үйлдвэрлэлийн дүрэмд_үгүйцэлд ордог, гэхдээ үйлдвэрлэлд биш.
Энэхүү схем нь хурдан бөгөөд энгийн байдлаар ажилладаг: бид серверүүдээс бүх ACL-ийг устгаж, техник хангамжийг буулгаж, тусгаарлагдсан VLAN-ийн тоог багасгадаг.
Шударга байдлын хяналт
Өмнө нь хэн нэгэн галт ханын дүрмийг гараар өөрчлөх үед мэдээлдэг тусгай гох төхөөрөмжтэй байсан. Би галт ханын дүрмийг шалгахын тулд асар том линтер бичиж байсан, энэ нь хэцүү байсан. Шударга байдлыг одоо BEFW хянаж байна. Тэрээр өөрийн гаргасан дүрэм журмыг өөрчлөхгүй байхыг хичээнгүйлэн баталгаажуулдаг. Хэрэв хэн нэгэн галт ханын дүрмийг өөрчилбөл бүх зүйлийг буцааж өөрчлөх болно. “Би гэрээсээ ажиллахын тулд хурдан прокси тохируулсан”— ийм сонголт байхгүй болсон.
BEFW нь үйлчилгээнүүдийн ipset-ийг хянадаг бөгөөд BEFW сүлжээн дэх үйлчилгээний дүрмийг befw.conf-д жагсаана. Гэхдээ энэ нь бусад хэлхээ, дүрэм болон бусад ipsets-ийг хянадаггүй.
Гэмтлийн хамгаалалт
BEFW нь хамгийн сүүлийн сайн төлөвийг шууд state.bin хоёртын бүтцэд хадгалдаг. Хэрэв ямар нэг зүйл буруу болвол үргэлж энэ төлөв рүү буцдаг.bin.
Энэ нь Консулын тогтворгүй үйл ажиллагаа, өгөгдөл илгээгээгүй эсвэл хэн нэгэн алдаа гаргасан, хэрэглэх боломжгүй дүрэм ашигласан тохиолдолд даатгал юм. Бид галт ханагүй үлдэхгүйн тулд аль ч шатанд алдаа гарвал BEFW хамгийн сүүлийн үеийн төлөв рүү буцна.
Хэцүү нөхцөлд энэ нь бидэнд ажиллах галт хана үлдэх баталгаа юм. Админ нь ирж засна гэж найдаж бүх саарал сүлжээг нээж байна. Хэзээ нэгэн цагт би үүнийг тохиргоонд оруулах болно, гэхдээ одоо бид гурван саарал сүлжээтэй байна: 10/8, 172/12, 192.168/16. Манай Консулын хувьд энэ нь биднийг цааш хөгжүүлэхэд тусалдаг чухал шинж чанар юм.
Демо: тайлангийн үеэр Иван BEFW-ийн демо горимыг харуулж байна. Жагсаал үзэх нь илүү хялбар байдаг . Демо эх код боломжтой .
Хүндрэл
Бидэнд тохиолдсон алдааны талаар би танд хэлэх болно.
ipset add set 0.0.0.0/0. Хэрэв та ipset дээр 0.0.0.0/0 нэмбэл юу болох вэ? Бүх IP нэмэх үү? Интернэт нэвтрэх боломжтой юу?
Үгүй ээ, бид хоёр цаг зогсоход хүргэдэг алдаа гарах болно. Түүнчлэн, алдаа 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 бөгөөд энэ мөчид зарим пакет ирэх бөгөөд энэ нь хаягдаж, ямар нэг зүйл буруу болно. Тэгэхээр тэнд жаахан хар ид шид бий.
consul kv get -datacenter=бусад. Миний хэлсэнчлэн, бид зарим өгөгдөл авахыг хүсч байна гэж бодож байна, гэхдээ бид өгөгдөл эсвэл алдаа авах болно. Бид үүнийг орон нутгийн консулаар дамжуулан хийж болно, гэхдээ энэ тохиолдолд хоёулаа хөлдөх болно.
Орон нутгийн Консулын үйлчлүүлэгч нь HTTP API дээр боодол юм. Гэхдээ энэ нь зүгээр л унжсан бөгөөд Ctrl+C, Ctrl+Z эсвэл ямар нэгэн зүйлд хариу өгөхгүй, зөвхөн kill -9 дараагийн консол дээр. Бид том кластер барьж байхдаа ийм зүйлтэй тулгарсан. Гэхдээ одоохондоо бидэнд шийдэл алга, бид Консул дээр энэ алдааг засахаар бэлтгэж байна.
Консулын дарга хариу өгөхгүй байна. Дата төв дэх манай мастер хариу өгөхгүй байгаа тул бид: "Магадгүй дахин сонгох алгоритм ажиллах болов уу?"
Үгүй ээ, энэ нь ажиллахгүй бөгөөд хяналт нь юу ч харуулахгүй: Консул амлалтын индекс байгаа, удирдагч олдсон, бүх зүйл сайхан байна гэж хэлэх болно.
Үүнийг бид хэрхэн шийдвэрлэх вэ? service consul restart цаг тутамд cron. Хэрэв танд 50 сервер байгаа бол том асуудал байхгүй. Тэдний 16 нь байгаа үед энэ нь хэрхэн ажилладагийг ойлгох болно.
дүгнэлт
Үүний үр дүнд бид дараахь давуу талыг олж авлаа.
- Бүх Линукс машинуудын 100% хамрах хүрээ.
- Хурд.
- Автоматжуулалт.
- Бид техник хангамж, сүлжээний инженерүүдийг боолчлолоос чөлөөлсөн.
- Бараг хязгааргүй интеграцийн боломжууд гарч ирэв: Кубернетестэй ч, Ansible-тэй ч, Python-той ч гэсэн.
Минусы: Консул, бид одоо амьдрах ёстой бөгөөд алдааны маш өндөр өртөгтэй. Жишээлбэл, би нэг удаа оройн 6 цагт (ОХУ-ын цаг) сүлжээнүүдийн жагсаалтад ямар нэгэн зүйлийг засварлаж байсан. Бид тухайн үед BEFW-д дөнгөж дулаалга хийж байсан. Би хаа нэгтээ алдаа хийсэн, би буруу маск зааж өгсөн бололтой, гэхдээ бүх зүйл хоёр секундын дотор унав. Хяналт асч, жижүүр гүйж ирээд: "Бидэнд бүх зүйл байна!" Яагаад ийм зүйл болсныг тус газрын дарга бизнес эрхлэгчдэд тайлбарлахад саарал өнгөтэй болжээ.
Алдааны өртөг маш өндөр тул бид урьдчилан сэргийлэх цогц арга хэмжээг боловсруулсан. Хэрэв та үүнийг томоохон үйлдвэрлэлийн сайт дээр хэрэгжүүлбэл хүн бүрт Консулын мастер жетон өгөх шаардлагагүй. Энэ нь муугаар дуусна.
Зардал Би ганцаараа 400 цаг код бичсэн. Миний 4 хүний бүрэлдэхүүнтэй баг сард 10 цагийг хүн бүрийг дэмжихэд зарцуулдаг. Ямар ч шинэ үеийн галт ханын үнэтэй харьцуулахад энэ нь үнэ төлбөргүй байдаг.
Төлөвлөгөө. Урт хугацааны төлөвлөгөө нь Консулыг солих эсвэл нөхөх өөр тээврийн хэрэгслийг олох явдал юм. Магадгүй энэ нь Кафка эсвэл үүнтэй төстэй зүйл байх болно. Харин ойрын жилүүдэд бид Консул дээр амьдрах болно.
Яаралтай төлөвлөгөө: Fail2ban, хяналт, nftables, магадгүй бусад түгээлтүүд, хэмжүүрүүд, дэвшилтэт хяналт, оновчлолтой нэгтгэх. Kubernetes-ийн дэмжлэг бас төлөвлөгөөний хаа нэгтээ байгаа, учир нь одоо бидэнд хэд хэдэн кластер, хүсэл байна.
Төлөвлөгөөнөөс дэлгэрэнгүй:
- замын хөдөлгөөний гажиг хайх;
- сүлжээний газрын зургийн менежмент;
- Kubernetes-ийн дэмжлэг;
- бүх системд зориулсан багцуудыг угсрах;
- Web-UI.
Бид тохиргоог өргөжүүлэх, хэмжүүрийг нэмэгдүүлэх, оновчтой болгох талаар байнга ажиллаж байна.
Төсөлд нэгдээрэй. Төсөл сайхан болсон ч харамсалтай нь нэг хүний төсөл хэвээр байна. Ирэх мөн ямар нэг зүйл хийхийг хичээ: хийх, туршиж үзэх, санал болгох, үнэлгээ өгөх.
Энэ хооронд бид бэлтгэл хийж байна , 6-р сарын 7, XNUMX-нд Санкт-Петербург хотод болох бөгөөд бид өндөр ачаалалтай системийг хөгжүүлэгчдийг урьж байна. . Туршлагатай илтгэгчид юу хийхээ аль хэдийн мэддэг байсан ч шинээр ярьж байгаа хүмүүст бид дор хаяж санал болгож байна . Чуулганд илтгэгчээр оролцох нь хэд хэдэн давуу талтай. Та алийг нь, жишээлбэл, төгсгөлд нь уншиж болно .
Эх сурвалж: www.habr.com