הרשת עובדת אבל Windows מציג "אין אינטרנט" — לבודד NCSI, DNS, Proxy ו-VPN ב-Windows

אתרי אינטרנט נפתחים. גם הודעות צ’אט מגיעות. ובכל זאת, רק התצוגה של Windows מראה “אין אינטרנט”.

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

לכן, לפני שמוחקים את הגדרות ה-Wi-Fi או מאפסים את כל הרשת, מפרידים בין השאלות: האם רק התצוגה שגויה, או שגם התעבורה שאתם רוצים להשתמש בה נכשלת?

במאמר הזה נסביר תחילה את המנגנון שגורם לפער, ומשם נעבור למצבים נפוצים, לאופן הקריאה לפי סימפטום, ולשלבי הבדיקה בפועל. מי שמעניין אותו המנגנון — פרקים 1 עד 3; מי שחוקר תקלה — פרקים 4 ו-5; ומפתחי יישומי Windows — גם פרק 6. המאמר מתמקד ב-Windows 11 ומכסה גם את ההבדלים מול Windows 10, והדוגמאות משתמשות ב-Windows PowerShell 5.1 וב-curl.exe.

1. Windows לא מסתכל רק על האתר שאתם רואים עכשיו

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

עכשיו נניח שרשת החברה מוגדרת כך: “תעבורה לאתרים שבשימוש יומיומי עוברת, אבל תעבורה ליעד בדיקת הקישוריות לא עוברת”. התעבורה של ה-browser תצליח, ואילו תעבורת הבדיקה של Windows תיכשל. גם באותו מחשב, אם מה שבודקים מולו שונה, התוצאות יכולות להיות שונות.¹

flowchart TB
    accTitle: דוגמה שבה האתר עובד ורק בדיקת הקישוריות נכשלת
    accDescr: דוגמה היפותטית שבה ה-browser באותו מחשב מצליח להגיע לאתר הרגיל, בעוד בקשת הבדיקה של NCSI לא מגיעה ליעד בדיקה אחר. זה אינו diagram שקובע את המצב הסופי של NCSI מבקשה אחת.
    pc["אותו מחשב"] --> browser["תעבורה של ה-browser"]
    pc --> probe["תעבורת הבדיקה של Windows"]
    browser --> site["האתר הרגיל<br/>הדף נפתח"]
    probe --> blocked["יעד בדיקת הקישוריות<br/>רק התעבורה לכאן נכשלת"]

איור 1: דוגמה היפותטית להמחשת המנגנון. התעבורה השגרתית ובדיקת הקישוריות פונות לגורמים שונים.

הרכיב שאחראי על קביעת הקישוריות הזו הוא NCSI (Network Connectivity Status Indicator). הוא קובע אם יש חיבור לאינטרנט או שהחיבור נשאר מקומי, ומספק את המידע שתצוגת הרשת והיישומים משתמשים בו. הוא לא מנטר את הפעילות של אתר כזה או אחר או של מערכת עסקית כלשהי.¹

לא “משהו חזר”, אלא האם חזר התוכן של הבדיקה

ב-Windows 10 גרסה 1607 ואילך, יעד ה-HTTP הסטנדרטי לבדיקה הוא ה-URL הבא. גוף התשובה הצפוי הוא Microsoft Connect Test. במחשבים שמנוהלים על ידי ארגון, יעד הבדיקה עשוי להיות מוחלף.²

http://www.msftconnecttest.com/connecttest.txt

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

flowchart TB
    accTitle: מה ה-HTTP probe בודק
    accDescr: בבקשה ליעד הבדיקה, בודקים אם חזרו התשובה וגוף התשובה הצפויים.
    start["בקשת HTTP ליעד הבדיקה"] --> response{"האם התקבלה תשובה"}
    response -->|"לא"| failed["לחקור העברה שלא הושלמה או כשל תקשורת"]
    response -->|"כן"| content{"האם זו התשובה וגוף התשובה הצפויים"}
    content -->|"כן"| success["חומר לזיהוי חיבור קיים"]
    content -->|"לא"| changed["לחקור authentication, חסימה או תוכן שהשתנה"]

איור 2: מפרידים בין כך שהתקבלה תשובה מיעד הבדיקה לבין כך שחזר התוכן הצפוי.

חשוב לציין ש-NCSI לא פועל רק מתעבורת הבדיקה הזו. השיטה שבה הוא בודק ביוזמתו נקראת active probe, והשיטה שבה הוא מסיק מידע כמו packets שהתקבלו נקראת passive probe — והוא משתמש בשתיהן. לכן, כשל של בקשת HTTP אחת ב-diagram אינו זהה לכך שמצב הקישוריות הסופי הופך ל”אין אינטרנט”.¹

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

ב-diagram, solid line מציינת relation שתמיד מתקיים ו-dashed line מציינת relation מותנה (התנאים מופיעים בהסבר של כל relation ב-detail page). הרשימה המלאה של ה-relations (סה”כ 5, כולל evidence ו-certainty) וההגדרות של ה-concepts המרכזיים נמצאות ב-detail page של ה-knowledge map (ביפנית). Data: JSON-LD / Turtle

2. שלושה מצבים נפוצים שבהם התצוגה והתעבורה אינן מתיישבות

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

נדייק קצת את הדוגמה של החברה מהפתיחה. ברשתות ארגוניות יש תצורות שבהן לא מתחברים ישירות החוצה, אלא דרך ממסר שנקרא proxy. המנגנון שבוחר את הממסר הזה לפי ה-URL שאליו ניגשים וקריטריונים דומים הוא קובץ ה-PAC. לעיתים משתמשים גם ב-automatic detection.⁴

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

flowchart TB
    accTitle: בודקים בנפרד את הנתיב של ה-browser ואת הנתיב של NCSI
    accDescr: הצלחה של תעבורת ה-browser אינה מבטיחה הצלחה של NCSI, שמשתמש ביעד אחר ובבחירת proxy אחרת.
    pc["אותו מחשב"] --> browser["בקשת ה-browser"]
    pc --> ncsi["בקשת הבדיקה של NCSI"]
    browser --> bpath["proxy ו-authentication של הבקשה הזו"]
    ncsi --> npath["proxy ו-authentication של בקשת הבדיקה"]
    bpath --> site["האתר שבו השתמשתם"]
    npath --> probe["יעד בדיקת הקישוריות"]

איור 3: “אותו מחשב” אינו בהכרח אותו נתיב. בודקים יעד, proxy ו-authentication עבור כל בקשה.

לכן לא מסתפקים בשאלה אם ה-browser הצליח, אלא בודקים איזה proxy נבחר לבקשה של NCSI, ובאיזה חשבון או תנאי authentication היא בוצעה. אותו דבר נכון גם ל-curl הידני שנשתמש בו בהמשך. אי-הנחה ששלושתם הם תעבורה בתנאים זהים — זו נקודת ההתחלה של הבידוד.

בבית מלון, ייתכן שנותרה התחברות אחרי החיבור ל-Wi-Fi

ב-Wi-Fi של בתי מלון וכדומה, ייתכן שאחרי החיבור לאוויר תתבקשו לאשר תנאי שימוש או להתחבר. שער ה-authentication הזה הוא captive portal. אם בקשת הבדיקה מופנית לדף ה-authentication, או שמוחזר מסך התחברות, זו אינה תשובת הבדיקה הרגילה. גם הפעולה שבה Windows פותח דפדפן כדי לבקש sign-in קשורה למנגנון הזה.³

flowchart TB
    accTitle: ההבדל בין חיבור ל-Wi-Fi לבין authentication בפורטל
    accDescr: גם אחרי חיבור אלחוטי מוצלח, תעבורה החוצה עשויה להישאר מוגבלת עד השלמת ה-authentication בצד הרשת.
    wifi["חיבור ל-Wi-Fi"] --> portal{"האם authentication השימוש הושלם"}
    portal -->|"לא הושלם"| signin["לבצע authentication דרך העמוד הרשמי"]
    portal -->|"הושלם"| test["לבדוק מחדש את התעבורה בפועל ואת הקביעה"]
    signin --> test

איור 4: סיום החיבור ל-Wi-Fi אינו אומר שהסתיים ה-authentication לשימוש ברשת הזו.

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

עם VPN, משתנה “של איזה חיבור התוצאה”

לפני ואחרי חיבור VPN, נתיב התעבורה ותנאי השימוש ב-DNS יכולים להשתנות. גם מצבים שבהם ההגדרות לא מסתדרות מיד אחרי החיבור, או שתעבורת הבדיקה יוצאת לנתיב לא מכוון, הם מועמדים לכשל של NCSI.²

במקרה כזה לא מסתכלים על כל ה-PC כעל “מחובר או לא מחובר” אחד, אלא מפרידים בין ה-LAN הפיזי או ה-Wi-Fi לבין ה-VPN. למשל, אם הצד הפיזי מציג LocalNetwork אבל התכנון הוא לצאת לאינטרנט דרך ה-VPN, שורה אחת על הצד הפיזי לא מספיקה כדי לקבוע שמשהו תקול. קוראים את ה-connection profiles מפרק 4 יחד עם הנתיב שבו התעבורה באמת עברה.⁵⁶

flowchart TB
    accTitle: מפרידים בין נתיב החיבור לבין משפחת ה-IP
    accDescr: מפרידים בין LAN פיזי ל-VPN ובין IPv4 ל-IPv6, ומתאימים בין הנתיב שבו עברה התעבורה לבין כל קביעה.
    pc["לרשום את החיבורים"] --> physical["LAN פיזי ו-Wi-Fi"]
    pc --> vpn["מתאם VPN"]
    physical --> p["קביעות IPv4 ו-IPv6"]
    vpn --> v["קביעות IPv4 ו-IPv6"]
    p --> route["הצלבה עם נתיב התעבורה בפועל"]
    v --> route

איור 5: מפרידים בין חיבור פיזי ל-VPN ובין IPv4 ל-IPv6, ומשווים לנתיב התעבורה בפועל.

אותו דבר לגבי IPv4 ו-IPv6. NCSI מטפל בשני ה-active probes במקביל, והצלחה של אחד מהם מספיקה כדי לקבוע שיש חיבור לאינטרנט. העובדה שאחד מהם אינו Internet לא מלמדת לבדה שכל ה-PC לא מחובר. איזו מהן יישום מסוים השתמש, בודקים בנפרד בתעבורה של אותו יישום.¹

אם רוצים להשוות בניתוק ה-VPN, עשו זאת במחשב בדיקה שאושר על ידי הארגון או בחלון שינוי מאושר. אין לנתק VPN בניתוק קבוע (always-on) בלי רשות רק לצורך החקירה.

3. הדבר הראשון שמפרידים: “רק התצוגה, או שגם התעבורה נכשלת”

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

במקום “הרשת עובדת”, כדאי להיות ספציפיים עד כדי כך שאפשר לכתוב “בשעה הזו, ביישום הזה, ליעד הזה, הפעולה הזו הצליחה”. כך מצמצמים את מה שצריך לבדוק.

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

מכאן ואילך אלה שלבי החקירה. מתקדמים בסדר הזה: לתעד את המצב → לקרוא את הגדרות יעד הבדיקה → להשוות תעבורה ידנית → לאמת ברשומות של NCSI עצמו. אין לשנות הגדרות proxy, VPN או אבטחה של הארגון בלי רשות; מתחילים מקריאה בלבד וממספר קטן של בדיקות תעבורה.

4. לפני שמשנים הגדרות, מאתרים היכן זה נכשל

4.1 לתעד את מועד ההתרחשות ואת מצב החיבור

קודם כל רושמים את מועד ההתרחשות, את ה-build של ה-OS, את שיטת החיבור, אם יש VPN ואיזה יישום נכשל. את גרסת ה-OS אפשר לבדוק עם winver. אחר כך מציגים את ה-connection profiles ב-PowerShell.⁵

Get-Date -Format o
Get-NetConnectionProfile |
    Select-Object Name, InterfaceAlias, InterfaceIndex,
        NetworkCategory, IPv4Connectivity, IPv6Connectivity |
    Format-Table -AutoSize

מה שקוראים הוא שם החיבור, InterfaceAlias ו-InterfaceIndex, וגם IPv4Connectivity ו-IPv6Connectivity. כשמופיעות כמה שורות, קוראים אותן תוך שמירה על השיוך של כל תוצאה לחיבור שלה — כדי להשוות בהמשך בין הבדיקות הידניות והלוגים לבין תוצאות מאותו זמן ומאותו חיבור.

הערכים Public / Private / DomainAuthenticated של NetworkCategory הם סיווג נפרד מקביעת חיבור האינטרנט. שינוי מ-Public ל-Private אינו שלב תיקון כללי ל”אין אינטרנט”. הפלט עשוי לכלול שמות של רשתות פנימיות, ולכן לפני מסירה לגורם שלישי יש להשמיט פרטים מזהים שאין בהם צורך.⁵

4.2 לקרוא למה המחשב הזה מוגדר לבדוק

לפני שמנסים את יעד הבדיקה הסטנדרטי, בודקים אם גם במחשב הזה ההגדרות זהות. הקוד הבא רק מציג ערכים; הוא לא משנה את ה-Registry. הוא קורא את יעדי הבדיקה של IPv4 ושל IPv6, את גוף התשובה הצפוי, ואת ה-policies ששולטים, בין השאר, ב-active test.¹⁷

$internetKey = 'HKLM:\SYSTEM\CurrentControlSet\Services\NlaSvc\Parameters\Internet'
Get-ItemProperty -LiteralPath $internetKey |
    Select-Object EnableActiveProbing, ActiveWebProbeHost,
        ActiveWebProbePath, ActiveWebProbeContent,
        ActiveWebProbeHostV6, ActiveWebProbePathV6,
        ActiveWebProbeContentV6 |
    Format-List

$policyKey = 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\NetworkConnectivityStatusIndicator'
if (Test-Path -LiteralPath $policyKey) {
    Get-ItemProperty -LiteralPath $policyKey |
        Select-Object NoActiveProbe, DisablePassivePolling |
        Format-List
} else {
    'אין policy של NCSI בנתיב ה-Registry הזה.'
}

ActiveWebProbeHost ו-ActiveWebProbePath הם יעד הבדיקה, ו-ActiveWebProbeContent הוא גוף התשובה הצפוי. יש לתעד גם את הערכים ששמם כולל V6. אם הוגדר יעד בדיקה מותאם אישית, יש להתאים גם את הבדיקות הידניות שלהלן לאותה הגדרה ולמדיניות הניהול.

פלט שאומר שאין מפתח policy פירושו שאין הגדרות בנתיב הזה. זו אינה הוכחה שאין הגדרות ניהול בכלל, כולל דרך MDM. אין ליצור מפתח שלא נמצא מתוך ניחוש; מאמתים מול המנהל.

לגבי proxy, בודקים את מסכי ההגדרות של Windows ואת ה-policies הניהוליות. להגדרות WinHTTP, בסביבות שתומכות בכך netsh winhttp show advproxy, ובסביבות ישנות יותר netsh winhttp show proxy — אלה נותנים חומר להשוואה. אבל מה שנלמד כאן הוא ההגדרה. את הנתיב ש-NCSI בחר בפועל דרך PAC או automatic detection יש להצליב עם רשומות התעבורה שיתוארו בהמשך.⁸⁴

4.3 להפריד בין פתרון השם לבין הצלחת חיבור ה-TCP

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

Resolve-DnsName -Name 'www.msftconnecttest.com' -Type A -DnsOnly
Test-NetConnection -ComputerName 'www.msftconnecttest.com' -Port 80 -InformationLevel Detailed

-Type A ב-Resolve-DnsName מגדיר חיפוש של כתובת IPv4. בשלב הראשון מתבוננים בהגדרות ה-DNS השגרתיות כמו שהן. מעבר מיידי ל-DNS ציבורי משנה גם את פתרון השמות הפנימי וגם את מדיניות הניהול, ומקשה על מעקב אחר הבעיה המקורית.⁹

מה ש-Test-NetConnection -Port 80 מלמד הוא חיבור ה-TCP ליעד שצוין. הוא אינו בודק את גוף ה-HTTP או authentication של proxy. בסביבה שבה חיבורים ישירים אסורים ומותר רק מעבר דרך HTTP proxy, כשל בבדיקת ה-TCP הזו יכול להיות תקין לחלוטין. יש לשמור גם את InterfaceAlias ו-SourceAddress, כדי לדעת מאיזה נתיב הגיעה התוצאה.⁶

flowchart TB
    accTitle: אילו שאלות עונות הבדיקות הידניות
    accDescr: פתרון שם, חיבור TCP ותשובת HTTP מכסים טווחים שונים, ולכן אין להתייחס להצלחה באחד מהם כערובה לשכבה הבאה.
    name["לפתור את השם ב-DNS"] --> tcp["לבדוק חיבור TCP ליעד"]
    tcp --> http["לבדוק תשובת HTTP ואת גוף התשובה"]
    http --> own["להשוות לרשומות של NCSI עצמו"]
    tcp -.-> proxy["נתיב אחר בסביבה שבה proxy חובה"]

איור 6: פתרון השם, חיבור ה-TCP ותשובת ה-HTTP — כל אחד מאמת דבר אחר, לפי הסדר.

4.4 ב-HTTP מסתכלים לא רק על הסטטוס אלא גם על גוף התשובה

בשלב הבא בודקים אם חוזר גוף התשובה של הבדיקה שתואר בפרק 1. במחשב שבו זמין curl.exe, מריצים את הפקודה הבאה מספר קטן של פעמים. כותבים במפורש .exe כדי לא להתבלבל עם ה-alias של PowerShell.

curl.exe -q --connect-timeout 5 --max-time 15 --include 'http://www.msftconnecttest.com/connecttest.txt'

--include מציג גם את ה-headers וגם את גוף התשובה. הוגדרו timeouts גם לחיבור וגם לפעולה כולה, ומכיוון ש--L לא ניתן, curl לא ממשיך אוטומטית ליעד ההפניה וכך רואים את התשובה הראשונה. ה--q בהתחלה אומר ל-curl לא לקרוא את קובץ ההגדרות המוגדר כברירת מחדל, אבל הוא לא מוחק משתני סביבה הקשורים ל-proxy.¹⁰

דוגמה מינימלית לתוכן הצפוי היא זו שלהלן. היא מיועדת להסבר ואינה לוג נמדד מהמאמר הזה. בפועל מופיעים גם headers נוספים.²

HTTP/1.1 200 OK
...

Microsoft Connect Test

החשוב כאן הוא שהבדיקה הידנית אינה מחליפה את NCSI — היא חומר להשוואה. curl אינו בדיקה שיורשת באותה צורה את ה-PAC של Windows או את מצב ה-authentication של ה-browser. תוצאה של “ה-browser הצליח, curl נכשל” לבדה אינה קובעת ש-NCSI תקול.

מאמתים מול המנהל איך אמורים להשתמש ב-proxy, ואין לכתוב credentials ישירות להיסטוריית הפקודות. גם אם בדיקת ה-HTTP הזו מצליחה, אין בכך ערובה לכך שה-HTTPS וה-authentication של API עסקי יצליחו.

4.5 ולבסוף, לחפש את הרשומות שבהן NCSI באמת נכשל

אחרי שהבדיקות הידניות הבהירו את המועמדים, בודקים את ההתנהגות של NCSI עצמו. נקודת הכניסה היא ב-Event Viewer, תחת “Applications and Services Logs → Microsoft → Windows → NCSI”. בודקים את ה-Operational log בסביבות מועד ההתרחשות.¹¹

לא מסתפקים בשורת שגיאה אחת; קוראים ברצף באיזה interface זה התחיל והאם זה הושלם, מה הייתה סיבת הכשל, ואיך מצב הקישוריות השתנה אחר כך. מצליבים באותו זמן ובאותו נתיב של הבדיקות הידניות, ובמידת הצורך משלבים packet capture מאושר.¹¹

flowchart TB
    accTitle: סדר הקריאה של הלוגים של NCSI
    accDescr: מחברים בין התחלה, סיום, סיבת כשל ושינוי במצב — לפי זמן ו-interface.
    start["באיזה נתיב זה התחיל"] --> finish["האם זה הושלם"]
    finish --> reason["קוד תוצאה וסיבת הכשל"]
    reason --> state["מצב הקישוריות אחר כך"]
    state --> correlate["הצלבה עם רשומות תעבורה מאותו זמן"]

איור 7: חיבור בין ההתחלה לשינוי במצב מקל על מעקב אחר מה שהיה שונה בין הבדיקה הידנית לבין NCSI.

אם קוד התוצאה הוא שגיאת WinHTTP, בודקים את משמעותה בטבלת WinHTTP. למשל, 12007 פירושו שהשם לא נפתר, ו-12002 הוא timeout. אבל מה שמתקבל הוא רק רמז לשלב שבו זה נכשל; זה לבדו לא קובע שכשל שרת ה-DNS או שהקו נותק.¹²

אם אין די פירוט, המנהל מפעיל את ה-Analytic log דרך “Show Analytic and Debug Logs”. זהו שינוי בהגדרות ה-diagnostics, ולכן רושמים את מועד ההפעלה, משחזרים את הבעיה, ואחרי האיסוף מחזירים את המצב לקדמותו. הפעלה אינה מאפשרת לשלוף בדיעבד אירועים מפורטים מלפני ההפעלה.¹¹

בנוסף, חיבור מחדש של ה-Wi-Fi או השבתה של מתאם לצורך שחזור הבעיה עלולים לנתק גם חיבורי ניהול כמו RDP. אין להריץ אותם בלי התראה על מחשב ייצור או על מחשב שמפעילים מרחוק. רשומות תעבורה עשויות לכלול שמות מארחים, כתובות IP ומידע הקשור ל-authentication — ולכן גם מקום השמירה והיקף השיתוף מוגבלים.

בדוגמת החברה מהפתיחה, כאן מצליבים בין ה-403 של ה-HTTP הידני, הלוג של NCSI מאותו זמן, ורשומות הדחייה של ה-proxy שהמנהל יכול לראות. אם רק יעד הבדיקה נדחה — מתקנים את הכלל ובודקים מחדש. ואם רק הבדיקה הידנית עברה בנתיב אחר — בודקים מחדש את תנאי ההשוואה. אין לקבוע מהמספר 403 לבדו ש”מדובר בבאג של NCSI” או ב”בעיה ב-proxy שלנו”; בוחרים את הפעולה הבאה לפי הרשומות. זו דוגמת בידוד היפותטית, לא ממצאים של מקרה אמיתי.

5. לא לנסות לתקן רק את התצוגה בפתרונות ישנים

לא להתבלבל בין תעבורת ה-DNS של Windows 11 לבין ה-DNS probe של גרסאות ישנות

במדריכים ישנים מופיע DNS probe אל dns.msftncsi.com. ואולם, ה-FAQ הרשמי של NCSI מסביר שה-active probe ב-Windows 11 ואילך משתמש ב-HTTP. גם אם ברשומה של Windows 11 יש תעבורת DNS, ייתכן שהיא פתרון השם של יעד ה-HTTP.²

flowchart TB
    accTitle: מבדילים בין תפקידי תעבורת ה-DNS
    accDescr: קוראים את פתרון השם של יעד ה-HTTP ב-Windows 11 ואת ה-DNS probe של גרסאות ישנות כשני דברים שונים.
    dns["ברשומה יש תעבורת DNS"] --> purpose{"לשם מה התעבורה"}
    purpose --> http["פתרון השם של יעד ה-HTTP"]
    purpose --> legacy["ה-DNS probe של גרסאות ישנות"]
    http --> win11["עשוי להידרש גם ב-Windows 11"]
    legacy --> version["לבדוק את גרסת ה-OS ואת הלוגים בפועל"]

איור 8: תעבורת ה-DNS שמאתרת את יעד ה-HTTP וה-DNS probe עצמו הם שני דברים שונים.

לכן את ההסבר הישן שלפיו “כל שאילתת DNS נפרדת מ-HTTP חייבת להצליח” אי אפשר להפוך לכלל שחל על כל גרסאות Windows. קוראים את גרסת ה-OS שנחקרת יחד עם הלוגים בפועל.

נקודה מבלבלת נוספת היא שם מקום ההגדרות. ב-Windows 11 הרכיב שמריץ את NCSI עבר מה-NLA המסורתי לצד של Network List Manager, אבל הגדרות כמו יעד הבדיקה עדיין משתמשות בנתיב ה-Registry שכולל NlaSvc מפרק 4. אין להסיק איזה שירות מריץ את זה רק מכך שבנתיב כתוב NlaSvc.¹

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

קביעת EnableActiveProbing ל-0, או איסור ה-active test ב-policy, הן הגדרות שמגבילות את בדיקת הקישוריות. הן אינן פעולה שמתקנת כשל DNS או נתיב proxy. יש להפריד בין אימוץ כזה כמדיניות ניהול ברשת מבודדת לבין שינוי שמטרתו להעלים את ההתראה. גם Microsoft אינה ממליצה להשבית את ה-active probe כפתרון לבעיות NCSI.⁷¹

מאותה סיבה, החזרת תשובת הצלחה מזויפת, כיבוי מלא של ה-firewall, או השבתת IPv6 בלי ביסוס — אינם שלבים ראשונים. כי שינוי בתצוגה ושיפור בתעבורה שאתם רוצים להשתמש בה הם שני דברים שונים.

flowchart TB
    accTitle: לא לשפוט תיקון לפי התצוגה בלבד
    accDescr: אחרי שינוי הגדרה בודקים לא רק את השינוי בתצוגה, אלא גם את נקודת הכשל ואת השיפור בתעבורה הנדרשת.
    change["שינוי מוצדק"] --> probe["לבדוק מחדש את תעבורת הבדיקה"]
    change --> app["לבדוק מחדש את התעבורה הנדרשת"]
    probe --> judge["לשפוט את השיפור לפי שתי התוצאות"]
    app --> judge

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

גם בתיקון כללי ההרשאה בארגון, לא מסיימים ברישום סטטי של כתובות IP ממאמר ישן. תשתית ההפצה של יעד הבדיקה הציבורי של NCSI עשויה להשתנות, ו-Microsoft מנחה להימנע מכללי הרשאה שתלויים בכתובת IP מסוימת. מאמתים מול המנהל כללים שמתאימים ליעד הבדיקה, לשירות ולנתיב בפועל.²

6. למפתחים: לא להחליט “לא לתקשר” רק לפי NCSI

כל מה שנאמר עד כה נוגע גם לתכנון של יישומי Windows. אם ה-OS מציג “אין אינטרנט” ואתם מסמנים את היישום כ-offline בלי לנסות ולו פעם אחת את הבקשה שצריך — ייתכן שאתם עוצרים תעבורה שהייתה עובדת. ולהפך: גם המחשבה ש-API עסקי חייב להצליח כי ה-OS מציג Internet היא טעות.

INetworkListManager::get_IsConnectedToInternet, שמחזיר את קביעת הקישוריות של כל ה-OS, הוא API שמחזיר את מצב חיבור האינטרנט של המחשב המקומי. הוא לא מבטיח ש-API מסוים או תיקיית שיתוף פועלים, ש-authentication מצליח, או שיש לכם הרשאה להשתמש בהם.¹³

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

flowchart TB
    accTitle: מנהלים בנפרד את קביעת ה-OS ואת תוצאת התעבורה העסקית
    accDescr: משתמשים במידע הקישוריות של ה-OS כרמז, ונותנים לתעבורה הנדרשת טיפול עצמאי בהצלחה ובכשל.
    status["מצב הקישוריות של ה-OS"] --> hint["רמז לתצוגה ולחיבור מחדש"]
    request["הבקשה הנדרשת"] --> outcome{"התוצאה בפועל"}
    outcome --> ok["טיפול כהצלחה"]
    outcome --> error["תיעוד סיבת הכשל"]
    error --> retry["ניסיון חוזר לאחר אימות שהדבר בטוח"]

איור 10: משתמשים בקביעה של ה-OS כרמז, ובמקביל נותנים לתעבורה העסקית טיפול נפרד בהצלחה ובכשל.

גם בלוג לא מכנסים הכול למילה “offline”, אלא מתעדים את השלב שנצפה שבו זה נכשל: DNS, חיבור, TLS, authentication, תשובת HTTP וכדומה. לבקשות מגדירים timeout ו-cancellation כדי לא להשאיר את ה-UI ממתין.

עם זאת, לניסיון חוזר אחרי timeout יש הסתייגות נפרדת. פעולת עדכון כמו ביצוע הזמנה או העברת כספים עשויה כבר להתבצע בצד השני גם אם התשובה לא הספיקה לחזור. אין להחליט “עבר ה-timeout, לכן זה לא בוצע” ולשלוח שוב; יש לקבוע כמפרט היישום אם מותר לנסות שוב, איזה מנגנון מונע כפילות, ואיך מבררים את התוצאה. זו אינה בעיה ש-NCSI יפתור במקומכם.

7. סיכום: לקרוא את התצוגה ואת התעבורה כשתי עובדות נפרדות

“הרשת עובדת אבל כתוב שאין אינטרנט” אינו בהכרח סתירה. החיבור ל-Wi-Fi, התקשורת עם הגורם שאליו רוצים להגיע, והקביעה של Windows עצמו דרך NCSI — כל אחד מהם מאמת דבר אחר.

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

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

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

• Windows Firewall ואפליקציות עסקיות
• המדריך המעשי ל-Certificate Store ב-Windows

קישורים למקורות

נבדק ב-11 בספטמבר 2026. בהבדלים בין גרסאות OS ניתנת עדיפות ל-FAQ הרשמי של NCSI, והשלבים במדריכים ישנים שמיועדים ל-clients ישנים אינם נחשבים כמפרט קבוע של Windows 11. גם שמות התצוגה של הלוגים והפקודות הזמינות יש לאמת מול ה-build של ה-OS ומול הגדרות הניהול בפועל.

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

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

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

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

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

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

שאלות נפוצות

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

למה Windows מציג "אין אינטרנט" כשאני מחובר ל-Wi-Fi?

מכיוון שהחיבור ל-Wi-Fi, התקשורת עם השירות שאתם רוצים, וקביעת הקישוריות ש-Windows מגיע אליה דרך NCSI הם שלושה דברים שונים. התצוגה יכולה לסתור את המציאות לא רק כשהקו עצמו נופל, אלא גם בגלל בעיות DNS, proxy, VPN או captive portal שמשפיעות על תעבורת הבדיקה. קודם כל בודקים מה באמת מצליח לתקשר.

אם אתר נפתח ב-browser, אפשר להסיק שגם NCSI תקין?

אי אפשר. היעד, ה-proxy שנבחר, מצב ה-authentication, IPv4 מול IPv6 ומועד הבקשה עשויים להיות שונים. את הגישה הידנית מתייחסים כחומר להשוואה, ומאמתים מול ה-event logs של NCSI עצמו, ובמידת הצורך מול packet capture.

האם ב-Windows 11 עדיין נדרש DNS probe אל dns.msftncsi.com?

ה-FAQ הרשמי של NCSI מסביר שה-active probe ב-Windows 11 ואילך משתמש ב-HTTP. יש להפריד בין תעבורת ה-DNS שפותרת את יעד ה-HTTP לבין ה-DNS probe של גרסאות ישנות. הנקודה החשובה היא לא להניח באופן גורף שכל בקשה בהליך ישן היא הכרחית.

אם נקבע EnableActiveProbing ל-0 זה יתקן את הבעיה?

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

אם NCSI מציג Internet, מובטח שאגיע למערכות העסקיות?

לא בהכרח. קביעת הקישוריות של ה-OS לא מבטיחה ש-API מסוים או תיקיית שיתוף פועלים, שה-authentication מצליח, או שיש לכם הרשאה להשתמש בהם. יישום צריך לשלוח את התעבורה שהוא באמת צריך, ולטפל ב-timeout, ב-cancellation, בסוג הכשל ובשאלה אם ניסיון חוזר בטוח.

פרופיל הכותב

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

Go Komura

מנהל KomuraSoft LLC

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