ה-VPN מתחבר בבית אך נגמר לו הזמן ב-Wi-Fi של המלון
אותו מחשב נייד, אותו חשבון, רשת אחרת. קרא את קוד השגיאה כשלב, בדוק את השם, ואז תפוס את החבילה החיצונית לפני שתשנה הגדרה כלשהי.
המחשב הנייד מצטרף ל-Wi-Fi הביתי, הלקוח מתחבר בשלוש שניות, ואותו פרופיל נכשל במלון שעה לאחר מכן. דבר לא עודכן בינתיים. מעבר על זה עם לקוח מולך עוסק בעיקר בלדעת איזו שגיאה שייכת לאיזה שלב, כי המידע המועיל נמצא בקוד שהלקוח מדפיס, לא בעובדה שהוא נכשל. עבור על ארבעת השלבים שלמטה לפי הסדר ותדע אם שם, חבילה, פורט או מדיניות סירבו לך.
קרא את קוד השגיאה כשלב, לא כפסק דין
הלקוח מגיע לשלושה אבני דרך נפרדות לפני שקיימת מנהרה. הוא מפענח את שם השרת, הוא מקבל תשובה ממשהו ברשת, והוא מנהל משא ומתן על אסוציאציית אבטחה. לכל אבן דרך יש הודעת כישלון משלה, ו-Windows במיוחד נדיב בקודים מובחנים ברגע שאתה יודע לאיזה שלב הם שייכים.
| What the client says | Stage that failed | First thing to run |
|---|---|---|
| 868, name did not resolve | DNS, before any packet leaves for the server | Resolve-DnsName vpn.example.net |
| 721 or 806, remote computer did not respond | Outer protocol filtered, typically GRE or UDP | A capture on the local interface |
| 809, server not responding | A device in the path is dropping the outer flow | The same capture, from a second network |
| 789, security layer error | The security exchange started and was rejected | Certificate and proposal settings on both ends |
שניים מהקודים האלה אומרים שהרשת חפה מפשע. 789 אומר שהחבילות זרמו וששני הקצוות לא הסכימו על הצפנה, וזו בעיית תצורה שאתה יכול לתקן בבית. 868 אומר שאף חבילה לא הייתה צריכה לצאת, ולכן תכנון המנהרה לא רלוונטי עד שהשם ייפתר. סיווג הקוד לשלב הנכון חוסך יותר זמן מכל תפיסת חבילות, כי הוא אומר לך איזה משלושת השלבים הבאים לדלג עליו.
הייה זהיר כראוי אם הלקוח אינו Windows. לקוחות צד שלישי ממצים את רוב זה ל"החיבור נכשל", ולכן שני השלבים הבאים אינם נשענים על ההודעה כלל.
בדוק את השם לפני שאתה מאשים את המנהרה
רשתות של מלונות ושדות תעופה מיירטות DNS כל הזמן, ומפענח שמשיב בכתובת פורטל יוצר כשל שנראה בדיוק כמו שרת מת. השווה את מה שהמפענח המקומי אומר למה שמפענח ציבורי אומר:
Resolve-DnsName vpn.example.net -Type A
nslookup vpn.example.net 1.1.1.1
ipconfig /all | findstr /i "DNS Servers"אם שתי התשובות נבדלות, מפנים אותך ושאר האבחון מבוזבז עד שזה ייפתר. כתובת פורטל במיוחד תקבל בשמחה את חיבור ה-TCP ואז תיתקע, ולכן זה יכול להיראות כמו חסימת חומת אש כשאתה בודק בדפדפן.
כעת אמת שהכתובת שאליה אתה מתכוון להגיע היא זו שבשימוש. לקוחות מסוימים שומרים את הפענוח הקודם למשך כל חיי הפרופיל, כך שהתחברות מחדש אחרי שינוי ה-DNS עדיין הולכת לכתובת הישנה. סגור את הלקוח לגמרי לפני בדיקה חוזרת, במקום ללחוץ התנתק והתחבר באותו חלון.
גלה איזו חבילה חיצונית נעלמת
למנהרה יש זרימה חיצונית ששייכת כולה לנתיב בינך לבין השרת, וזו הזרימה שקופסאות ביניים מסווגות ומפילות. תפוס אותה בלקוח, ואז השווה רשת שעובדת לזו שנכשלת. ב-Windows התפיסה המובנית מספיקה למבט ראשון:
pktmon filter remove
pktmon filter add -p 500 -t UDP
pktmon start --capture --pkt-size 128
pktmon stop
pktmon etl2txt PktMon.etlמה שאתה רוצה לראות הוא אם החבילות שלך יוצאות בכלל, ואם משהו חוזר. חבילות שיוצאות בלי כלום בחזרה פירושן שהנתיב או הקצה הרחוק מפילים אותן; אם כלום לא יוצא, הלקוח מעולם לא הגיע לשליחה, מה שמצביע חזרה על פענוח שמות או על מדיניות חומת אש מקומית.
חזור על אותה בדיקה בנקודת גישה של טלפון. זו ההשוואה המאלפת ביותר שעומדת לרשותך, כי היא מסירה מהנתיב כל קופסה במלון תוך שמירה על המחשב הנייד, הלקוח והפרטים זהים. אם המנהרה עולה בנקודת הגישה, הפסק להסתכל בשרת. אם היא נכשלת גם שם, יש לך בעיית לקוח או חשבון שהרשת מעולם לא גרמה.
שנה מוביל אחד ובדוק שוב
ברגע שאתה יודע שהזרימה החיצונית מופלת, השאלה המעשית היא איזו זרימה הרשת כן מתירה. רוב הרשתות המוגבלות מתירות TCP 443 יוצא כי אחרת הן לא יכולות לתפקד, ולכן העברת המאזין לשם היא התשובה הרגילה. ב-OpenVPN זהו מתג בצד הלקוח עד שהשרת ישונה:
openvpn --config corp.ovpn --proto tcp-client --remote vpn.example.net 443 --verb 4ללקוחות IPsec יש מתג מקביל בלוחות ההגדרות שלהם, שמתואר בדרך כלל כ-IPsec over TCP או NAT traversal. שינוי שלו הוא גם אבחון: אם המנהרה עולה מעל TCP ומתה מעל UDP, הוכחת שהרשת מסננת UDP, וגם מצאת את ההגדרה שתזדקק לה בכל ביקור באתר הזה.
התנגד לפיתוי לכבות תכונות של הראוטר בניסיון הראשון. כיבוי בדיקה עם מצב או הגנה מפני הצפה ברשת של מלון לא זמין לך בכל מקרה, ובציוד שלך הוא מחליף הגנה אמיתית במחשב נייד אחד. רשום איזו הגדרה שינתה את התוצאה, ואז החזר אותה וחפש מוביל שהרשת כבר מתירה.
אמת את אותו פרופיל ברשת השנייה
לפני שאתה סוגר את הפנייה, הוכח שהשינוי שרד את היציאה מהבניין. התחבר מחדש ברשת המקורית עם ההגדרות המקוריות, תפוס את שלושים השניות הראשונות, ואמת שהלקוח מגיע לאותו מצב שאליו הגיע בנקודת הגישה:
pktmon filter add -p 443 -t TCP
pktmon start --capture
Get-VpnConnection -Name "Corp" | Select-Object ConnectionStatus, TunnelType, ServerAddressשווה לשמור את ההבחנה שהפקודה האחרונה חושפת: הפרופיל יכול לדווח על מנהרה מחוברת בזמן שהניתוב בפנים שגוי, וזה יוצר "ה-VPN מחובר אבל שום דבר לא עובד", שזה מאמר אחר. אם סוג המנהרה השתנה אחרי העריכה שלך, הפרופיל אינו זה שבדקת.
ואז כתוב את הממצא במקום שבו האדם הבא יסתכל. "הפרופיל הארגוני צריך TCP 443 באתר הזה; המלון מסנן UDP 500" הוא משפט שעמית יכול לפעול לפיו. "ה-VPN לא יציב במלונות" אינו כזה, והוא מבטיח שהשעה הזאת תבוזבז שוב בחודש הבא.