כשלי כתיבת GRE ב-pptpd אינם בעיית סיסמה

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

שתי הודעות, שני כשלים שונים

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

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

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

פרוטוקול 47 אינו פורט 47

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

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

צפו בשני הכיוונים בו-זמנית בשרת במקום לנחש איזה צד מפיל תעבורה: tcpdump -ni any port 1723 or proto gre.

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

אפשרו GRE במקום שהמארח באמת מעביר

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

הוסיפו כלל input לחבילות שמופנות לשרת עצמו, כי שרשרת forward לא רואה אותן. אחר כך ראו את מוני הכלל לפני ניסיון חיבור ואחריו, מה שאומר לכם אם החבילות מגיעות בכלל.

הפכו את הכלל לקבוע דרך שירות חומת האש של ההפצה במקום להריץ אותו שוב אחרי כל אתחול. במארח nftables, התאימו את ip protocol gre גם בשרשרת input וגם בשרשרת forward.

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

התאימו את האפשרויות ללקוח שבאמת יש לכם

התיקון מהדוח האחר נמצא ב-/etc/ppp/pptpd-options, שם המתכון מסרב ל-PAP, CHAP ו-MSCHAP, מוציא מהערה את שורות ה-require המתאימות ושומר על MPPE עם מצב. המתכון הזה נכתב עבור תערובת לקוחות אחת, והעתקה עיוורת שוברת את המקרה הנפוץ. קראו את שורות הסירוב כהצהרה על הלקוחות שהיו למחבר, לא כהמלצה.

לקוח Windows צריך בדרך כלל MS-CHAPv2 עם MPPE-128. שמרו על הדרישות האלה והסירו רק את האפשרויות שהלקוח באמת לא יכול לנהל משא ומתן עליהן.

# keep encryption; drop only what this client cannot negotiate
refuse-pap
refuse-chap
refuse-mschap
mppe-stateful
require-mschap-v2
require-mppe-128

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

קראו את מספר השגיאה של הלקוח

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

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

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