שגיאת PPTP 800 מול 812 וניתוקים אחרי דקה

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

שגיאה 800 פירושה שהמנהרה מעולם לא נוצרה

Windows מעלה שגיאה 800 כשהוא אינו יכול לבנות את המנהרה כלל, והטקסט על שרת בלתי נגיש או פרמטרי אבטחה לא מתאימים הוא סיכום ולא אבחנה. PPTP זקוק לשני דברים נפרדים מהרשת לפני שנבדקת כל הרשאה. TCP 1723 נושא את ערוץ הבקרה, ופרוטוקול IP 47, GRE, נושא את המטען העטוף.

בדקו את הנתיב החיצוני הזה מחוץ ל-LAN שלכם, כי חיבור שעובד בתוך המשרד לא מוכיח דבר על הקצה:

$ nc -vz vpn.example.net 1723
Connection to vpn.example.net 1723 port [tcp/*] succeeded!
$ sudo tcpdump -ni eth0 proto gre
tcpdump: listening on eth0, link-type EN10MB

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

כוונו את ההעברה לכתובת ה-LAN הנוכחית של השרת, הפעילו העברת PPTP היכן שהנתב מציע אותה, ונסו שוב מאותה נקודה חיצונית. כשמ-GRE מסונן במעלה הזרם ואין לכם אפשרות לשנות זאת, ל-SSTP מעל TCP 443 או ל-L2TP/IPsec מעל UDP 500 ו-4500 יש סיכוי טוב יותר מכל שינוי שתוכלו לעשות בצד Windows.

שגיאה 812 היא השרת שדוחה את שיטת האימות שלכם

שגיאה 812 חוזרת לאחר שהמנהרה עלתה, ולכן היא מרגישה כמו בעיית סיסמה. השרת דוחה את שיטת האימות שנקבעה בחיבור, לא בהכרח את הסיסמה עצמה. בלקוח, פתחו את רשומת ה-VPN, עברו ללשונית האבטחה, קבעו את הסוג ל-Point-to-Point Tunneling Protocol, בחרו את רשימת הפרוטוקולים המפורשת וסמנו Microsoft CHAP גרסה 2.

אפשר לקרוא את ההגדרה הנוכחית בלי ללחוץ בדיאלוג:

$ Get-VpnConnection -Name "Office" | Select-Object -ExpandProperty AuthenticationMethod
MsChapv2

שרת שדורש MS-CHAP v2 דוחה לקוח שנשאר על PAP או על סוג אוטומטי שמנהל משא ומתן על משהו חלש יותר, והשגיאה מגיעה לפני שנבדקת סיסמת משתמש כלשהי. פורמט החשבון הוא החצי השני של אותה דחייה. במקרה אחד Windows שלח זהות חשבון Microsoft מהצורה MicrosoftAccount\[email protected] בעוד השרת רצה חשבון מקומי או חשבון תחום. הקלדת SERVERNAME\username אמרה ל-Windows באיזה מאגר חשבונות להשתמש והסירה את השגיאה. הזינו את השם ביד במקום לתת להרשאה שמורה לחזור על פורמט קודם.

ניתוקים אחרי דקה הם החלטת keepalive

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

בשרת Linux pptpd הערכים האלה חיים ב-/etc/ppp/options.pptpd, והתיקון הרגיל הוא להרחיב את התקציב ולא לקצר את המרווח:

# /etc/ppp/options.pptpd
lcp-echo-failure 30
lcp-echo-interval 5
# then
sudo systemctl restart pptpd

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

תת-רשתות חופפות שוברות את נתיב הנתונים

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

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

התחילו בשלב שנכשל: GRE בשביל 800, השיטה ומחרוזת החשבון בשביל 812, הגדרות הד בשביל מנהרה שמתה לפי לוח זמנים.