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

הניע אותי לפוסט הזה זו ההערה.

אני מצטט את זה כאן:

קאלמן היום בשעה 18:53

הייתי מרוצה מהספק היום. יחד עם עדכון מערכת חסימת האתרים נאסר ה-mailer שלו mail.ru, אני מתקשר לתמיכה טכנית מהבוקר, אבל הם לא יכולים לעשות כלום. הספק קטן, וכנראה שספקים בעלי דירוג גבוה יותר חוסמים אותו. שמתי לב גם להאטה בפתיחה של כל האתרים, אולי התקינו איזה DLP עקום? בעבר לא היו בעיות בגישה. ההרס של RuNet מתרחש ממש לנגד עיני...

העובדה היא שנראה שאנחנו אותו ספק :)

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

מה להלן יתחלק לשני חלקים:

1. הסיבות לבעיות הנוכחיות שלנו עם mail.ru והמסע המרגש למצוא אותן
2. קיומה של ISP במציאות של היום, היציבות של RuNet הריבוני.

בעיות נגישות עם mail.ru

אה, זה סיפור די ארוך.

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

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

לפני מספר ימים הפעלנו עליו סינון אסור (תוך השארת המערכת הישנה פועלת) - נראה היה שהכל תקין.

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

אבל היום, לאחר שהפעלת NAT על הציוד עבור החלק הבא של המנויים, כבר מהבוקר עמדנו בפני מספר הגון של תלונות על חוסר זמינות או זמינות חלקית mail.ru ומשאבים אחרים של Mail Ru Group.

הם התחילו לבדוק: משהו איפשהו לפעמים, מדי פעם שולח TCP RST בתגובה לבקשות אך ורק לרשתות mail.ru. יתר על כן, הוא שולח TCP RST שגוי (ללא ACK), ללא ספק מלאכותי. כך זה נראה:

באופן טבעי, המחשבות הראשונות היו על הציוד החדש: DPI נורא, אין בו אמון, אי אפשר לדעת מה הוא יכול לעשות - אחרי הכל, TCP RST הוא דבר נפוץ למדי בקרב כלי חסימה.

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

ראשית, יש לנו קישורים שפויים מספיק כדי שלא נצטרך לסבול ככה :)

שנית, אנחנו מחוברים לכמה IX במוסקבה, והתנועה ל-mail.ru עוברת דרכם - ואין להם לא אחריות ולא כל מניע אחר לסנן תנועה.

חצי היום הבא הוקדש למה שנקרא שמאניזם - יחד עם ספק הציוד, שעליו אנו מודים להם, הם לא ויתרו :)

• הסינון הושבת לחלוטין
• NAT הושבת באמצעות הסכימה החדשה
• מחשב הבדיקה הונח בבריכה מבודדת נפרדת
• כתובת ה-IP השתנתה

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

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

שים לבבשלב זה, מישהו יכול לומר: אבל זה היה הרבה יותר קל לקחת dump לא ממחשב הבדיקה, אלא מהכביש המהיר מעל ה-DPI?

לא, למרבה הצער, לקחת dump (ואפילו רק לשקף) 40+gbps זה בכלל לא טריוויאלי.

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

בדקתי באיזה IX עוברת כעת התעבורה לרשתות MRG ופשוט ביטלתי את הפגישות של ה-bgp אליו. והנה - הנה! - הכל חזר מיד לקדמותו 🙁

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

מאידך גיסא:

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

- צירוף מקרים משמח להפליא של נסיבות: חומרה מורכבת חדשה שאינה מהימנה במיוחד וממנה לא ברור מה ניתן לצפות - מותאמת במיוחד לחסימת משאבים, כולל TCP RSTs

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

זה היה ניסיון קטן להצדיק את עצמי, אנא הבינו וסלחו :)

נ.ב: אני בכוונה לא שם ליצרן של DPI/NAT או IX (למעשה, אין לי אפילו תלונות מיוחדות עליהם, העיקר להבין מה זה היה)

המציאות של היום (כמו גם של אתמול ושלשום) מנקודת מבטו של ספק אינטרנט

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

בחלק זה, אנסה לתאר את ה"התפתחות" של ליבת הרשת של ספק שירותי אינטרנט טיפוסי בעשר השנים האחרונות.

לפני עשר שנים.

באותם זמנים מבורכים, הליבה של רשת ספק יכולה להיות פשוטה ואמינה כמו פקק תנועה:

בתמונה מאוד מאוד פשוטה זו, אין טראנקים, טבעות, ניתוב ip/mpls.

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

סכימה כזו היא מאוד מאוד קלה לשמור גם ב-L3 (ניתוב דינמי) וגם ב-L2 (MPLS).

אתה יכול להתקין N+1 מכל דבר: גישה לשרתים, מתגים, גבולות - ובדרך זו או אחרת לשמור אותם למעבר אוטומטי לכשל.

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

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

יש כאן גישות שונות.

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

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

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

אגב, לגבי ה-DPI של אז והיוםאגב, רבים שרכשו את מערכות ה-DPI הקיימות אז בשוק כבר זרקו אותן. ובכן, הם לא מיועדים לכך: מאות אלפי כתובות, עשרות אלפי כתובות URL.

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

הייתי רוצה להיות גאה, אבל קצת עצוב =)

עכשיו הכל נראה כך:

עוד כמה שנים לכולם כבר היו רואי חשבון; היו יותר ויותר משאבים ברישום. עבור ציוד ישן יותר (לדוגמה, Cisco 7600), סכימת "סינון הצד" פשוט הפכה לבלתי ישימה: מספר המסלולים ב-76 פלטפורמות מוגבל למשהו כמו תשע מאות אלף, בעוד שמספר מסלולי ה-IPv4 לבדו היום מתקרב ל-800 אלף. ואם זה גם ipv6... וגם... כמה יש? 900000 כתובות בודדות באיסור RKN? =)

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

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

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

לפני שנה או שנתיים על פי שמועות, כמעט כל ה-FSB החלו לדרוש את התקנת הציוד בפועל SORM (בעבר, רוב הספקים ניהלו באישור הרשויות תוכנית SORM - תוכנית של אמצעים מבצעיים במקרה של צורך למצוא משהו איפשהו)

בנוסף לכסף (לא בדיוק מופקע, אבל עדיין מיליונים), SORM דרש עוד הרבה מניפולציות עם הרשת.

• SORM צריך לראות כתובות משתמש "אפורות" לפני תרגום נאט
• ל-SORM יש מספר מוגבל של ממשקי רשת

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

כלומר, בפשטות רבה, זה היה (שמאל) לעומת הפך (ימין):

עכשיו רוב הספקים דורשים גם הטמעה של SORM-3 - הכולל בין היתר רישום של שידורי nat.

למטרות אלו, היינו צריכים להוסיף גם ציוד נפרד עבור NAT לתרשים שלמעלה (בדיוק מה שנדון בחלק הראשון). יתר על כן, הוסף בסדר מסוים: מכיוון ש-SORM חייב "לראות" את התעבורה לפני תרגום כתובות, התעבורה חייבת להתנהל באופן הבא: משתמשים -> מיתוג, ליבה -> גישה לשרתים -> SORM -> NAT -> מיתוג, ליבה - > אינטרנט. כדי לעשות זאת, היינו צריכים ממש "לסובב" את זרמי התנועה לכיוון השני למטרות רווח, וזה גם היה די קשה.

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

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

וירוביה עדיין לפניה.

מקור: www.habr.com