PPTP דרך נקודת גישה: TCP 1723 הוא רק חצי מהסיפור

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

GRE הוא פרוטוקול IP 47. זה לא פורט 47 של TCP או UDP, וההבחנה הזו מסבירה את רוב הבלבול סביב חומות אש.

שני מסלולים, חיבור אחד

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

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

נקודת הגישה מוסיפה עוד שני גבולות

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

פריט תפריט בשם PPTP passthrough, במקום שהוא קיים, קובע איך המכשיר הזה מטפל בפרוטוקול הזה. זו אינה אותה תכונה כמו אירוח VPN בטלפון או העברת כל פרוטוקול ללא תנאי, והפעלתו אינה הרשאה כללית להעביר GRE.

קראו את 807 כהפסקה, לא כפסק דין

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

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

בודדו את השלב שנכשל

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

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

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