PPTP מתחבר ואז נתקע מאחורי Linux NAT: עוזר ה-GRE

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

ההעברה מעולם לא הייתה הבעיה

כלל העברת פורט מתאר תעבורת TCP או UDP. הוא אינו יכול לתאר מטען שעובר לפרוטוקול IP אחר באמצע הפעלה, ו-PPTP עושה בדיוק את זה.

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

TCP לשליטה, GRE לנתונים

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

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

GRE חשוף בלי PPTP אינו זקוק לכתיבה מחדש כזו, ולכן מנהרת GRE רגילה יכולה לעבוד דרך נתב שנכשל עבור לקוח PPTP באותו נתיב.

ארבעה מודולים ו-sysctl שכיבה אותם

שני מודולים מטפלים במסגור, nf_conntrack_proto_gre ו-nf_nat_proto_gre. שניים נוספים מטפלים במזהה השיחה, nf_conntrack_pptp ו-nf_nat_pptp. טעינת האחרון שבהם מושכת את השאר דרך תלויות, ולכן רשימת מודולים צריכה להראות את כל הארבעה.

הוראות ישנות משתמשות בקידומת ip_ מעידן 2.6. הפקודות האלה עשויות להיראות כאילו הן פועלות בלי לטעון דבר, לכן בדקו את הרשימה הטעונה ולא את מצב היציאה.

לטעון אותן כבר אינו מספיק. מאז Linux 4.7 ברירת המחדל של sysctl net.netfilter.nf_conntrack_helper היא 0, מה שמבטל הקצאה אוטומטית של עוזר לזרימות חדשות. לנתב יכולים להיות כל המודולים ובכל זאת לא לתרגם דבר. בדקו את הערך האפקטיבי לפני שתבדקו שוב את רשימת המודולים.

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

iptables -t raw -A PREROUTING -p tcp --dport 1723 -j CT --helper pptp

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

פתיחת פרוטוקול שאין לו פורטים

כלל חומת אש שמתיר 1723 אינו אומר דבר על פרוטוקול 47. ב-firewalld התירו את הפרוטוקול באזור הפונה ללקוח. ב-iptables רגיל קבלו את הפרוטוקול gre בשרשרת הקלט.

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

לאחר שהוא מתחבר, מגבלת הגודל

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

קראו את ה-MTU במתאם ה-PPP של הלקוח ו- התאימו אותו לחישוב של הנתב עצמו במקום להוריד מספרים עד שמשהו יעבוד. מקטעים בגודל מלא שיוצאים ולא חוזר דבר מצביעים על המגבלה הזו ולא על התרגום.

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