חסר passthrough של PPTP: תיקון שגיאה 807 ב-Windows VPN

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

לטבלת פורטים אין שורה עבור מספר פרוטוקול

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

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

מה Windows מדווח כשמסלול הנתונים מת

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

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

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

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

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

הוכיחו איזו מחצית נכשלת

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

Test-NetConnection vpn.example.com -Port 1723
rasdial "Work VPN"

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

tcpdump -ni any proto 47

המקבילה ב-Wireshark היא מסנן התצוגה ip proto 47, שקל יותר למסור למי שלא נוח לו בשורת פקודה. GRE שמגיע בלי ששום דבר יוצא בתשובה פירושו שמסלול החזרה צריך תיקון.

מה באמת מתקן את השגיאה

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

/ip firewall filter add chain=forward protocol=gre action=accept
/ip firewall filter print where protocol=gre

החלפת PPTP היא האפשרות האחרת ולעתים קרובות הזולה יותר. נתב שמסיים את ה-VPN בעצמו נמנע מ-NAT כפול ללקוחות נכנסים, ופרוטוקול ש-NAT מבוסס פורטים כבר מטפל בו אינו זקוק ל-passthrough כלל: OpenVPN על UDP, SSTP על TCP 443 או L2TP/IPsec עם NAT-T שעוטף ESP בתוך UDP 4500. PPTP תלוי גם ב-MS-CHAPv2, וחולשותיו המתועדות הופכות אותו לבחירה גרועה לפריסה חדשה גם אחרי שהשגיאה נעלמת.

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