קונסול + iptables = :3

בשנת 2010 החברה Wargaming היו 50 שרתים ומודל רשת פשוט: backend, frontend וחומת אש. מספר השרתים גדל, המודל נעשה מורכב יותר: רכיבי VLAN מבודדים עם ACL, ואז VPNs עם VRFs, VLANs עם ACLs על L2, VRFs עם ACLs על L3. הראש מסתובב? זה יהיה יותר כיף אחר כך.

כשהיו 16 שרתים, אי אפשר היה לעבוד בלי דמעות עם כל כך הרבה מקטעים הטרוגניים. אז הגענו לפתרון אחר. לקחנו את מחסנית Netfilter, הוספנו אליה את Consul כמקור נתונים, וקיבלנו חומת אש מבוזרת מהירה. הם החליפו ACLs בנתבים והשתמשו בהם בתור חומת אש חיצונית ופנימית. לניהול דינמי של הכלי, פיתחנו את מערכת 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 לאלף מערכות.

אין חומת אש בתוך מקטעים. חומת אש בתוך מקטעים החלה להגיע אלינו כאשר שירותים שונים הופיעו באותה רשת. פתרון: השתמש בחומת אש ברמת המארח - חומות אש מבוססות מארח. כמעט בכל מקום שיש לנו לינוקס, ובכל מקום שיש לנו iptables, זו לא בעיה.

קשיים עם כללי ביקורת. פתרון: שמור את כל הכללים במקום אחד לבדיקה וניהול, כדי שנוכל לבקר הכל.

רמת שליטה נמוכה בתשתיות. פתרון: רשום מלאי של כל השירותים והגישה ביניהם.

זה יותר תהליך אדמיניסטרטיבי מאשר תהליך טכני. לפעמים יש לנו 200-300 מהדורות חדשות בשבוע, במיוחד במהלך מבצעים וחגים. יתר על כן, זה מיועד רק לצוות אחד של DevOps שלנו. עם כל כך הרבה מהדורות, אי אפשר לראות אילו יציאות, כתובות IP ואינטגרציות נחוצות. לכן, נזקקנו למנהלי שירות שעברו הכשרה מיוחדת ששאלו את הצוותים: "מה יש בכלל ולמה העלתם את זה?"

אחרי כל מה שהשקנו, מהנדס רשת בשנת 2019 החל להיראות כך.

קוֹנסוּל

החלטנו שנכניס את כל מה שמצאנו בעזרת מנהלי שירות לקונסול ומשם נכתוב חוקי iptables.

איך החלטנו לעשות את זה?

• נאסוף את כל השירותים, הרשתות והמשתמשים.
• בואו ניצור חוקי iptables המבוססים עליהם.
• אנחנו עושים שליטה אוטומטית.
• ....
• רווח.

Consul הוא לא API מרוחק, הוא יכול לרוץ בכל צומת ולכתוב ל-iptables. כל מה שנותר הוא לבוא עם בקרה אוטומטית שינקה דברים מיותרים, ורוב הבעיות ייפתרו! את השאר נסדר תוך כדי.

למה קונסול?

הוכיח את עצמו היטב. בשנים 2014-15, השתמשנו בו כחלק אחורי עבור Vault, שבו אנו מאחסנים סיסמאות.

לא מאבד נתונים. במהלך השימוש, קונסול לא איבד נתונים במהלך תאונה אחת. זהו יתרון עצום עבור מערכת ניהול חומת אש.

חיבורי P2P מאיצים את התפשטות השינוי. עם P2P, כל השינויים מגיעים במהירות, אין צורך לחכות שעות.

REST API נוח. שקלנו גם את Apache ZooKeeper, אבל אין לו REST API, אז תצטרך להתקין קביים.

עובד גם ככספת מפתחות (KV) וגם כספרייה (גילוי שירות). אתה יכול לאחסן שירותים, קטלוגים ומרכזי נתונים בבת אחת. זה נוח לא רק לנו, אלא גם לצוותים שכנים, כי כשבונים שירות גלובלי, אנחנו חושבים בגדול.

נכתב ב-Go, שהוא חלק מחסנית Wargaming. אנחנו אוהבים את השפה הזו, יש לנו הרבה מפתחי Go.

מערכת ACL עוצמתית. ב-Consul, אתה יכול להשתמש ב-ACL כדי לשלוט מי כותב מה. אנו מבטיחים שכללי חומת האש לא יחפפו לשום דבר אחר ולא יהיו לנו בעיות עם זה.

אבל לקונסול יש גם חסרונות.

• לא משתנה בתוך מרכז נתונים אלא אם יש לך גרסה עסקית. זה ניתן להרחבה רק לפי פדרציה.
• תלוי מאוד באיכות הרשת ובעומס השרת. Consul לא יעבוד כמו שצריך כשרת בשרת עמוס אם יש לאגים ברשת, למשל, מהירות לא אחידה. זה נובע מחיבורי P2P ומודלים של הפצה עדכונים.
• קושי במעקב אחר זמינות. בסטטוס קונסול הוא יכול לומר שהכל בסדר, אבל הוא מת מזמן.

פתרנו את רוב הבעיות הללו תוך כדי שימוש בקונסול, וזו הסיבה שבחרנו בה. לחברה יש תוכניות לגיבוי חלופי, אבל למדנו להתמודד עם בעיות וכרגע אנחנו גרים עם קונסול.

איך עובד קונסול

נתקין שלושה עד חמישה שרתים במרכז נתונים מותנה. שרת אחד או שניים לא יעבדו: הם לא יוכלו לארגן מניין ולהחליט מי צודק ומי טועה כאשר הנתונים אינם תואמים. יותר מחמישה לא הגיוני, הפרודוקטיביות תרד.

לקוחות מתחברים לשרתים בכל סדר: אותם סוכנים, רק עם הדגל server = false.

לאחר מכן, הלקוחות מקבלים רשימה של חיבורי P2P ובונים ביניהם קשרים.

ברמה הגלובלית, אנו מחברים מספר מרכזי נתונים. הם גם מחברים P2P ומתקשרים.

כאשר אנו רוצים לאחזר נתונים ממרכז נתונים אחר, הבקשה עוברת משרת לשרת. תכנית זו נקראת פרוטוקול Serf. פרוטוקול Serf, כמו קונסול, פותח על ידי HashiCorp.

כמה עובדות חשובות על קונסול

לקונסול יש תיעוד שמתאר איך זה עובד. אתן רק עובדות נבחרות שכדאי לדעת.

שרתי קונסול בוחרים מאסטר מבין הבוחרים. קונסול בוחר מאסטר מרשימת השרתים עבור כל מרכז נתונים, וכל הבקשות עוברות רק אליו, ללא קשר למספר השרתים. הקפאת מאסטר אינה מובילה לבחירה מחדש. אם המאסטר לא נבחר, בקשות לא מטופלות על ידי אף אחד.

רצית קנה מידה אופקי? סליחה, לא.

בקשה למרכז נתונים אחר עוברת ממאסטר למאסטר, ללא קשר לאיזה שרת היא הגיעה. המאסטר שנבחר מקבל 100% מהעומס, למעט העומס בבקשות העברה. לכל השרתים במרכז הנתונים יש עותק עדכני של הנתונים, אך רק אחד מגיב.

הדרך היחידה לבצע קנה מידה היא לאפשר מצב מעופש בלקוח.

במצב מיושן, אתה יכול להגיב ללא מניין. זהו מצב בו אנו מוותרים על עקביות הנתונים, אבל קוראים קצת יותר מהר מהרגיל, וכל שרת מגיב. באופן טבעי, הקלטה רק דרך המאסטר.

קונסול אינו מעתיק נתונים בין מרכזי נתונים. כאשר מרכיבים פדרציה, לכל שרת יהיו נתונים משלו בלבד. עבור אחרים, הוא תמיד פונה למישהו אחר.

אטומיות הפעולות אינה מובטחת מחוץ לעסקה. זכור שאתה לא היחיד שיכול לשנות דברים. אם אתה רוצה את זה אחרת, בצע עסקה עם מנעול.

פעולות החסימה אינן מבטיחות נעילה. הבקשה עוברת ממאסטר למאסטר, ולא ישירות, כך שאין ערובה שהחסימה תעבוד כאשר תחסום, למשל, במרכז נתונים אחר.

ACL גם לא מבטיחה גישה (במקרים רבים). ייתכן שה-ACL לא יעבוד מכיוון שהוא מאוחסן במרכז נתונים פדרציה אחד - במרכז הנתונים של ה-ACL (Primary DC). אם ה-DC לא עונה לך, ה-ACL לא יעבוד.

מאסטר קפוא אחד יגרום לכל הפדרציה לקפוא. לדוגמה, יש 10 מרכזי נתונים בפדרציה, ולאחד יש רשת גרועה, וראש אחד נכשל. כל מי שמתקשר איתו יתקע במעגל: יש בקשה, אין לה מענה, השרשור קופא. אין דרך לדעת מתי זה יקרה, רק בעוד שעה או שעתיים כל הפדרציה תיפול. אין שום דבר שאתה יכול לעשות בקשר לזה.

סטטוס, מניין ובחירות מטופלים בשרשור נפרד. בחירה חוזרת לא יקרה, הסטטוס לא יראה כלום. אתה חושב שיש לך קונסול חי, אתה שואל וכלום לא קורה - אין תשובה. יחד עם זאת, הסטטוס מראה שהכל בסדר.

נתקלנו בבעיה זו ונאלצנו לבנות מחדש חלקים ספציפיים של מרכזי נתונים כדי להימנע ממנה.

לגרסה העסקית של Consul Enterprise אין חלק מהחסרונות לעיל. יש לו פונקציות שימושיות רבות: בחירת בוחרים, הפצה, קנה מידה. יש רק "אבל" אחד - מערכת הרישוי למערכת מבוזרת היא יקרה מאוד.

פריצה לחיים: rm -rf /var/lib/consul - תרופה לכל המחלות של הסוכן. אם משהו לא עובד בשבילך, פשוט מחק את הנתונים שלך והורד את הנתונים מעותק. סביר להניח שהקונסול יעבוד.

BEFW

עכשיו בואו נדבר על מה שהוספנו לקונסול.

BEFW הוא ראשי תיבות של BackEndFכַּעַסWאת כל. הייתי צריך שם למוצר איכשהו כשיצרתי את המאגר כדי להכניס אליו את התחייבויות הבדיקה הראשונות. השם הזה נשאר.

תבניות כללים

הכללים כתובים בתחביר iptables.

• -N BEFW
• -P ירידת קלט
• -A INPUT -m state-state RELATED,STABLISHED -j קבל
• -A INPUT -i lo -j קבל
• -A קלט -j BEFW

הכל נכנס לרשת BEFW, מלבד ESTABLISHED, RELATED ומארח מקומי. התבנית יכולה להיות כל דבר, זו רק דוגמה.

כיצד BEFW שימושי?

שירותים

יש לנו שירות, תמיד יש לו פורט, צומת עליו הוא פועל. מהצומת שלנו, אנחנו יכולים לשאול את הסוכן באופן מקומי ולגלות שיש לנו שירות כלשהו. אתה יכול גם לשים תגים.

כל שירות שפועל ורשום אצל Consul הופך לכלל iptables. יש לנו SSH - יציאה פתוחה 22. הסקריפט של Bash פשוט: curl ו-iptables, אין צורך בשום דבר אחר.

לקוחות

איך לפתוח גישה לא לכולם, אלא באופן סלקטיבי? הוסף רשימות IP לאחסון KV לפי שם שירות.

לדוגמה, אנו רוצים שכולם ברשת העשירית יוכלו לגשת לשירות SSH_TCP_22. להוסיף שדה TTL קטן אחד? ועכשיו יש לנו אישורים זמניים, למשל, ליום אחד.

גישה

אנו מחברים שירותים ולקוחות: יש לנו שירות, אחסון KV מוכן לכל אחד. כעת אנו נותנים גישה לא לכולם, אלא באופן סלקטיבי.

הקבוצה

אם נכתוב אלפי כתובות IP לגישה בכל פעם, נתעייף. בואו נמציא קבוצות - תת-קבוצה נפרדת ב-KV. בואו נקרא לזה כינוי (או קבוצות) ונאחסן שם קבוצות לפי אותו עיקרון.

בואו נתחבר: עכשיו אנחנו יכולים לפתוח SSH לא ספציפית עבור P2P, אלא עבור קבוצה שלמה או מספר קבוצות. באותו אופן, יש TTL - ניתן להוסיף לקבוצה ולהסיר מהקבוצה באופן זמני.

Интеграция

הבעיה שלנו היא הגורם האנושי והאוטומציה. עד כה פתרנו את זה כך.

אנחנו עובדים עם Puppet, ומעבירים אליהם את כל מה שקשור למערכת (קוד אפליקציה). Puppetdb (רגיל PostgreSQL) מאחסן רשימה של שירותים הפועלים שם, ניתן למצוא אותם לפי סוג משאב. שם תוכל לברר מי מגיש בקשה לאן. יש לנו גם מערכת בקשות משיכה ובקשות מיזוג בשביל זה.

כתבנו befw-sync, פתרון פשוט שעוזר בהעברת נתונים. ראשית, ניתן לגשת לעוגיות סינכרון על ידי puppetdb. שם מוגדר API של HTTP: אנו מבקשים אילו שירותים יש לנו, מה צריך לעשות. ואז הם מגישים בקשה לקונסול.

האם יש אינטגרציה? כן: הם כתבו את הכללים ואפשרו לקבל בקשות משיכה. האם אתה צריך יציאה מסוימת או להוסיף מארח לקבוצה כלשהי? משוך בקשה, בדוק - לא יותר "מצא 200 ACLs אחרים ונסה לעשות משהו בנידון."

אופטימיזציה

פינג למארח מקומי עם שרשרת כללים ריקה לוקח 0,075 אלפיות השנייה.

בואו נוסיף 10 כתובות iptables לשרשרת הזו. כתוצאה מכך, הפינג יגדל פי 000: iptables הוא ליניארי לחלוטין, עיבוד כל כתובת לוקח קצת זמן.

עבור חומת אש שבה אנו מעבירים אלפי ACLs, יש לנו הרבה כללים, וזה מציג חביון. זה רע לפרוטוקולי משחקים.

אבל אם נשים 10 כתובות ב-ipset הפינג אפילו יקטן.

הנקודה היא ש-"O" (מורכבות האלגוריתם) עבור ipset תמיד שווה ל-1, לא משנה כמה כללים יש. נכון, יש מגבלה - לא יכולים להיות יותר מ-65535 כללים. בינתיים אנחנו חיים עם זה: אפשר לשלב אותם, להרחיב אותם, ליצור שני ipsets באחד.

אחסון

המשך הגיוני של תהליך האיטרציה הוא אחסון מידע על לקוחות עבור השירות ב-ipset.

עכשיו יש לנו את אותו SSH, ואנחנו לא כותבים 100 כתובות IP בבת אחת, אלא מגדירים את השם של ה- ipset איתו אנחנו צריכים לתקשר, ואת הכלל הבא DROP. אפשר להמיר אותו לכלל אחד "מי לא כאן, DROP", אבל זה יותר ברור.

עכשיו יש לנו חוקים וסטים. המשימה העיקרית היא ליצור סט לפני כתיבת הכלל, כי אחרת iptables לא יכתבו את הכלל.

תכנית כללית

בצורה של דיאגרמה, כל מה שאמרתי נראה כך.

אנחנו מתחייבים ל-Puppet, הכל נשלח למארח, שירותים כאן, 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. עבור כל משתמש אנו יוצרים קבוצה לפי שם משתמש ומציבים בה IP עם TTL השווה ל-dhcp.lease שלו - ברגע שהוא יפוג, הכלל ייעלם.

כעת אנו יכולים לפתוח גישה לשירותים, כמו קבוצות אחרות, לפי שם משתמש. הורדנו את הכאב משמות מארחים כשהם משתנים, והורדנו את הנטל ממהנדסי הרשת כי הם כבר לא צריכים את סיסקו. כעת המהנדסים עצמם רושמים גישה בשרתים שלהם.

בידוד

במקביל התחלנו לפרק את הבידוד. מנהלי שירות ערכו מלאי, וניתחנו את כל הרשתות שלנו. בואו נחלק אותם לאותן קבוצות, ובשרתים הדרושים נוספו הקבוצות, למשל, כדי להכחיש. עכשיו אותו בידוד בימוי מסתיים בכללים_הכחשה של ההפקה, אבל לא בהפקה עצמה.

הסכימה פועלת במהירות ובפשטות: אנו מסירים את כל ה-ACL מהשרתים, פורקים את החומרה ומצמצמים את מספר ה-VLAN המבודדים.

בקרת יושרה

בעבר, היה לנו טריגר מיוחד שדיווח כאשר מישהו שינה כלל חומת אש באופן ידני. כתבתי לינטר ענק לבדיקת חוקי חומת אש, זה היה קשה. שלמות נשלטת כעת על ידי BEFW. הוא מבטיח בקנאות שהכללים שהוא קובע לא ישתנו. אם מישהו ישנה את חוקי חומת האש, זה ישנה הכל בחזרה. "הגדרתי במהירות פרוקסי כדי שאוכל לעבוד מהבית" - אין יותר אפשרויות כאלה.

BEFW שולט ב-ipset מהשירותים ורשום ב-befw.conf, כללי השירותים בשרשרת BEFW. אבל זה לא מפקח על שרשראות וכללים אחרים ושאר אי-סטים.

הגנה מפני התרסקות

BEFW תמיד מאחסן את המצב הטוב האחרון הידוע ישירות במבנה הבינארי state.bin. אם משהו משתבש, הוא תמיד חוזר למצב.bin זה.

זהו ביטוח מפני פעולת קונסול לא יציבה, כאשר הוא לא שלח נתונים או שמישהו טעה והשתמש בכללים שלא ניתן ליישם. כדי להבטיח שלא נישאר ללא חומת אש, BEFW יחזור למצב העדכני ביותר אם תתרחש שגיאה בכל שלב.

במצבים קריטיים, זוהי ערובה לכך שנישאר עם חומת אש תקינה. אנחנו פותחים את כל הרשתות האפורות בתקווה שהמנהל יבוא ויתקן את זה. מתישהו אני אשים את זה בהגדרות, אבל עכשיו יש לנו רק שלוש רשתות אפורות: 10/8, 172/12 ו- 192.168/16. בתוך הקונסול שלנו, זוהי תכונה חשובה שעוזרת לנו להתפתח הלאה.

הדגמה: במהלך הדוח, Ivan מדגים את מצב ההדגמה של 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=אחר. כפי שאמרתי, אנחנו חושבים שאנחנו מבקשים כמה נתונים, אבל או שנקבל נתונים או שגיאה. אנחנו יכולים לעשות זאת דרך קונסול מקומית, אבל במקרה זה שניהם יקפאו.

לקוח הקונסול המקומי הוא מעטפת על ה-API של HTTP. אבל זה פשוט נתקע ולא מגיב ל-Ctrl+C, או Ctrl+Z, או משהו, בלבד kill -9 בקונסולה הבאה. נתקלנו בזה כשבנינו אשכול גדול. אבל עדיין אין לנו פתרון; אנחנו מתכוננים לתקן את השגיאה הזו בקונסול.

מנהיג הקונסול לא מגיב. המאסטר שלנו במרכז הנתונים לא מגיב, אנחנו חושבים: "אולי אלגוריתם הבחירה מחדש יעבוד עכשיו?"

לא, זה לא יעבוד, והניטור לא יראה כלום: הקונסול יגיד שיש מדד מחויבות, נמצא מנהיג, הכל בסדר.

איך אנחנו מתמודדים עם זה? service consul restart בקרון כל שעה. אם יש לך 50 שרתים, לא נורא. כשיהיו 16 כאלה, תבינו איך זה עובד.

מסקנה

כתוצאה מכך, קיבלנו את היתרונות הבאים:

• כיסוי של 100% של כל מכונות לינוקס.
• מהירות.
• אוטומציה.
• שחררנו את מהנדסי החומרה והרשת מעבדות.
• הופיעו אפשרויות אינטגרציה שהן כמעט בלתי מוגבלות: אפילו עם Kubernetes, אפילו עם Ansible, אפילו עם Python.

חסרונות: קונסול, איתו אנחנו צריכים לחיות עכשיו, והעלות הגבוהה מאוד של טעות. כדוגמה, פעם אחת ב-6:XNUMX (פריים טיים ברוסיה) ערכתי משהו ברשימות הרשתות. בדיוק בנינו בידוד ב-BEFW באותו זמן. עשיתי טעות איפשהו, נראה שציינתי את המסכה הלא נכונה, אבל הכל נפל תוך שתי שניות. הניטור נדלק, איש התמיכה התורן בא בריצה: "יש לנו הכל!" ראש המחלקה האפיר כשהסביר לבית העסק מדוע זה קרה.

עלות הטעות היא כל כך גבוהה שהמצאנו הליך מניעה מורכב משלנו. אם אתה מיישם את זה באתר ייצור גדול, אתה לא צריך לתת אסימון מאסטר על קונסול לכולם. זה ייגמר רע.

עלות. כתבתי קוד ל-400 שעות לבד. הצוות שלי של 4 אנשים מקדיש 10 שעות בחודש על תמיכה לכולם. בהשוואה למחיר של כל חומת אש מהדור החדש, זה בחינם.

תוכניות. התוכנית ארוכת הטווח היא למצוא תחבורה חלופית כדי להחליף או להשלים את קונסול. אולי זה יהיה קפקא או משהו דומה. אבל בשנים הקרובות נחיה על קונסול.

תוכניות מיידיות: אינטגרציה עם Fail2ban, עם ניטור, עם nftables, אולי עם הפצות אחרות, מדדים, ניטור מתקדם, אופטימיזציה. גם התמיכה של Kubernetes נמצאת איפשהו בתוכניות, כי עכשיו יש לנו כמה אשכולות והרצון.

עוד מהתוכניות:

• חיפוש חריגות בתנועה;
• ניהול מפות רשת;
• תמיכת Kubernetes;
• הרכבת חבילות לכל המערכות;
• Web-UI.

אנו עובדים כל הזמן על הרחבת התצורה, הגדלת מדדים ואופטימיזציה.

הצטרפו לפרויקט. הפרויקט התברר כמגניב, אבל, למרבה הצער, זה עדיין פרויקט של אדם אחד. בוא ל GitHub ולנסות לעשות משהו: להתחייב, לבדוק, להציע משהו, לתת את ההערכה שלך.

בינתיים אנחנו מתכוננים Saint HighLoad++, שיתקיים ב-6 וב-7 באפריל בסנט פטרסבורג, ואנו מזמינים מפתחים של מערכות עומס גבוה להגיש בקשה לדוח. דוברים מנוסים כבר יודעים מה לעשות, אבל למי שנודע לדבר חדש אנחנו ממליצים לפחות לנסות. להשתתפות בכנס כדובר יש מספר יתרונות. אתה יכול לקרוא אילו מהם, למשל, בסוף במאמר זה.

מקור: www.habr.com