PPTP בתוך Docker מאמת אך אינו נושא תעבורה

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

חמישה בדיקות, בסדר שחוסך את הזמן הרב ביותר.

בדיקה 1: הפרידו בין ערוץ השליטה למטען

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

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

בדיקה 2: אשרו את העוזר בגרעין המארח

מעקב חיבורים אינו יכול לקשר חיבור שליטה ב-TCP לזרימת GRE בלי עוזר. המודול הוא nf_conntrack_pptp, הוא חי בגרעין המארח, וטעינתו בתוך תמונת המכולה אינה משיגה דבר כי מודולים חלים על המארח כולו. lsmod | grep nf_conntrack_pptp במארח Docker הוא הבדיקה. אם הוא חסר, modprobe nf_conntrack_pptp טוען אותו עבור הגרעין הפועל ואינו אומר דבר על האתחול הבא, ולכן הוסיפו אותו גם לתצורת המארח.

מודול שנעלם באתחול מחדש הופך לאותו כרטיס בחודש הבא.

בדיקה 3: קראו את מדיניות הגרעין שמכבה אותו

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

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

בדיקה 4: הביטו בנתיב המכולה בנפרד

עוזר טעון אינו יוצר נתיב. המכולה זקוקה לנתיב לשרת PPTP, והעברה במארח חייבת לאפשר GRE בשני הכיוונים: iptables -L FORWARD -v -n מראה אם פרוטוקול 47 מתקבל ואם המונים זזים. כללי masquerade של Docker מתרגמים TCP ו-UDP, לא פרוטוקול 47, ולכן מכולה מגושרת עשויה להזדקק לאישור forward מפורש ובחלק מהמארחים גם לכלל תרגום משלה. ודאו גם שלמכולה יש תמיכת התקן PPP שהתמונה שלה מצפה לה.

קראו את המונים ולא את טקסט הכלל. כלל שקיים ואינו מתאים לשום דבר הוא קישוט.

בדיקה 5: הוכיחו ש-GRE במעקב, ואז החליטו לגבי PPTP

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

PPTP עצמו הוא מורשת ו-MS-CHAPv2 חלש. אם השרת מציע גם L2TP/IPsec, IKEv2 או WireGuard, מעבר לאחד מהם מסיר את כל סוג הבעיות הזה.

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