לפני ימי PowerShell Test-NetConnection cmdlet, היו לנו כלי שורת פקודה שונים רבים שיכולנו לבחור מתוך כדי לאתר בעיות קשרי רשת שונות.
היו לנו ping לבדיקת ICMP echoes ותשובות; tracert כדי לראות איפה יתכן שהחבילות שלנו נפלו; nslookup לביצוע שאילתות DNS נגד השרתים שלנו; telnet לבדיקת פורטים פתוחים של TCP, וכליים שונים נוספים. היה יותרון לכל דבר.
עם הצגת PowerShell v4 ב- Windows 8.1 ו- Windows Server 2012 R2, גישת השימוש בכלי אחד למשימה אחת לבד בכדי לאתר בעיות קשרי התקשורת הפכה לעתיקה.
אני מאפשר לך להצטרף למוצג החדש, כל-יכול Test-NetConnection cmdlet. חשוב לחשוב על PowerShell Test-NetConnection כ ping, tracert, nslookup, telnet, וכמה כלים נוספים מעוטרים יחד לסוויטה של שפע של כלי בדיקות.
בדיקות עם Test-NetConnection של PowerShell
בואו נראה מה אנו יכולים לעשות עם כלי ה- Powershell test-netconnection cmdlet ונבחן איך נוכל להשתמש בו כאשר אנו נמצאים במצב מבאס של פיתרון בעיה בקשר הרשת.
כדי להדגיש זאת, אני הולך להשתמש ב-PowerShell Test-NetConnection כדי לפתור בעיה נפוצה בעולם האמית: "אני לא יכול להגיע לאתר XYZ!"
מה שרוב המשתמשים אינם יודעים הוא שהצגת אתר בדפדפן היא בעצמה הישג מדהים, שבחשיבותו ישנם המון רכיבים שחייבים לעבוד ביחד כדי שזה יקרה. לפחות, התהליך כולל:
- יש לך חיבור לאינטרנט.
- יש לך מסלול לשרת ה-DNS שלך.
- יצירת קשר עם שרת ה-DNS כדי לפתור את ה-URL.
- יש לך מסלול לכתובת ה-IP שה-URL מפתיע ל.
- יש לך את יציאת ה- TCP 80 פתוחה.
- וכו', וכו'.
אימות חיבור האינטרנט שלך
כדי להתחיל בפתרון בעיות, עליך תחילה לוודא שיש לך חיבור לאינטרנט. תוכל לעשות זאת פשוט על ידי הרצת PowerShell Test-NetConnection ללא פרמטרים בכלל. אם תרצה לקבל עוד מידע, אני ממליץ להשתמש בפרמטר InformationLevel עם הארגומנט Detailed.
הפקודה הפשוטה הזו בודקת את התקשורת המקומית והתקשורת לאינטרנט שלך ומאמת שלקוח ה-DNS שלך יכול לפתור שמות המפנים לשרת ה-DNS שלך, הכול בפגישה אחת. תכל'ס, זהו בדיקת בריאות כללית לחיבור הרשת שלך. הפקודה הזו בודקת שלוש מתוך חמישה התהליכים הנדרשים להצגת אתר באמצעות בדיקה אחת!
השתמש ב-Test-NetConnection כדי לבדוק את החיבור שלך למארח האתר
נצטרך כעת להפנות את פתרון בעיותינו למארח האתר הרלוונטי. בואו נשתמש ב-google.com כדוגמה. תוכלו גם להשתמש במחשב מרוחק.
אנו יכולים להשתמש ב־Test-NetConnection עם הפרמטר ComputerName כדי לוודא באופן סימולטני שהמארח של האתר ניתן לפירוש ב־DNS, שישנה נתיב TCP זמין להגעה לכתובת ה־IP שבה נפתר שמו, ושניתן לשלוח ping לו.
אף על פי ששלב זה מאמת בצורה טכנית שיש לנו נתיב לשרת האינטרנט של google.com, אני רוצה למצוא מידע נוסף ומפורט יותר על הראוטרים שאותם החבילות שלי עוברות דרך כדי להגיע לשרת האינטרנט של google.com. כדי לעשות זאת, אני אשתמש בפרמטר TraceRoute כדי לקבל רשימה.
ודאו שיציבות הפורט של TCP פתוחה
הבדיקה הסופית שלנו היא לוודא שהפורט של TCP שאנו מצפים לשרת האינטרנט פועל. במקרה זה, מאחר שאנו פשוט מציינים את google.com, אני אניח שזהו פורט TCP 80. כדי לעשות זאת, פשוט נוסיף פרמטר נוסף ל־Test-NetConnection. מכיוון ש־Test-NetConnection מבין את הפורט התקני של TCP למספר שירותים שונים, אין לנו אפילו צורך לדעת את מספר הפורט. אני פשוט אוכל להעביר HTTP לפרמטר CommonTCPPort והוא יעשה את העבודה עבורי.
אך, אם האתר עשוי לרוץ תחת פורט שונה, כמו 8080, ניתן לציין פורט TCP ישירות באמצעות הפרמטר Port במקום.
כעת בדקנו כל אחת מדרישות התקשורת המופיעות בתחילת המאמר הזה. אם עדיין לא יכולים להציג את האתר בזמן זה, אישרנו שהבעיה אינה נמצאת אצל הלקוח שלנו, ונוכל להעביר את הבעיה ל-Google או אולי לשרת DNS למטה.