כיצד להשתלט על תשתית הרשת שלך. פרק שני. ניקיון ותיעוד

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

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

עכשיו לא נדבר על ביקורת אבטחה - זה יהיה הנושא של החלק השלישי.

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

המצב האידיאלי הוא מתי

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

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

במקרה הגרוע ביותר, יהיה לך

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

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

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

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

סט מסמכים

נתחיל עם דוגמה.

להלן כמה מסמכים שנוצרים בדרך כלל ב-Cisco Systems במהלך התכנון.

CR – דרישות הלקוח, דרישות הלקוח (מפרט טכני).
הוא נוצר במשותף עם הלקוח וקובע את דרישות הרשת.

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

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

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

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

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

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

אלו המסמכים הבאים:

• תרשים (יומן) של מיתוג פיזי (כבלים)
• דיאגרמת רשת או דיאגרמות עם מידע חיוני על L2/L3

דיאגרמת מיתוג פיזית

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

במקרה זה, הבעיה נפתרת בחלקה על ידי הגישה הבאה.

• השתמש בתיאור בממשק כדי לתאר מה מחובר אליו
• כיבוי מנהלתי של כל יציאות ציוד הרשת הלא מחוברות

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

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

האפשרות האידיאלית היא להשתמש ביישומים המיועדים לעבוד עם מידע מסוג זה. אבל אתה יכול להגביל את עצמך לטבלאות פשוטות (לדוגמה, ב-Excel) או להציג את המידע שאתה רואה צורך בדיאגרמות L1/L2.

חשוב!

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

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

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

דיאגרמות רשת

אין גישה אוניברסלית לציור דיאגרמות.

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

באלמנטים פיזיים אנו מתכוונים

• ציוד פעיל
• ממשקים/יציאות של ציוד פעיל

תחת לוגי -

• התקנים לוגיים (N7K VDC, Palo Alto VSYS, ...)
• VRF
• וילנס
• ממשקי משנה
• מנהרות
• אזורים
• ...

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

• מרכז הנתונים
• לאינטרנט
• WAN
• גישה מרחוק
• LAN משרדי
• DMZ
• ...

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

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

• כיסוי
• תחתית L1/L2
• תחתית L3

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

ערכת ניתוב

לכל הפחות, תרשים זה צריך לשקף

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

כמו כן, סכימת L2 (OSI) שימושית לעתים קרובות.

סכימת L2 (OSI)

תרשים זה עשוי להראות את המידע הבא:

• איזה VLAN
• אילו יציאות הן יציאות מטען
• אילו יציאות מצטברים לתוך ערוץ אתר (ערוץ יציאה), ערוץ יציאה וירטואלי
• באילו פרוטוקולי STP משתמשים ובאילו מכשירים
• הגדרות STP בסיסיות: גיבוי שורש/שורש, עלות STP, עדיפות יציאה
• הגדרות STP נוספות: מגן/מסנן BPDU, מגן שורש...

טעויות עיצוב אופייניות

דוגמה לגישה גרועה לבניית רשת.

ניקח דוגמה פשוטה של ​​בניית LAN משרדי פשוט.

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

מה כל כך קשה בחיבור מתגים אחד לשני, הגדרת VLAN, ממשקי SVI (במקרה של מתגי L3) והגדרת ניתוב סטטי?

הכל יעבוד.

אבל במקביל, שאלות הקשורות

• אבטחה
• הזמנה
• קנה מידה רשת
• פִּריוֹן
• תפוקה
• מהימנות
• ...

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

טעויות עיצוב נפוצות של L1 (OSI).

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

הייתי גם מסווג כשגיאות מסוג L1 הקשורות למשאבים של הציוד המשמש, למשל,

• רוחב פס לא מספיק
• TCAM לא מספיק בציוד (או שימוש לא יעיל בו)
• ביצועים לא מספקים (לעתים קרובות קשור לחומת אש)

טעויות עיצוב נפוצות של L2 (OSI).

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

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

• קוטר רשת STP גדול, שעלול להוביל לסערות שידור
• שורש STP ייקבע באופן אקראי (בהתבסס על כתובת mac) ונתיב התעבורה יהיה לא אופטימלי
• יציאות המחוברות למארחים לא יוגדרו כ-edge (portfast), מה שיוביל לחישוב STP מחדש בעת הפעלה/כיבוי של תחנות קצה
• הרשת לא תפולח ברמת L1/L2, וכתוצאה מכך בעיות עם מתג כלשהו (לדוגמה, עומס יתר) יובילו לחישוב מחדש של טופולוגיית ה-STP ולעצירת התעבורה בכל ה-VLAN בכל המתגים (כולל אחד קריטי מנקודת המבט של מגזר שירותי המשכיות)

דוגמאות לטעויות בעיצוב L3 (OSI).

כמה טעויות אופייניות של רשתות מתחילות:

• שימוש תכוף (או שימוש בלבד) בניתוב סטטי
• שימוש בפרוטוקולי ניתוב לא אופטימליים עבור עיצוב נתון
• פילוח רשת לוגי לא אופטימלי
• שימוש לא אופטימלי במרחב הכתובות, שאינו מאפשר צבירת מסלולים
• אין מסלולי גיבוי
• אין הזמנה לשער ברירת מחדל
• ניתוב א-סימטרי בעת בנייה מחדש של מסלולים (יכול להיות קריטי במקרה של NAT/PAT, חומות אש תקינות)
• בעיות עם MTU
• כאשר מסלולים נבנים מחדש, התנועה עוברת דרך אזורי אבטחה אחרים או אפילו חומות אש אחרות, מה שמוביל להורדת תנועה זו
• מדרגיות טופולוגיה לקויה

קריטריונים להערכת איכות העיצוב

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

• מדרגיות
  לדוגמה, אתה מחליט להוסיף מרכז נתונים נוסף. כמה קל אתה יכול לעשות את זה?
• קלות שימוש (ניתנות לניהול)
  כמה קלים ובטוחים הם שינויים תפעוליים, כמו הכרזת רשת חדשה או מסלולי סינון?
• זמינות
  באיזה אחוז מהזמן המערכת שלך מספקת את רמת השירות הנדרשת?
• בִּטָחוֹן
  עד כמה הנתונים המועברים מאובטחים?
• מחיר

שינויים

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

• באיזו קלות ניתן לתקן את הבעיה הזו
• כמה סיכון היא נושאת?

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

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

מקור: www.habr.com