VPN לא מתחבר — מדריך פתרון תקלות מקיף לטכנאי Helpdesk (2026)

אם אתם עובדים ב-Helpdesk, אתם מכירים את השיחה הזו בעל-פה: "לא מצליח להתחבר ל-VPN, אני עובד מהבית, זה דחוף!". בכנות, זו אחת הקריאות הכי שכיחות בכל מחלקת IT, ובמיוחד מאז שהמודל ההיברידי הפך לסטנדרט. אז במקום לרוץ בכל פעם בין כמה מאמרים שונים, ריכזתי כאן את כל מה שטכנאי צריך — זרימת אבחון מסודרת, כל קודי השגיאה הנפוצים של Windows VPN ב-2026, פתרונות מעשיים לבעיות DNS ב-Split Tunneling, התמודדות עם MTU ו-Fragmentation, וגם שיטות עבודה מומלצות ל-AlwaysOn VPN ו-WireGuard.

נצלול לזה.

זרימת אבחון VPN: 5 הצעדים הראשונים

לפני שצוללים לקודי שגיאה ספציפיים, חשוב לעבור על רשימת אבחון בסיסית. מניסיון שלי, ב-80% מהקריאות (לפחות) הסיבה היא אחת מהבאות:

1. אינטרנט תקין? בקשו מהמשתמש לפתוח https://example.com. אם אין גישה — הבעיה כלל לא ב-VPN.
2. שעון מערכת מסונכרן? סטייה של יותר מ-5 דקות שוברת אימות Kerberos ותעודות IPSec. כן, זה באמת קורה.
3. סיסמת המשתמש פגה? שגיאה 691 לעיתים מסווה סיסמה שפגה ב-AD — תופעה שראיתי שוב ושוב.
4. חיבור מרשת חדשה? מלון, שדה תעופה או 4G סלולרי — לעיתים חוסמים פורטים VPN (UDP 500, 4500, TCP 1723).
5. VPN client מעודכן? גרסאות ישנות של FortiClient, AnyConnect או GlobalProtect לא תמיד מסתדרות עם Windows 11 24H2 ומעלה.

קודי שגיאה נפוצים ב-Windows VPN — טבלת אבחון מהירה

שמרו את הטבלה הזו בסימנייה. היא תחסוך לכם זמן בכל קריאה שלישית:

קוד שגיאה	משמעות	פתרון מהיר
691	אימות נכשל	בדוק שם משתמש/סיסמה, פרוטוקול אימות (MS-CHAPv2/EAP)
720	בעיית WAN Miniport / pool כתובות מוצה	הסרה והתקנה מחדש של WAN Miniport, הגדלת DHCP scope
789	L2TP/IPSec — כשל במשא ומתן	בדוק PSK/תעודה, אפשר L2TP Passthrough בנתב
800	השרת לא נגיש	בדוק קישוריות, פיירוול ארגוני, פורטים פתוחים
809	השרת לא מגיב — ככל הנראה NAT/Firewall	פתח UDP 500/4500, או עבור ל-SSTP על TCP 443
812	מדיניות שרת חוסמת	בדוק NPS Policy, התאם פרוטוקול אימות בצד השרת והלקוח
13801	בעיית IKE — תעודה לא חוקית	בדוק תוקף תעודת השרת ושרשרת CA במחשב הלקוח

שגיאה 691 — אימות נכשל

שגיאה 691 פירושה ש-VPN Server דחה את האימות. הסיבות הנפוצות:

• סיסמה שגויה או Caps Lock דולק (כן, עדיין).
• חשבון נעול ב-Active Directory — בדקו עם Get-ADUser -Identity %username% -Properties LockedOut.
• פרוטוקול אימות לא תואם — הלקוח מנסה PAP אך השרת דורש MS-CHAPv2.
• סיסמה שפגה. ה-VPN client לרוב לא מציג חלון לשינוי סיסמה, וזה בדיוק מה שהופך את התקלה למתעתעת.

בדיקת הגדרות אימות בצד הלקוח דרך PowerShell:

Get-VpnConnection -Name "CorpVPN" | Select-Object Name, AuthenticationMethod, EncryptionLevel

שגיאה 720 — WAN Miniport או IP Pool מוצה

שגיאה 720 בדרך כלל נגרמת מ-WAN Miniport פגום או מ-DHCP Scope של ה-RRAS שמוצה. אם בארגון שלכם ה-VPN Pool הוא /24 ויש 250 עובדים מרוחקים — נחשו כמה זמן ייקח עד שזה ייגמר. כדי לתקן:

1. פתחו Device Manager, הציגו Hidden devices.
2. תחת Network adapters, הסירו את כל ה-WAN Miniport (IP, IPv6, IKEv2, L2TP, PPTP, SSTP).
3. בחרו Action → Scan for hardware changes.
4. בצד השרת — הגדילו את ה-Static IP Pool ב-RRAS או הרחיבו את ה-DHCP Scope.

שגיאה 789 — L2TP/IPSec נכשל

שגיאה זו מתרחשת לעיתים קרובות בחיבור מאחורי NAT (כלומר, כמעט תמיד מהבית). פתרונות:

• ודאו שה-PSK זהה בצד השרת ובצד הלקוח — שווה לבדוק שוב, גם אם נשבעתם שזה תקין.
• הפעילו IPSec Passthrough בנתב הביתי, במיוחד בנתבים זולים שספק האינטרנט סיפק.
• הוסיפו את מפתח הרישום הבא כדי לאפשר L2TP מאחורי NAT:

reg add HKLM\SYSTEM\CurrentControlSet\Services\PolicyAgent /v AssumeUDPEncapsulationContextOnSendRule /t REG_DWORD /d 2 /f

נדרשת הפעלה מחדש של המחשב לאחר השינוי. אל תסמכו על "Sign out" — זה לא יעבוד.

שגיאה 800 ו-809 — השרת לא נגיש

לרוב הסיבה היא חסימת פורטים. השתמשו ב-Test-NetConnection כדי לאמת קישוריות:

Test-NetConnection -ComputerName vpn.contoso.com -Port 443
Test-NetConnection -ComputerName vpn.contoso.com -Port 4500

אם הפורטים חסומים — מומלץ לעבור ל-SSTP (TCP 443) או IKEv2 על UDP 4500. SSTP, אגב, עובר כמעט בכל פיירוול ציבורי כיוון שהוא נראה בדיוק כמו תעבורת HTTPS רגילה. זו הסיבה שבמלונות ובכנסים זה לרוב הפרוטוקול היחיד שעובד.

שגיאה 812 — מדיניות שרת חוסמת

שגיאה זו פירושה ש-NPS (Network Policy Server) דחה את הבקשה. בדקו:

• ב-NPS Server — Event Viewer תחת Custom Views → Server Roles → NPS.
• שהמשתמש שייך לקבוצת AD המורשית במדיניות הרשת. (לא, "Domain Users" לא תמיד מספיק.)
• שפרוטוקול האימות (PEAP, EAP-TLS) תואם בין הלקוח לשרת.

בעיות DNS ב-VPN: התקלה ה"שקופה" ביותר

תרחיש קלאסי: ה-VPN מתחבר, אבל המשתמש מתלונן ש"לא נפתחים לו שיתופים" או ש"האינטרנט פתאום איטי". ב-99% מהמקרים? תקלת DNS.

איך Windows 11 בוחר שרת DNS?

Windows 10/11 שולחים שאילתות DNS מהממשק עם Interface Metric הנמוך ביותר. אם מתאם ה-Ethernet קיבל מטריק נמוך מהמתאם של ה-VPN, השאילתות הולכות ל-DNS המקומי במקום ל-DNS הארגוני. התוצאה: Internal hostnames פשוט לא נפתרים, והמשתמש בטוח שהבעיה אצלכם.

תיקון מהיר: שינוי Interface Metric

Get-NetIPInterface | Sort-Object InterfaceMetric | Format-Table InterfaceIndex, InterfaceAlias, InterfaceMetric -AutoSize

# Example: lower the VPN metric so DNS queries route through it
Set-NetIPInterface -InterfaceAlias "CorpVPN" -InterfaceMetric 1

הגדרת DNS Suffix ו-Split Tunneling

Set-VpnConnection -Name "CorpVPN" -SplitTunneling $True
Set-VpnConnection -Name "CorpVPN" -DnsSuffix "corp.contoso.com"

# Configure NRPT (Name Resolution Policy Table) — preferred approach in modern Windows
Add-VpnConnectionTriggerDnsConfiguration -ConnectionName "CorpVPN" -DnsSuffix "corp.contoso.com" -DnsIPAddress 10.0.0.10,10.0.0.11

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

בדיקת תקינות DNS דרך VPN

nslookup dc01.corp.contoso.com 10.0.0.10
netsh namespace show effectivepolicy
ipconfig /all
ipconfig /flushdns

תקלות MTU ו-Packet Fragmentation

תרחיש שגרתי, ומעצבן: ה-VPN מתחבר אבל דפי אינטרנט נתקעים, RDP מתחיל ונופל, או קבצים גדולים נכשלים בהעברה. הסיבה — MTU גבוה מדי שגורם לפיצול חבילות שלא עובר ב-Tunnel. זו אחת התקלות הכי קשות לאיתור, כי "החיבור עובד", אבל לא באמת.

איך מגלים את גודל ה-MTU האופטימלי?

# Send 1472-byte ICMP packet without fragmentation
ping -f -l 1472 8.8.8.8

# If "Packet needs to be fragmented" — reduce by 10 each time:
ping -f -l 1462 8.8.8.8
ping -f -l 1452 8.8.8.8

הגודל הגדול ביותר שעבר בלי פיצול + 28 (כותרת ICMP+IP) = MTU האופטימלי. עבור רוב חיבורי VPN ב-PPPoE — 1492. עבור L2TP/IPSec — 1400. אלה ערכי "כתב יד", אבל מתחילים מהם.

שינוי MTU בממשק VPN

netsh interface ipv4 show subinterfaces
netsh interface ipv4 set subinterface "CorpVPN" mtu=1400 store=persistent

VPN מתחבר אבל אין גישה למשאבים

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

1. Routing: הריצו route print וודאו שה-Subnet הארגוני מנותב דרך מתאם ה-VPN.
2. DNS: ודאו ש-nslookup <hostname>.corp.contoso.com מחזיר IP פנימי, לא Public IP.
3. Firewall ארגוני: בדקו ב-RRAS/ASA אם ה-Subnet של ה-VPN Pool מורשה לגשת ל-VLAN של השרתים.
4. SMB Signing/Kerberos: אם RDP נכשל עם "Authentication Error", זה לרוב סטיית שעון או מדיניות SMB Signing חדשה (תודה, Patch Tuesday).

AlwaysOn VPN — בעיות נפוצות ב-2026

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

• Device Tunnel לא עולה: ודאו שתעודת המכשיר ב-Computer Store ולא ב-User Store. בדקו עם certutil -store My תחת SYSTEM context.
• User Tunnel נכשל אחרי שינוי סיסמה: בעיה ידועה — ה-Profile של AlwaysOn נשמר ל-Cred Manager. השתמשו ב-rasdial /disconnect ואז התחברו מחדש.
• ProfileXML מ-Intune לא מגיע: בדקו Event Viewer → Applications and Services Logs → Microsoft → Windows → DeviceManagement-Enterprise-Diagnostics-Provider → Admin לאיתור שגיאות הפצה.

פקודות חיוניות לאבחון AlwaysOn VPN

# View installed VPN profiles
Get-VpnConnection -AllUserConnection
Get-VpnConnection

# Detailed Always On status
Get-NetIPInterface -InterfaceAlias "AzureVPN" | Format-List

# Force resync of Intune-pushed VPN profiles
Get-ScheduledTask -TaskName "*PushLaunch*" | Start-ScheduledTask

WireGuard ופרוטוקולים מודרניים

ב-2026, WireGuard הפך לסטנדרט בארגונים שמחפשים ביצועים. בהשוואה ל-OpenVPN, הוא לרוב מהיר ב-30-50% וצורך פחות סוללה במכשירים ניידים. דעה אישית? אם אתם נתקלים ב-VPN איטי באופן עקבי, וההנהלה רומזת על תלונות, זה בדיוק הזמן הנכון לפתוח שיחה על מעבר. הקוד של WireGuard בנוי ב-~4,000 שורות (לעומת מאות אלפים ב-OpenVPN), וזה לא רק מספר — זה אומר פחות פאזל לאבחון.

טיפ קטן לאבחון WireGuard ב-Windows: הלוגים נמצאים ב-%ProgramFiles%\WireGuard\Data\log.bin, וניתן לצפות בהם דרך GUI הלקוח (View Log).

צ'קליסט מקוצר לטכנאי Helpdesk

שמרו, הדפיסו, הצמידו לקיר. לא צוחק:

• ☐ אינטרנט עובד ללא VPN?
• ☐ שעון המערכת תקין?
• ☐ סיסמת המשתמש בתוקף ב-AD?
• ☐ Test-NetConnection אל פורט VPN מצליח?
• ☐ Antivirus/Firewall ארגוני מאפשר VPN client?
• ☐ ipconfig /all — האם מתאם ה-VPN קיבל IP?
• ☐ route print — האם המסלולים נכונים?
• ☐ nslookup מצליח לפתור שמות פנימיים?
• ☐ MTU נבדק עם ping -f -l?
• ☐ Event Viewer ב-VPN Server (RRAS/NPS) לא מציג דחיות?

שאלות נפוצות (FAQ)

למה ה-VPN שלי מתחבר אבל אין אינטרנט?

הסיבה הכי נפוצה היא Force Tunnel שמנתב את כל התעבורה דרך ה-VPN, כולל יציאה לאינטרנט — אבל ה-VPN Server לא מאפשר Internet Breakout. הפתרון: להפעיל Split Tunneling עם הפקודה Set-VpnConnection -Name "CorpVPN" -SplitTunneling $True, או לבטל את האפשרות "Use default gateway on remote network" בהגדרות ה-IPv4 של מתאם ה-VPN.

איך לתקן שגיאת VPN 789?

שגיאת 789 (L2TP/IPSec failure) נפתרת לרוב באחת מארבע דרכים: (1) ודאו ש-PSK זהה בלקוח ובשרת. (2) הפעילו L2TP Passthrough בנתב הביתי. (3) הוסיפו את מפתח הרישום AssumeUDPEncapsulationContextOnSendRule=2 תחת HKLM\SYSTEM\CurrentControlSet\Services\PolicyAgent והפעילו מחדש. (4) ודאו ששירות IKE and AuthIP IPsec Keying Modules פעיל.

למה ה-VPN שלי כל הזמן מתנתק?

ניתוקים חוזרים ב-VPN נובעים בדרך כלל מאחת מארבע סיבות: רשת אלחוטית לא יציבה, MTU שגוי שגורם ל-Packet Loss, Idle Timeout נמוך מדי בצד השרת, או IPSec Rekey שלא מצליח. בדקו עם ping -t אם יש Packet Loss בזמן החיבור, וב-VPN Server הגדילו את ה-Idle Timeout ל-3600 שניות.

איך פותחים את הפורטים הנכונים ל-VPN בפיירוול?

זה תלוי בפרוטוקול: PPTP דורש TCP 1723 ו-GRE Protocol 47. L2TP/IPSec דורש UDP 500, UDP 4500 ו-Protocol 50 (ESP). IKEv2 דורש UDP 500 ו-UDP 4500. SSTP משתמש רק ב-TCP 443 — מה שהופך אותו לבחירה הטובה ביותר ברשתות מסוננות. OpenVPN משתמש ב-UDP 1194 כברירת מחדל. WireGuard משתמש ב-UDP 51820.

מה ההבדל בין Split Tunneling ל-Full Tunneling?

ב-Full Tunneling (Force Tunnel) כל התעבורה — כולל גישה ל-Google ול-YouTube — עוברת דרך ה-VPN. זה מאפשר אכיפת מדיניות אבטחה אחידה, אבל מעמיס על השרת ומאט גלישה. ב-Split Tunneling, רק תעבורה אל יעדים פנימיים (10.x.x.x, 192.168.x.x) עוברת ב-Tunnel, השאר יוצא ישירות לאינטרנט. ב-2026, רוב הארגונים משתמשים ב-Split Tunneling עם NRPT לניהול DNS — שילוב שמשפר ביצועים ב-45-60% מבלי לפגוע באבטחה באופן משמעותי.

סיכום

פתרון תקלות VPN דורש גישה שיטתית: בדיקת קישוריות בסיסית, אימות מול AD, ניתוח קוד השגיאה הספציפי, ואז ירידה לפרטי DNS, MTU, ו-Routing. שמרו את צ'קליסט האבחון בראש כל קריאה — תופתעו כמה תקלות נפתרות בתוך דקות.

לאבחון מתקדם, הקפידו לאסוף Event Logs מצד הלקוח, צד ה-VPN Server, ו-NPS לפני שמסלימים את הקריאה לצוות התשתיות. זה גם יחסוך לכם הרבה "מה ניסית עד עכשיו?" ויעזור לבנות אמון מקצועי. בהצלחה.