אני מקבל הרבה פניות ושאלות בנושא תקלות ברשתות תקשורת, ולעשות את הבלוג מעניין החלטתי להביא קצת תקלות ואירועים מעניינים.
מקרה ראשון ולא מסובך (כמו שאומרים, נתחיל בקטנה..)
מבנה הרשת (החלק הרלבנטי לתקלה):
רשת של מרכז עם מספר שרתים, וכ- 25 אתרי קצה, שמחוברים למרכז הרשת בקווי IPVPN של בזק. ברוחב פס של 2M-Down/0.3M-Up. באופן רגיל השימוש ברשת הוא מועט והעומס על הקווים הוא נמוך.
העבודה הינה ב- Microsoft TS העובדים מול שרת באתר המרכזי
מה הייתה הבעיה:
הבעיה הייתה שבאופן אקראי, אתרים מסוימים, ללא קשר לאתרים האחרים, מתחילים לעבוד באיטיות רבה. העבודה מאתרים אלו למרכז "זוחלת". בתקלה היא אקראית ולא ניתן להצביע על דפוס (Pattern) מסוים – זה יכול לקרות בכל מקום ובכל שעה.
פתרון:
- שלב ראשון – מהיכן נובעת הבעיה? ובכן, בבדיקה בתוכנת SNMP שמותקנת במרכז רואים שבשעות מסוימות, בתחנות קצה מסוימות, ובאופן אקראי לחלוטין, קווי ה- Upstream חסומים לחלוטין בגלל עומס.
- שלב שני – ממה נובע העומס? כדי למצוא מהיכן מגיע העומס, שהוא אקראי לחלוטין, נצטרך תוכנה שדוגמת את הקווים באופן קבוע, כולל מקור ויעד ברמה 3/4 (IP ו- TCP/UDP) ולראות מהיכן מגיע העומס. הדרך הפשוטה ביותר היא להפעיל Netflow בנתבי קצה, ונרכז את המידע ב- Netflow Collector במרכז. בבדיקה שנעשתה, לאחר מספר שעות, אני רואה דבר כזה (תוכנת PRTG):
מה שאנחנו רואים זה שכתובת 172.30.121.1 מדברת עם כתובת 172.30.0.22, ועבר בינהם מידע של 225Mbytes. מהיכרותי את הכתובות והמחשבים המדוברים, אין סיכוי שכמות כזאת של מידע תעבור בינהם, ולכן אני ממשיך לבדוק מה קרה כאן.
באופן רגיל, פרוטוקול Netflow אמור לתת לי גם את ה- TCP Port numbers של הקישור, ומסיבה כלשהי אני לא רואה את זה כאן, אבל מכיוון שעל שרת 172.30.0.22 מותקן לי Wireshark, אז חבל לבזבז זמן כי אני יכול לראות מידית מה קורה.
- הגדרתי אתראה במערכת שכאשר יש עומס אני אקבל הודעה ואוכל להתחבר, קיבלתי אתראה, התחברתי והפעלתי Wireshark על שרת 172.30.0.22, ומה שאני רואה זה (שימו לב להגדרה של ה- Filter):
כלומר, קו ה- Upstream "חנוק" על 360Kbps שזה בערך ה- Upstream של קו ה- IPVPN
4. בבדיקה של סטטיסטיקות, רואים כי התנועה העיקרית היא על TCP Port 445, כלומר אחד מפרוטוקולי NetBIOS של מייקרוסופט.
5. כדי לדעת איזה Process במחשב מייצר את התנועה, ניתן להריץ את הפקודה Netstat -o (o for owner), ואז אני רואה שה- Process ID הוא 4. ב- Task manager, כאשר מאפשרים לראות את ה- Process ID, ובאופן משעשע ה- Process המדובר הוא ה- System …
6. מה שעוד יותר משעשע, שכאשר חסמתי את Port 445 ב- FW, התנועה מתחילה להיות על TCP Port 139 (NetBIOS Session Protocol)…
7. חסמתי גם את Port 139, והכל עבד. עכשיו רק נשאר להשקיע קצת זמן ב- Google ולראות אם זה תולעת (כמו שזה נראה) או משהו אחר..
