מינהור מפוצל של PPTP לא עובד: תקנו קודם את נתיב GRE

צפו בחיבור PPTP עולה וקל להאמין שהחלק הקשה כבר מאחוריכם: הלקוח מאמת את עצמו, מופיע מתאם ppp0 או WAN Miniport, וחלון המצב הופך לירוק. ואז הבקשה הראשונה למארח פנימי מגיעה לפסק זמן, והפרופיל מקבל את האשמה. בפועל יש שתי שכבות עצמאיות שיש לפנות: התעבורה החיצונית שנושאת TCP 1723 ו־GRE, והמדיניות הפנימית שקובעת אילו יעדים משתמשים בממשק PPP. מצב ירוק מוכיח רק שהשכבה הראשונה ניהלה משא ומתן; על השנייה הוא לא אומר דבר.

עקבו אחרי הלקוח מהפרופיל עד לשקע הבקרה

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

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

sudo tcpdump -ni any 'tcp port 1723' -c 20

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

GRE הוא פרוטוקול שני, לא פורט

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

עקבו אחרי פרוטוקול 47 באותה לכידה, ואז השוו את מה שיוצא למה שחוזר:

sudo tcpdump -ni any 'proto gre' -c 20

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

הוכיחו שהמנהרה מעבירה מנה אחת

כשהגה GRE זורם, משא ומתן PPP מקצה כתובת לממשק הלקוח. קראו את ההקצאה במקום להניח אותה:

ip -4 addr show ppp0

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

עשו זאת לפני הוספת נתיב מפוצל כלשהו. שינוי נתיב שנעשה כשהתעבורה שבורה יוצר משתנה שני ומסתיר את הראשון.

כתבו את המדיניות המפוצלת, כולל DNS

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

בדקו את ההחלטה שהליבה מקבלת עבור כתובת אחת בכל קטגוריה:

ip route get 10.20.5.10
ip route get 203.0.113.25

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

בדיקה ניתנת לחזרה בחמישה שלבים

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

גרסה תמציתית ללקוח Linux נראית כך:

sudo tcpdump -ni any 'tcp port 1723 or proto gre' -c 40
ip -4 addr show ppp0
ping -c 3 192.0.2.1
ip route get 10.20.5.10

ב־Windows חל אותו סדר עם route print ומצב המתאם המוצג בלקוח. PPTP הוא פרוטוקול מדור קודם, ואם השרת מציע SSTP או IKEv2, מעבר הוא בדרך כלל שימוש טוב יותר בזמן מאשר כיוונון נתיב שתלוי במעבר של פרוטוקול 47 בכל קפיצה. בדקו את התעודה ואת חוזה האימות של המחליף במקום להעתיק פרופיל ישן לגרסה חדשה.