- Zen IT Technologies
- תשתיות רשת
אף אחד לא שם לב לרשת שעובדת.
Wi-Fi שנופל תמיד באותה פינה במשרד. חומת אש עם חוקים שנוספו בשתיים בלילה לפני ארבע שנים. חדר שרתים שגדל במשך השנים בלי תכנון מסודר. בעיות רשת יכולות להישאר ככה שנים, כי כל אחת מהן בפני עצמה עדיין מאפשרת לעבוד. ביחד הן גורמות למשרד לעבוד נגד האנשים שנמצאים בו.
אנחנו מתכננים רשתות מראש: קודם סקר, אחר כך ערוצים, אחר כך מדיניות. אחרי זה בונים ומתפעלים. מנחושת ועד לענן.
הבעיה
רוב הרשתות לא תוכננו. הן הורחבו.
פעם היה תכנון. הוא התאים לחברה קטנה יותר ולמשרד אחר. כל מה שקרה מאז היה תוספת: נקודת גישה במקום שבו התלוננו הכי הרבה, חוק בחומת האש כדי לשחרר מישהו שהיה בלחץ, מתג שנקנה כשנגמרו הפורטים. כל שינוי בפני עצמו היה הגיוני. התוצאה לא.
אלה תקלות הרשת שבגללן קוראים לנו, והן חוזרות על עצמן:
-
Wi-Fi שנופל תמיד באותם מקומות.
נקודות גישה שהותקנו לפי נוחות הכבילה ולא לפי כיסוי, ערוצים שחופפים אחד לשני ולשכנים בבניין, ועוצמת שידור שהוגברה עד שאזורי הכיסוי מתחילים להפריע אחד לשני.
-
חומת אש שאף אחד לא מוכן לגעת בה.
חוקים שהצטברו לאורך שנים, כל אחד מהם נוסף מסיבה שלא נכתבה בשום מקום, ועכשיו אף אחד לא ימחק אחד מהם מחשש שמשהו יפסיק לעבוד.
-
שירותי ליבה עם תלות מעגלית.
DNS ו-NTP שהוגדרו בחיפזון, ואחר כך אחראים בשקט לשנים של תקלות אימות ותעודות שנראו כאילו אין להן שום קשר אליהם.
-
רשת אחת שטוחה.
אורחים, עובדים, מדפסות, מצלמות ו-IoT על אותו מקטע, כי ההפרדה תמיד הייתה פרויקט לרבעון הבא.
-
חדר שרתים שגדל בלי תכנון.
כבילה לא מסומנת, בלי תיעוד חיבורים, וארון שרק אדם אחד יכול לעבוד בו בביטחון.
-
אף אחד לא יודע מה השתנה.
אין טופולוגיה, אין תכנון VLAN, אין תכנון ערוצים, וציוד שעדיין רץ על הקושחה שהגיעה איתו, כי אף אחד לא בטוח מה יישבר אם ישנו אותו. כל שינוי נוסף הופך לניחוש, ואת הקודם קשה להחזיר בבטחה.
מה כוללות תשתיות רשת
- אינטרנט / WAN
- משתמשים מרוחקים
- אתרים נוספים
- רשתות בענן
הקשר זהות ומכשיר משפיע על החלטות גישה היכן שיש תמיכה
- רשת ארגונית קווית
- Wi-Fi ארגוני
- אורחים ו-IoT
- משאבים פרטיים ובענן
תפעול הרשת לאורך זמן
-
תכנון רשת אלחוטית וסקר RF
סקר חזוי עוד לפני שנקנית חומרה, על בסיס תוכניות הקומה וחומרי הבנייה ולא על בסיס איפה יש שקעים. מיקום נקודות הגישה, תכנון הערוצים ותכנון עוצמות השידור נעשים יחד, מפני שהגברת העוצמה בלי תכנון ערוצים היא מה שגורם לרוב הבעיות שהיא אמורה לפתור. הגדרת הבקר, ולאחריה סקר אימות שמוודא שהתכנון שרד את המפגש עם הבניין. כולל סביבות בצפיפות גבוהה ובמספר קומות, שבהן ההפרעה המשמעותית מגיעה בדרך כלל מהקומות שלכם עצמכם.
-
מדיניות Firewall וחשיפה לאינטרנט
סקירת מדיניות ואיחוד חוקים, כך שלכל חוק שנשאר יש סיבה ברורה. בדיקה של מה חשוף מבחוץ, והגבלת ממשקי הניהול רק למקומות שמהם באמת צריך לנהל אותם. כשמערכת חוקים גדלה במשך שנים, העבודה המועילה היא לברר מה היא מתירה בפועל לפני שמחליטים מה למחוק ממנה.
-
WAN, גישה מרחוק וקישוריות לענן
משתמשים, אתרים ומשאבים בענן לא בהכרח יושבים מאחורי Firewall אחד. גישה מרחוק יכולה להסתיים ב-Firewall במשרד, בענן או בשירות גישה ייעודי. אנחנו מתכננים ופותרים תקלות בקישוריות site-to-site והיברידית בין רשתות משרדיות לסביבות AWS ו-GCP, עם failover היכן שיש לכך הצדקה. הקמת המנהרה היא בדרך כלל לא החלק הקשה. הניתוב, טווחי הכתובות ומדיניות הסינון בדרך כלל כן. כשהמסלול הסטנדרטי לא מתאים, אנחנו בונים פתרון נקודתי, למשל jump host לסביבה פרטית.
-
רשת קווית, מיתוג והפרדת רשתות
תכנון VLAN שמפריד בין אורחים, מכשירי החברה, מדפסות, מצלמות ו-IoT, עם מדיניות בין הרשתות שמוגדרת במפורש ולא נשארת פתוחה כברירת מחדל. VLAN הופך לגבול רק במקום שבו התעבורה בין המקטעים עוברת דרך משהו שיכול לאכוף מדיניות, וזה נקבע לפי המקום שבו יושב ה-gateway. תכנון uplinks ו-trunks, תקצוב PoE שלוקח בחשבון את הצריכה האמיתית של נקודות הגישה, ומפת פורטים מתועדת כדי שהאדם הבא ימצא את מה שהוא מחפש.
-
ניתוב, כתובות IP ושירותי רשת
ניתוב פנימי ותכנון כתובות שמשאיר מקום לאתר הבא, כך ששתי סביבות שיצטרכו להתחבר בהמשך לא ישתמשו כבר באותם טווחים פרטיים. אחר כך DHCP, DNS ו-NTP מתוכננים במכוון ולא נשארים כברירת המחדל של הנתב: הגדרות DHCP אחידות בין האתרים, שרתי DNS פנימיים או מנוהלים לפי הצורך, מקורות זמן אמינים ושירותי upstream בלי תלות מעגלית. לא זוהר, אבל תקלות בשכבה הזאת גורמות לחלק מפתיע מכשלי אימות ותעודות.
-
הקמת משרדים ואתרים
משרדים חדשים, מעברים והתרחבות לקומות נוספות, מחדר השרתים ועד לעמדת העבודה. תכנון כבילה מובנית וארונות תקשורת, טכנולוגיית חדרי ישיבות ו-AV, ציוד אבטחה ו-IoT, והתיאום מול קבלנים ובעלי הנכס שקובע אם הרשת מוכנה ביום שבו האנשים מגיעים.
-
תפעול הרשת לאורך זמן
ניטור זמינות וקישוריות, עם התראות שמגיעות לאדם ולא לתיבת דואר. לצד זה, מה שמתגלה רק לאורך חודשים: תקינות הקווים, קיבולת ותצורה שהתרחקה ממה שסוכם. מעקב אחר גרסאות קושחה וסטטוס תמיכה על חומות אש, מתגים, נקודות גישה ובקרים, ולא רק בקצה הרשת, עם שמירת מצב התצורה כדי שתהיה דרך חזרה ידועה היכן שזה מעשי. טופולוגיה, מפת VLAN, תכנון ערוצים ומדריכי תפעול שמתוחזקים כחלק מהתפעול השוטף, כך שגם מי שלא בנה את הרשת יכול להבין איך היא עובדת.
גישה לרשת, זהות ומצב המכשיר
גישה לרשת לא חייבת להיות שכל מה שמתחבר לשקע, או כל מי שיודע את סיסמת ה-Wi-Fi, נמצא ברשת הארגונית. היכן שהציוד ומכשירי הקצה תומכים בכך, פורט, רשת אלחוטית או שירות גישה מרחוק יכולים לבדוק מול ספק הזהויות, דרך RADIUS, 802.1X או שירות ZTNA.
הבעלות חשובה יותר מהמנגנון. זהות היא המקום שממנו מגיעים המשתמש והקבוצות שלו. ניהול מכשירים הוא מה שיכול להגיד משהו על המכשיר. הרשת, או פלטפורמת הגישה שלפניה, אוכפת את ההחלטה על החיבור. אנחנו בונים את האינטגרציה ביניהם; אף אחד מהם לא מחזיק לבדו בכל הבקרה.
מסמכים טכניים באנגלית
למה רשתות Wi-Fi במשרד נכשלות בקיבולת ולא בכיסוי
הוספת נקודות גישה לקומה עמוסה בדרך כלל דווקא מאטה את הרשת.
עוד בנושא
איך זה עובד
-
מיפוי.
מה באמת פרוס, איך הוא מוגדר, ואיך התעבורה זורמת בפועל: טופולוגיה, קווים, ניתוב, גרסאות וסביבת ה-RF היכן שיש Wi-Fi. מתחילים מהתסמינים ולא מהסיבה שמישהו כבר הניח.
-
תכנון.
טופולוגיה, כתובות וניתוב, המקטעים והמדיניות ביניהם, איך האתרים וסביבות הענן מתחברים, יתירות היכן שיש לכך הצדקה, ותכנון ה-Wi-Fi. כתוב ומאושר לפני שמזמינים חומרה.
-
פריסה.
מכינים ומגדירים מראש, עם מועד מעבר מתואם, בדיקות ודרך חזרה. כשהפסקה בשירות היא בלתי נמנעת, היא מתוכננת ומתואמת מראש ולא מתגלה תוך כדי השינוי.
-
תחזוקה.
ניטור והתאמות ככל שהאתרים וכמות האנשים משתנים, עם מעקב אחר קושחה, מצב התצורה וקיבולת. תכנון הערוצים שורד גם כשמישהו אחר נוגע בו, כי הוא מתועד.
דוגמאות מהשטח
-
פריסת Wi-Fi משרדית שהפסיקה לייצר קריאות.
חברת תשתיות AI
סקר RF חזוי, תכנון ערוצים ועוצמות שידור, ובנייה מחדש של הבקר. תור קריאות ה-Wi-Fi התרוקן ונשאר ריק.
-
רשת משרדית רב-קומתית שתוכננה לפני הבנייה.
חברת טכנולוגיה
מיקום נקודות הגישה, תכנון הערוצים והמיתוג תוכננו מתוך תוכניות הקומה עוד לפני הבנייה, כך שהרשת הוקמה יחד עם המשרד ולא תוקנה אחרי שכולם כבר נכנסו.
-
שירותי רשת ליבה שנבנו מחדש בכל האתרים.
חברת שירותים פיננסיים
שירותי ה-DNS וה-NTP הפנימיים עברו מתצורה עם תלות מעגלית לשירותים פנימיים ייעודיים, הופצו על פני האתרים דרך DHCP, והתכנון יחד עם מדריך תפעול הועברו לצוות הפנימי.
לפי בקשה, ניתן לתאם שיחה פרטית עם לקוחות או ממליצים, בכפוף להסכמתם מראש. דוגמאות הלקוחות כאן אנונימיות במכוון.
למי זה מתאים
לחברות עם משרד פיזי שבהן הרשת הפכה לנושא חוזר בשיחות שהיא בכלל לא אמורה להופיע בהן: בסטנדאפ, בישיבת הנהלה או ב-All Hands. לצוותים שמקימים משרד חדש, מתרחבים לקומה נוספת, או נכנסים לבניין שבו הכבילה של הדייר הקודם הפכה לבעיה שלהם.
וגם לחברות שחושדות שהתשובה לתלונה כרונית היא לא עוד חומרה. בדרך כלל היא באמת לא. הוספת נקודות גישה לפריסה שלא תוכננה נכון מחמירה בדרך כלל את המצב, ואנחנו מעדיפים לעשות סקר ולהגיד את זה.
לא צריך משרד כדי להזדקק לזה. VPN, ניתוב, קישוריות לענן וגישה מרחוק עדיין דורשים מישהו שיתכנן את המסלול ויפתור בו תקלות. הצד הרשתי של הבעיה הוא שלנו; ארכיטקטורת אפליקציות והנדסת פלטפורמה נשארות מחוץ לשירות הזה.
שאלות נפוצות
-
צריך סקר, או שאפשר פשוט להוסיף עוד נקודות גישה?
בדרך כלל כן. „ה-Wi-Fi לא עובד טוב” יכול לתאר כמה בעיות שונות, וכיסוי הוא רק אחת מהן. נקודות גישה על אותו ערוץ עלולות לחלוק את אותו airtime, ולכן הוספת חומרה לפריסה שלא תוכננה עלולה להחמיר את התסמין במקום לשפר אותו. סקר מראה מה באמת קורה, ולא פעם מקטין את כמות החומרה שצריך.
-
ה-Wi-Fi אצלנו איטי. זו בעיית אינטרנט או בעיית רשת?
אלה שתי בעיות שונות עם פתרונות שונים, והתשובה מתבררת בדרך כלל מהר. קו שנמצא ברוויה, QoS מוגדר לא נכון, סביבת RF שבה המכשירים נאלצים לשדר שוב ושוב, ושרת DNS שמוסיף השהיה לכל בקשה, כולם נראים בדיוק אותו הדבר למי שחווה אותם: „ה-Wi-Fi איטי”. לברר איזה מהם זה לוקח הרבה פחות זמן ממה שרוב האנשים מצפים.
-
אפשר לחבר את המשרד שלנו ל-AWS או ל-GCP, או שזה כבר תחום של מישהו אחר?
זה בדיוק השירות הזה. אנחנו מטפלים בקישוריות site-to-site, בניתוב, בתכנון הכתובות ובמדיניות הרשת שקובעת אם הסביבות באמת מצליחות להגיע אחת לשנייה. המנהרה עצמה היא לרוב החלק הקל. ארכיטקטורת האפליקציה והפריסה שלה הן תחום נפרד; אם הבעיה נמצאת שם, נגיד את זה.
-
אתם יכולים לעבוד עם החומרה הקיימת שלנו, או שזה אומר להחליף הכול?
רוב ההתקשרויות מתחילות בהגדרה נכונה של מה שכבר יש לכם, וחלק לא קטן מהן גם נגמר שם. כשאנחנו ממליצים על החלפה זה מפני שהפלטפורמה לא יכולה לעמוד בדרישה מסוימת, כמו קיבולת, תמיכה בתקנים או גרסת קושחה שאין לה יותר מסלול שדרוג נתמך. אנחנו מסבירים את הסיבה לפני שמזמינים משהו.
-
אתם עושים גם את העבודה הפיזית או רק את התכנון?
בישראל, גם וגם: חדרי שרתים, ארונות, כבילה, נקודות גישה, מיתוג, וציוד IT, IoT, אבטחה ו-AV שנלווה לזה, כולל טכנולוגיית חדרי ישיבות. בחו״ל התכנון, ההגדרה והאימות נעשים מרחוק, ואנחנו מתאמים את ההתקנה הפיזית מול טכנאים מקומיים. ההגדרה והניהול זהים בשני המקרים.
-
מה קורה לרשת אחרי שאתם בונים אותה?
אתם מקבלים את הטופולוגיה, מפת ה-VLAN, תכנון הערוצים, מצב התצורה ומדריכי התפעול, והם שלכם בין אם ההתקשרות ממשיכה ובין אם לא. משם זה או העברה לצוות שלכם או ניהול שוטף כחלק מהתקשרות רחבה יותר.
בואו נבדוק מה הרשת שלכם באמת עושה.
שיחה של 30 דקות עם ג׳וני. נחזור אליכם תוך יום עסקים אחד.