פינג עובד בכיוון אחד: למה Windows מפיל את ההד של השרת

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

שני כיוונים, שתי החלטות שונות

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

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

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

עקבו אחרי החבילה עד שהיא נעלמת

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

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

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

הגבילו כלל אחד במקום לפתוח ICMP

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

Get-NetConnectionProfile
Get-NetAdapter | Where-Object Status -eq 'Up'
New-NetFirewallRule -DisplayName "VPN server echo" -Direction Inbound -Protocol ICMPv4 -IcmpType 8 -RemoteAddress 10.63.0.1 -InterfaceAlias "Office VPN" -Profile Private -Action Allow -WhatIf

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

מה הכלל לא מכסה

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

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

קראו את התוצאה בכיוון הנכון

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

Get-NetFirewallRule -DisplayName "VPN server echo" | Get-NetFirewallAddressFilter
ping 10.63.4.17
ping -6 fd00:63::17

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