חומת האש של Windows ויישומים עסקיים — רישום כללי כניסה מהמתקין

«במכונת הפיתוח רץ בלי בעיה, ואצל הלקוח הלקוח לא מתחבר לשרת», «בהפעלה הראשונה יצאה אזהרה כלשהי, ונראה שהאדם בשטח ביטל», «ב-netstat הפורט מאזין, אבל מהמחשב ליד זה לא מגיע» — בשטח הטמעת יישום עסקי, פניות «אי אפשר לתקשר» מהסוג הזה הן הקלאסיקה שבקלאסיקות. ומי שנשאר בראש הסיבות הוא חומת האש של Windows ‏(Windows Defender Firewall).

הבעיה היא שבמכונת הפיתוח התקלה לא נראית. במכונת הפיתוח לחצתם בעצמכם על היתר בהרצת ניפוי של Visual Studio, או שאתם עצמכם מנהלים, ולכן יוצאים לשחרור בלי להבחין בחסימת הכניסה כברירת מחדל. אצל הלקוח, מי שמפעיל הוא משתמש רגיל בלי הרשאות מנהל, והרשת מנוהלת ב-GPO. זה לא «מה שאמור לרוץ לא רץ»; המציאות היא ש«מכונת הפיתוח במקרה רצה».

המאמר הזה מיועד למפתחי יישומים עסקיים שנתקלים ב«אצל הלקוח אי אפשר לתקשר» ביישום שפיתחו, ולאנשי מערכות מידע בעסקים קטנים ובינוניים שמקבלים את הפניות האלה. אחרי תפיסה מינימלית של פעולת ברירת המחדל של חומת האש של Windows ושל מנגנון הפרופילים, הוא מסדר לפי מקורות ראשוניים נכון לאוגוסט 2026 את תכנון כלל הכניסה, רישום במתקין בפועל, הליך חיתוך, ונקודות זהירות תחת ניהול GPO/Intune.

1. השורה התחתונה קודם

• ברירת המחדל של חומת האש של Windows היא «כניסה חסומה, יציאה מותרת». תעבורת כניסה שאינה תשובה לבקשה נזרקת כל עוד אינה מתאימה לכלל.¹
• כלל כניסה נחוץ רק ליישום מסוג שרת שמאזין בפורט. יישום לקוח שרק יוצא להתחבר יכול לתקשר כברירת מחדל. קודם חותכים כאן.¹
• יש שלושה פרופילים (דומיין / פרטי / ציבורי). דומיין חל אוטומטית בזיהוי בקר תחום, וציבורי הוא ברירת המחדל לרשת לא מזוהה. הכלל נקבע כמופעל או מושבת לפי פרופיל.¹
• אסור להשאיר את דיאלוג «האזהרה החשובה» לייצור. אם מנהל מבטל, נוצר כלל חסימה, ובמשתמש בלי הרשאות מנהל כל כפתור שיילחץ יוצר כלל חסימה. עד שמוחקים את הכלל שנוצר הדיאלוג לא יוצג שוב.²
• המסקנה: «כלל כניסה ליישום עסקי רושמים במתקין». Microsoft עצמה ממליצה להציב כללים לפני ההפעלה הראשונה, ולהשבית התראות כניסה.²
• מתכננים כללים בהרשאה מינימלית. ציר של תוכנית + פרוטוקול + פורט, מצמצמים פרופיל לדומיין/פרטי, ומצמצמים IP מרוחק לתת-הרשת הנחוצה. בנתיב תוכנית אין תווים כלליים.²³
• החיתוך הוא בסדר Test-NetConnection → Get-NetFirewallRule → pfirewall.log. יומן חומת האש כברירת מחדל אינו נכתב; הוא מופיע רק אחרי שמפעילים רישום של מנות שנזרקו.⁴⁵⁶
• השבתה כוללת בעצירת שירות אינה נתמכת. תחת ניהול GPO/Intune «מיזוג כללים מקומיים» עשוי להיות כבוי, ואז כלל מקומי לא חל. מגישים לאנשי מערכות המידע בקשת הפצה מרוכזת של הכלל.¹²

מפת הידע של המאמר

ברירת המחדל של חומת האש של Windows היא כניסה חסומה ויציאה מותרת, וכלל כניסה נחוץ רק ליישום עסקי מסוג שרת שמאזין בפורט. כשיישום בלי כלל מתחיל להאזין מוצג דיאלוג «האזהרה החשובה», אבל לפי הפעולה עלול להיצרב כלל חסימה ולהפוך לסיבת תקלת «אי אפשר לתקשר», ולכן העיקרון הוא לרשום כלל כניסה במתקין. תחת ניהול GPO/Intune מיזוג כללים מקומיים עשוי להיות כבוי, ואז כלל שנרשם מקומית אינו חל.

flowchart LR
    accTitle: מפת הידע של חומת האש של Windows ויישומים עסקיים
    accDescr: תרשים שמראה את הקשר בין חומת האש של Windows, כלל כניסה, יישום מאזין, דיאלוג «האזהרה החשובה», מתקין והרשאות מנהל, צמצום כללים (ציון תוכנית וצמצום IP מרוחק), מיזוג כללים מקומיים, תקלת «אי אפשר לתקשר» ופקודות החיתוך
    windows_firewall["חומת האש של Windows"]
    inbound_rule["כלל כניסה"]
    listen_app["יישום עסקי מסוג מאזין"]
    installer["מתקין"]
    network_profile["פרופיל רשת"]
    communication_failure["תקלת «אי אפשר לתקשר»"]
    firewall_notification["דיאלוג «האזהרה החשובה»"]
    exe_path_change["שינוי נתיב קובץ ההפעלה"]
    pfirewall_log["יומן חומת האש (pfirewall.log)"]
    group_policy["מדיניות קבוצתית (Group Policy)"]
    intune["Microsoft Intune"]
    local_policy_merge["מיזוג כללים מקומיים"]
    mpssvc["שירות חומת האש (MpsSvc)"]
    port_rule["כלל בציון פורט"]
    over_permission["היתר יתר בכלל"]
    test_netconnection["Test-NetConnection"]
    get_netfirewallrule["Get-NetFirewallRule"]
    unsolicited_inbound["תעבורת כניסה שלא התבקשה"]
    netsh_advfirewall["netsh advfirewall"]
    new_netfirewallrule["New-NetFirewallRule"]
    admin_rights["הרשאות מנהל"]
    remote_ip_scope["צמצום IP מרוחק"]
    program_rule["כלל בציון תוכנית"]
    mpssvc_stop["עצירת שירות MpsSvc"]
    firewall_disable["השבתת חומת האש"]
    named_pipe["‏named pipe (צינור בעל שם)"]
    smb_445["SMB (TCP 445)"]
    get_netconnectionprofile["Get-NetConnectionProfile"]
    block_rule["כלל חסימה"]
    notify_disable["השבתת התראת כניסה"]
    service_rule["כלל בציון שירות"]
    profile_limit["צמצום פרופיל"]
    updater_reregistration["רישום מחדש של כלל בעדכון"]
    netstat["netstat"]
    listen_app -->|"מחייב"| inbound_rule
    installer -->|"מענה מומלץ ל"| inbound_rule
    network_profile -.->|"עלול לגרום ל"| communication_failure
    firewall_notification -.->|"עלול לגרום ל"| communication_failure
    exe_path_change -.->|"עלול לגרום ל"| communication_failure
    communication_failure -->|"נבדק באמצעות"| pfirewall_log
    windows_firewall -->|"מוגדר באמצעות"| group_policy
    windows_firewall -->|"מוגדר באמצעות"| intune
    inbound_rule -.->|"מחייב"| local_policy_merge
    mpssvc -->|"מממש את"| windows_firewall
    windows_firewall -->|"משתמש ב"| network_profile
    port_rule -.->|"עלול לגרום ל"| over_permission
    exe_path_change -.->|"עלול לגרום ל"| firewall_notification
    firewall_notification -->|"מוגדר באמצעות"| group_policy
    communication_failure -->|"נבדק באמצעות"| test_netconnection
    communication_failure -->|"נבדק באמצעות"| get_netfirewallrule
    windows_firewall -->|"מונע"| unsolicited_inbound
    inbound_rule -->|"מוגדר באמצעות"| netsh_advfirewall
    inbound_rule -->|"מוגדר באמצעות"| new_netfirewallrule
    inbound_rule -->|"מחייב"| admin_rights
    remote_ip_scope -->|"מצמצם"| over_permission
    program_rule -->|"מצמצם"| over_permission
    firewall_notification -->|"שימוש לא מומלץ ל"| inbound_rule
    mpssvc_stop -->|"שימוש לא מומלץ ל"| firewall_disable
    remote_ip_scope -->|"מענה מומלץ ל"| over_permission
    program_rule -->|"מענה מומלץ ל"| over_permission
    named_pipe -->|"משתמש ב"| smb_445
    network_profile -->|"נבדק באמצעות"| get_netconnectionprofile
    firewall_notification -.->|"עלול לגרום ל"| block_rule
    block_rule -->|"עלול לגרום ל"| communication_failure
    notify_disable -->|"מונע"| firewall_notification
    service_rule -->|"מצמצם"| over_permission
    profile_limit -->|"מצמצם"| over_permission
    updater_reregistration -->|"מענה מומלץ ל"| exe_path_change
    communication_failure -->|"נבדק באמצעות"| netstat

בתרשים, קו מלא מציין קשר שמתקיים תמיד וקו מקווקו מציין קשר מותנה (תנאי ההתקיימות מפורטים בהסבר של כל קשר בעמוד המפורט). רשימת כל הקשרים (סך הכול 35, עם אסמכתה ורמת ודאות) והגדרות המושגים המרכזיים מרוכזות בעמוד המפורט של מפת הידע (ביפנית). נתונים: JSON-LD / Turtle

2. לתפוס במדויק את פעולת ברירת המחדל — כניסה חסומה כברירת מחדל, יציאה מותרת כברירת מחדל

קודם תופסים את הבסיס במדויק. חומת האש של Windows היא חומת אש מארחת שמופעלת כברירת מחדל בכל המהדורות, ופעולת ברירת המחדל מסתכמת בשתי שורות.¹

• כניסה (inbound): הכול חסום אלא אם זו תשובה לבקשה (solicited) או שהיא מתאימה לכלל
• יציאה (outbound): הכול מותר אלא אם מתאים לכלל

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

• יישום לקוח שרק יוצא להתחבר לשרת ווב פנימי, שרת DB או מערכת ליבה → ככלל אין צורך בכלל. מנות החזרה של החיבור הן «תשובה לבקשה» ולכן עוברות כברירת מחדל.
• יישום מסוג שרת או שירות Windows שפותח פורט ומאזין לחיבור ב-TCP, gRPC או פרוטוקול עצמי → כלל כניסה חובה.
• תצורה שמשתמשת ב-named pipe מרחוק היא חריג. named pipe מרחוק אינו פורט של היישום עצמו אלא עובר ב-SMB ‏(TCP 445), ולכן מה שנחוץ אינו כלל של היישום אלא כלל בצד שיתוף הקבצים (SMB).
• החריג הוא סביבה מאובטחת מאוד ששינתה במפורש את ברירת המחדל של היציאה לחסימה. התצורה הזו קיימת רק בחלק מהארגונים, ואז גם ליישום לקוח נדרשת בקשה לכלל יציאה.²

flowchart TB
    accTitle: כלל כניסה נחוץ רק לצד שמאזין
    accDescr: חיבור כלקוח בלבד אינו דורש ככלל כלל כניסה, וכשפותחים פורט ומאזינים רושמים כלל כניסה במתקין
    APP["סופרים את התקשורת של היישום"] --> Q{"האם פותחים פורט<br/>ומאזינים לחיבור"}
    Q -- "לא מאזינים<br/>(רק מתחברים כלקוח)" --> C1["כלל כניסה ככלל מיותר<br/>החזרה של החיבור עוברת כ«תשובה»"]
    Q -- "מאזינים<br/>(סוג שרת / קבלת callback)" --> S1["כלל כניסה חובה<br/>→ רישום במתקין (פרק 5)"]
    C1 -.-> EX["חריג: בסביבה מאובטחת מאוד<br/>עם חסימת יציאה כברירת מחדל מבקשים כלל יציאה"]

איור 1: כשפותחים פורט ומאזינים נחוץ כלל כניסה; חיבור כלקוח בלבד אינו דורש ככלל כלל כניסה.

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

2.1. פרופילים ו«מיקום הרשת»

כללים חלים לפי פרופיל רשת. יש שלושה פרופילים.¹

את הפרופיל שחל כעת מאשרים ב-Get-NetConnectionProfile, ומעבר פרטי/ציבורי עושים ב-Set-NetConnectionProfile.¹ תאונה נפוצה בשטח היא שבסביבת workgroup אצל הלקוח הרשת נקבעה כ«ציבורית», וכלל כניסה שנוצר מוגבל לדומיין/פרטי אינו חל. כש«יש כלל אבל זה לא עובר», חשדו בהתאמת הפרופיל לפני תוכן הכלל.

2.2. סדר העדיפות של כללים

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

1. כלל היתר מפורש גובר על חסימה כברירת מחדל
2. כלל חסימה מפורש גובר על כלל היתר מתנגש
3. בטווח שאינו סותר את 2, כלל ספציפי יותר גובר

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

3. זהות דיאלוג «האזהרה החשובה» — למה אסור להשאיר לו

כשיישום מתחיל לראשונה להאזין (listen) בפורט, ואם אין כלל היתר ליישום ואין כלל שהגדיר מנהל, Windows מציג את דיאלוג «אזהרה חשובה של אבטחת Windows» המוכר, «חלק מפונקציות היישום הזה חסומות בחומת האש של Windows Defender». המפרט של ההתנהגות ברור.²

• כשמוצג למשתמש עם הרשאות מנהל: «התר גישה» יוצר כלל היתר. אבל לחיצה על «ביטול» יוצרת כלל חסימה. בדרך כלל שניים, ל-TCP ול-UDP.
• כשמוצג למשתמש בלי הרשאות מנהל: כל אפשרות שתיבחר יוצרת כלל חסימה.
• בשני המקרים, כל עוד לא מוחקים את הכלל שנוצר הדיאלוג לא יוצג שוב, והתקשורת ממשיכה להיחסם.

flowchart TB
    accTitle: פיצול דיאלוג «האזהרה החשובה»
    accDescr: כשאין כלל והתראת כניסה מופעלת מוצג הדיאלוג, וביטול או פעולת משתמש רגיל יוצרים כלל חסימה והדיאלוג לא יוצג שוב
    L["היישום מתחיל להאזין בפורט"] --> Q1{"יש כלל שמתאים<br/>ליישום"}
    Q1 -- "יש" --> R1["פועלים לפי הכלל<br/>(הדיאלוג לא יוצא)"]
    Q1 -- "אין" --> Q2{"התראת כניסה<br/>מופעלת"}
    Q2 -- "כבויה" --> R2["חוסמים בשקט<br/>(כלל לא נוצר)"]
    Q2 -- "מופעלת" --> DLG["דיאלוג «האזהרה החשובה»"]
    DLG -- "מנהל «התר גישה»" --> OK["נוצר כלל היתר"]
    DLG -- "מנהל «ביטול»" --> NG1["נוצר כלל חסימה"]
    DLG -- "משתמש בלי הרשאות מנהל<br/>(בכל פעולה)" --> NG2["נוצר כלל חסימה"]
    NG1 --> NEVER["עד שמחיקת הכלל<br/>הדיאלוג לא יוצג שוב"]
    NG2 --> NEVER

איור 2: ביטול הדיאלוג או פעולת משתמש בלי הרשאות מנהל יוצרים כלל חסימה; בלי מחיקה הדיאלוג לא יוצג שוב.

כלומר הדיאלוג נראה כ«מנגנון שמבקש היתר מהמשתמש», ובשטח יישום עסקי הוא פועל כ«מנגנון שצורך כלל חסימה ברגע שמשתמש רגיל נוגע». אם אחראי ההטמעה מפעיל לראשונה בחשבון מנהל ומתיר בדיאלוג, כלל ההיתר שנוצר חל על כל המחשב, ולכן גם המשתמש הרגיל ממחרת יכול לתקשר בינתיים. ועדיין נשארות תאונות — כשמשתמש רגיל דורך לראשונה על האזנה שלא נדרכה באישור בהטמעה, כשפרופיל הרשת שחל שונה מזה שבהטמעה, וכשנתיב ה-exe משתנה בעדכון (פרקים 4 ו-5).

גם Microsoft עצמה מציינת במפורש את שיטות העבודה המומלצות הבאות למכשירים שמשתמשים בהם מי שאינם מנהלים.²

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

השבתת התראה אפשרית ב-Set-NetFirewallProfile -NotifyOnListen False, או ב-Group Policy.⁷ «כשהדיאלוג יוצא, נבקש מהאדם בשטח ללחוץ היתר» אינו נוהל תפעול; זו הזמנה לתאונה. כלל כניסה רושמים בהתקנה — זו מסקנת המאמר, והיא גם תואמת את המלצת Microsoft.

4. תכנון כלל כניסה — ציון תוכנית, ציון פורט, ציון שירות

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

מעל זה משלבים צמצום היקף. גם המלצת התכנון של Microsoft היא «כלל כניסה ספציפי ככל האפשר».²

• צמצום פרופיל: כלל כניסה ליישום עסקי שמשמש רק בפנים מצמצמים לדומיין/פרטי, ואינם מפעילים בציבורי. כך נמנעת תאונה שבה ברגע שמחשב נייד מתחבר ל-Wi-Fi חיצוני פורט האזנה נפתח לעולם.
• צמצום IP מרוחק: אם מקור החיבור קבוע, מצמצמים -RemoteAddress לתת-הרשת הזו. לרשת ביתית או משרד קטן מומלץ צמצום במפתח LocalSubnet.²³
• כיוון ומספר: אם ההאזנה היא TCP בלבד, די בכלל TCP אחד. לא ליצור מתוך אינרציה כללי TCP ו-UDP כמו שהדיאלוג יוצר אוטומטית.

«רק מהעמית הנחוץ, רק לפורט הנחוץ, רק לתוכנית הנחוצה» — תכנון כלל כניסה מסתכם במשפט ההרשאה המינימלית הזה.

5. רישום במתקין בפועל — netsh ו-New-NetFirewallRule

5.1. הנחה: נדרשות הרשאות מנהל

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

5.2. רישום ב-netsh advfirewall

קלאסי, וקל לקרוא מכל מתקין, הוא netsh advfirewall firewall add rule.⁸

rem add rule מוסיף גם אם יש כלל באותו שם, ולכן לקראת הרצה חוזרת
rem בהתקנה מחדש, תיקון ועדכון מוחקים כלל באותו שם ואז רושמים מחדש
netsh advfirewall firewall delete rule name="MyCompany OrderServer"

rem כלל היתר כניסה עם ציון תוכנית + ציון פורט + צמצום פרופיל
netsh advfirewall firewall add rule name="MyCompany OrderServer" dir=in action=allow program="C:\Program Files\MyCompany\OrderServer\OrderServer.exe" protocol=TCP localport=50051 profile=domain enable=yes

rem בהסרת התקנה: מחיקה לפי שם
netsh advfirewall firewall delete rule name="MyCompany OrderServer"

add rule אינו מחליף כלל קיים באותו שם אלא מוסיף באותו שם, ולכן בלי delete rule קודם הכלל מתרבה בכל הרצה, ואחרי עדכון ששינה נתיב או היקף כלל ההיתר הישן שורד (בהרצה הראשונה ה-delete rule שבראש מחזיר ש«אין כלל מתאים», אבל הביצוע של האצווה ממשיך, ולכן הסדר הזה תקין. אם המתקין קובע הצלחה לפי קוד יציאה, הסתכלו בתוצאת add rule שבסוף). אפשר גם לצמצם מקור חיבור כמו remoteip=157.60.0.1,172.16.0.0/16,LocalSubnet.⁸ מחיקה מוחקת יחד כללים שמתאימים לשם, ולכן שם הכלל ייחודי עם קידומת של החברה הוא הבטוח.

5.3. רישום ב-PowerShell ‏(New-NetFirewallRule)

לשליטה דקה יותר משתמשים במודול NetSecurity. -DisplayName חובה, ו--Profile יכול לקבל כמה ערכים מופרדים בפסיק (בלי רווח).³

# רישום (מריצים מוגבה מהמתקין). -Name הוא מזהה ייחודי, ולכן
# בהרצה חוזרת בהתקנה מחדש, תיקון ועדכון יצירת כלל באותו שם
# תיכשל. עושים אידמפוטנטיות במחיקת כלל קיים באותו שם ואז יצירה מחדש
Remove-NetFirewallRule -Name "MyCompany-OrderServer-In" -ErrorAction SilentlyContinue
New-NetFirewallRule -Name "MyCompany-OrderServer-In" `
    -DisplayName "MyCompany OrderServer (כניסת TCP 50051)" `
    -Direction Inbound -Action Allow `
    -Program "C:\Program Files\MyCompany\OrderServer\OrderServer.exe" `
    -Protocol TCP -LocalPort 50051 `
    -Profile Domain,Private -RemoteAddress LocalSubnet

# בהסרת התקנה: לא נכשלים גם אם אינו קיים
Remove-NetFirewallRule -Name "MyCompany-OrderServer-In" -ErrorAction SilentlyContinue

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

5.4. כשנתיב ה-exe משתנה בעדכון

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

flowchart TB
    accTitle: עדכון שמשנה נתיב exe מנתק את הכלל
    accDescr: כלל בציון תוכנית מקבע נתיב מלא, ולכן שינוי מקום ההצבה מאבד את היעד, ולפי התראה הדיאלוג מוצג שוב או שיש חסימה בשקט
    V1["הטמעת v1.0<br/>הכלל מצביע על exe בתיקיית v1.0"] --> UP["בעדכון הצבה בתיקיית v1.1<br/>נתיב ה-exe שרץ משתנה"]
    UP --> MISS["הכלל בנתיב הישן מאבד את היעד<br/>(הכלל נשאר אבל לא חל)"]
    MISS --> Q{"התראת כניסה<br/>מופעלת"}
    Q -- "מופעלת" --> DLG["הדיאלוג מוצג שוב<br/>נגיעת משתמש רגיל = כלל חסימה"]
    Q -- "כבויה" --> SILENT["בלי דיאלוג,<br/>חסימה בשקט"]
    MISS -.->|"טיפול"| FIX["מקבעים נתיב מעבר לעדכונים<br/>או בעדכון מוחקים כלל ישן ורושמים מחדש"]

איור 3: אם עדכון משנה את נתיב ה-exe, הכלל הישן מאבד את היעד; מקבעים נתיב יציב או רושמים מחדש בעדכון.

הטיפול פשוט, אחת מאלה:

• מקבעים יעד התקנה כך שהנתיב המלא של ה-exe לא משתנה מעבר לעדכונים
• בעדכון שמשנה נתיב, ה-updater מוחק את הכלל הישן ורושם מחדש בנתיב החדש (מריצים גם בעדכון את הפקודות של 5.2/5.3)

ב-MSI הרישום של הכלל הוא פעולה מותאמת שרצה אחרי הצבת הקבצים (ובהסרת התקנה פעולה מותאמת בצד המחיקה) — זה הדפוס. בערכות כלים כמו WiX יש גם הרחבות שמתארות כללי חומת אש באופן הצהרתי. מקום המימוש משתנה לפי שיטת ההפצה שנבחרה, ולכן ראו גם «איך בוחרים שיטת הפצה ליישום Windows». ועוד תקלה קלאסית בהרחבה אצל לקוח — זיהוי שגוי של אנטי-וירוס — מטופלת ב«טיפול בזיהוי שגוי של Microsoft Defender».

6. פתרון תקלות — זרימת חיתוך של «אי אפשר לתקשר»

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

flowchart TB
    accTitle: חיתוך של «אי אפשר לתקשר»
    accDescr: מאשרים לפי הסדר האזנה בשרת, הגעה מהלקוח, התאמת פרופיל, כללים ב-ActiveStore, וזריקה DROP ביומן
    S["«אי אפשר לתקשר מהלקוח»"] --> N["בצד השרת: netstat -ano"]
    N -- "לא מאזין" --> APP["בעיה לפני חומת האש<br/>חוקרים יישום / שירות"]
    N -- "LISTENING" --> T["בצד הלקוח: Test-NetConnection"]
    T -- "TcpTestSucceeded=True" --> OTHER["ההגעה תקינה<br/>חוקרים שכבת יישום (אימות / פרוטוקול)"]
    T -- "False" --> P["בצד השרת: Get-NetConnectionProfile<br/>מאשרים פרופיל חל"]
    P -- "לא תואם ליעד הכלל" --> FIXP["בודקים מחדש את ציון הפרופיל בכלל"]
    P -- "תואם" --> R["Get-NetFirewallRule -PolicyStore ActiveStore<br/>מאשרים קיום כלל היתר וערבוב כלל חסימה"]
    R --> LOGCHK["מדידת זריקה (DROP) ב-pfirewall.log"]

איור 4: חיתוך מכני: netstat → Test-NetConnection → פרופיל → כללים ב-ActiveStore → pfirewall.log.

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

# חיפוש לאחור של כללים שקשורים לפורט 50051
Get-NetFirewallPortFilter | Where-Object { $_.LocalPort -eq 50051 } | Get-NetFirewallRule

# מעקב אחרי מקור הכלל (מקומי או GPO)
Get-NetFirewallRule -PolicyStore ActiveStore -TracePolicyStore |
    Select-Object Name, DisplayName, PolicyStoreSourceType, PolicyStoreSource

יומן חומת האש (pfirewall.log) בשלב 5 כברירת מחדל אינו רושם דבר. הנתיב כברירת מחדל הוא %windir%\system32\logfiles\firewall\pfirewall.log, הגודל המרבי כברירת מחדל 4,096KB, והכתיבה מתחילה רק אחרי שמפעילים «רשום מנות שנזרקו ליומן» או «רשום חיבורים שהצליחו ליומן».⁶ במחשב בודד אפשר להפעיל כך:⁶

netsh advfirewall set allprofiles logging droppedconnections enable
netsh advfirewall set allprofiles logging allowedconnections enable

היומן הוא קובץ טקסט, וכל שורה רושמת זריקה (DROP) או היתר (ALLOW), פרוטוקול, וכתובות ופורטים של מקור/יעד, ולכן כאן קובעים «האם SYN מהלקוח הגיע ונזרק, או כלל לא הגיע». בסביבה שהיומן מוגדר במדיניות לפעמים חסרות הרשאות כתיבה לתיקיית היומן (FullControl לשירות mpssvc) והקובץ לא נוצר; אז נדרשות יצירת תיקייה והענקת ACL.⁶

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

ולבסוף מבהירים חיתוך שאסור לעשות. השבתה גורפת בעצירת שירות חומת האש (MpsSvc) אינה נתמכת, והיא גורמת לבעיות בצד מערכת ההפעלה כמו תפריט התחלה שלא זז וכשל בעדכון יישומי החנות. אם בכל זאת רוצים להשבית כדי לאשר, משאירים את השירות רץ ומשביתים פרופיל ב-Set-NetFirewallProfile -Profile Domain,Public,Private -Enabled False, ומחזירים מיד אחרי האישור.¹⁷ ואחרי שקבעתם שהסיבה היא חומת האש, הטיפול אינו להנציח השבתה אלא להוסיף כלל נכון אחד.

7. זהירות תחת ניהול ארגוני — סביבה שכלל מקומי לא חל בה, ואופן הבקשה

יש סביבות שגם אחרי שהמתקין רושם כלל, הוא לא חל. בארגון שמנהל חומת אש במרוכז ב-GPO או Intune ‏(CSP) אפשר להשבית לפי פרופיל את «מיזוג כללים מקומיים» (AllowLocalPolicyMerge). כשההגדרה כבויה, כללים שמנהל מקומי (כולל המתקין) יצר אינם חלים, וכללי יישומים שדורשים חיבור כניסה חייבים הפצה מרוכזת מ-GPO/CSP.²

flowchart TB
    accTitle: כשמיזוג כללים מקומיים כבוי, רישום המתקין אינו חל
    accDescr: בסביבה ש-AllowLocalPolicyMerge כבוי בה הכלל המקומי קיים אבל אינו חל, ועוברים להפצה מרוכזת ב-GPO או ב-CSP
    GPOR["כללים שהופצו ב-GPO/Intune"] --> EFF["קבוצת הכללים שחלים בפועל<br/>(ActiveStore)"]
    LOCAL["כללים שנוצרו מקומית<br/>(כולל רישום המתקין)"] --> Q{"מיזוג כללים מקומיים<br/>(AllowLocalPolicyMerge)"}
    Q -- "מופעל (ברירת מחדל)" --> EFF
    Q -- "כבוי" --> DROP["הכלל קיים אבל אינו חל<br/>→ עוברים להפצה מרוכזת ב-GPO/CSP"]

איור 5: כשמיזוג כללים מקומיים כבוי, כללי המתקין אינם חלים; נדרשת הפצה מרוכזת ב-GPO/CSP.

ההכנה המציאותית מצד הפיתוח ומצד ההטמעה:

• רישום הכלל במתקין מתוכנן כ«לא נכשל» (הרישום עצמו מצליח, ולכן אי אפשר לזהות בשגיאה. כוללים בנוהל אישור קישוריות אחרי ההטמעה)
• בשלב 4 בפרק 6 (-TracePolicyStore) מאשרים אם מקור הכלל שחל הוא מקומי או GPO⁵
• כשמבינים שכלל מקומי לא חל, עוברים לבקשת הפצת כלל למחלקת מערכות המידע

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

גם מצד מערכות המידע, בקשה עם הטבלה הזו ובלי הטבלה הזו שונות לגמרי בכמות העבודה. ולהפך, «תפתחו» עם מספר פורט בלבד נוטה להיתר יתר, כפי שראינו בפרק 4. ודרישות תקשורת סביב שיתוף קבצים ואימות בסביבת דומיין משתנות גם בלחצים אחרים מלבד חומת האש (חובת חתימה וכו’). ראו גם «חתימת SMB ו-LDAP channel binding».

8. סיכום

• ברירת המחדל של חומת האש של Windows היא כניסה חסומה ויציאה מותרת. כלל כניסה נחוץ רק ליישום מסוג שרת שמאזין, וככלל מיותר אם רק מתחברים כלקוח.
• כללים חלים לפי פרופיל (דומיין / פרטי / ציבורי). החשוד הראשון ב«יש כלל אבל זה לא עובר» הוא אי-התאמת פרופיל.
• דיאלוג «האזהרה החשובה» יוצר כלל חסימה בביטול או בפעולת משתמש בלי הרשאות, ומכאן ואילך אינו מוצג שוב. אסור להשאיר תפעול ייצור לדיאלוג הזה.
• כלל כניסה ליישום עסקי רושמים במתקין — זה העיקרון היחיד. הרישום בהרשאות מנהל, ועם -Name מקובע כולל מחיקה.
• הכלל סביב תוכנית + פרוטוקול + פורט, ומצמצמים בפרופיל וב-IP מרוחק. אם נתיב ה-exe משתנה בעדכון, לא שוכחים לרשום מחדש את הכלל.
• החיתוך מכני: netstat → Test-NetConnection → אישור פרופיל → Get-NetFirewallRule ‏(ActiveStore) → pfirewall.log. השבתה בעצירת שירות אינה נתמכת.
• תחת ניהול GPO/Intune מיזוג כללים מקומיים עשוי להיות כבוי. אז מגישים לאנשי מערכות המידע הפצה עם שם כלל, כיוון, תוכנית, פורט, IP מרוחק ופרופיל.

מאמרים קשורים

• איך בוחרים תקשורת בין-תהליכית ב-Windows — טבלת החלטה named pipes / TCP / gRPC / זיכרון משותף / COM
• איך בוחרים שיטת הפצה ליישום Windows - MSI/MSIX/ClickOnce/xcopy/עדכון עצמי
• מתי באמת נדרשות הרשאות מנהל ב-Windows - UAC, אזורים מוגנים, ואיך מבחינים בתכנון
• כשיישום Windows שפיתחתם מטופל כווירוס — טיפול בזיהוי שגוי של Microsoft Defender, והיחס להשפעה על ביצועים
• חתימת SMB ו-LDAP channel binding — לסגור בשטח את «החצי שנשאר» בטיפול ב-NTLM
• איך בונים ומפעילים שירות Windows — מהבחירה מול Task Scheduler עד הפיכת BackgroundService לשירות

תחומי ייעוץ קשורים

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

• פיתוח יישומי Windows
• חקירת תקלות ואיתור גורמים
• ייעוץ טכני וסקירת תכנון
• יצירת קשר

מקורות

מאמרים קשורים

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

נושאים קשורים

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

שירותים הקשורים לנושא הזה

המאמר קשור ישירות לשירותים הבאים.

שאלות נפוצות

שאלות נפוצות בפניות בנושא המאמר.

גם ליישום שהוא רק לקוח שמתחבר לשרת נחוץ כלל חומת אש?

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

אי אפשר פשוט ללחוץ «התר גישה» בדיאלוג «אזהרה חשובה של אבטחת Windows»?

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

כלל כניסה — לפי פורט או לפי תוכנית?

הבסיס הוא לשלב, לא לבד. ציון תוכנית מצמצם לפי נתיב מלא של exe, אבל אם הנתיב משתנה בעדכון הכלל מאבד את היעד (אין תווים כלליים). ציון פורט מבהיר את הבקשה לאנשי מערכות המידע, אבל מעביר גם תהליך אחר שמאזין באותו פורט. ביישום עסקי בייצור הציר הוא «תוכנית + פרוטוקול + פורט», מצמצמים פרופיל לדומיין/פרטי, ומצמצמים IP מרוחק לתת-הרשת שבה יושבים הלקוחות — זה דפוס ההרשאה המינימלית. רק כשהפורט דינמי משתמשים בציון תוכנית לבד.

נראה שהכלל שהמתקין רשם לא חל במחשב אצל הלקוח. למה?

סביר שחומת האש אצל הלקוח מנוהלת במרוכז ב-GPO או Intune, ו«מיזוג כללים מקומיים» (AllowLocalPolicyMerge) כבוי. כשההגדרה כבויה, כלל שנוצר מקומית קיים בפרופיל אבל אינו חל, ואין ברירה אלא להפיץ את הכלל במרוכז מצד GPO/CSP. מאשרים את כלל הכללים התקפים ב-Get-NetFirewallRule -PolicyStore ActiveStore, ומגישים בקשת הפצה למחלקת מערכות המידע. בבקשה מעבירים בבת אחת שם כלל, כיוון, נתיב תוכנית, פרוטוקול ופורט, טווח IP מרוחק ופרופיל — וזה עובר בפעם אחת.

מותר להשבית זמנית את חומת האש לצורך חיתוך תקשורת?

השבתה בעצירת השירות (MpsSvc) אסורה בהחלט. זו פעולה שאינה נתמכת בידי Microsoft, והיא גורמת לבעיות בצד מערכת ההפעלה כמו תפריט התחלה שלא זז וכשל בעדכון יישומי החנות. אם בכל זאת רוצים להשבית לצורך חיתוך, הדרך הנכונה היא להשאיר את השירות רץ ולהשבית פרופיל ב-Set-NetFirewallProfile -Enabled False. גם זה מוגבל לשימוש של כמה דקות כדי לאשר «האם הסיבה היא חומת האש», ומחזירים מיד אחרי האישור. תפעול שמשאיר מושבת מחליף בעיה שאפשר לפתור בכלל אחד בחוסר הגנה על כל המחשב.

פרופיל הכותב

עמוד היכרות עם כותב המאמר.

Go Komura

מנהל KomuraSoft LLC

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