שרת PPTP מאחורי ראוטר ביתי: קודם לתקן את 1723 ואת GRE
הפעילו PPTP מאחורי ראוטר ביתי: TCP 1723, פרוטוקול IP 47, תיבת המעבר וחשבון ה-MTU, וגם מתי L2TP או OpenVPN הם העסקה הטובה יותר.
PPTP מאחורי ראוטר ביתי נכשל בשתי דרכים לא קשורות, וערבוב ביניהן מבזבז ערב שלם. אחד הכשלים הוא פער בהעברה: הראוטר מעביר TCP 1723 וזורק את פרוטוקול IP 47, ולכן הלקוח נתקע על שגיאה 619. האחר הוא בעיית גודל: המנהרה עולה, מאמתת, ואז קופאת כשצריך להעביר מנה בגודל מלא. לברר איזה משניהם יש לכם הוא הצעד האמיתי הראשון; השאר משווה מה הראוטר שלכם יכול לבטא, לא איזה מותג טוב יותר.
שני מובילים, ורק לאחד מהם יש פורט
PPTP מתפצל לשני מובילים: חיבור בקרה על TCP 1723, ומסגרות PPP עטופות ב-GRE משופר, כלומר פרוטוקול IP 47. ל-GRE אין מספר פורט, ולכן כלל שנכתב כהעברת פורט 1723 אינו יכול לכסות אותו, יהיה שם השדה בממשק האינטרנט אשר יהיה. ראוטר ביתי מציע בדרך כלל תיבת סימון בשם מעבר PPTP במקום כלל פרוטוקול, והתיבה הזו עושה שני דברים: היא מאפשרת לפרוטוקול 47 לעבור דרך חומת האש, והיא מלמדת את NAT איך לעקוב אחר זרימת GRE. בראוטר לינוקס המשימות האלה הן מודולים נפרדים וכללים נפרדים, ולכן מעבר שהוגדר למחצה עדיין מפיק ערוץ בקרה עובד. בררו איזה חצי קיים לפני שתשנו דבר.
חומת האש של השרת עצמו חייבת גם לאפשר את פרוטוקול 47 מכתובת הראוטר. חומת אש של מארח שמקבלת רק 1723/tcp משחזרת את שגיאה 619 מתוך ה-LAN, מה שעושה העברה שבורה וכלל מארח שבור לדומים לחלוטין.
sudo iptables -S FORWARD | grep -i gre
sudo nft list ruleset | grep -i gre
lsmod | grep -E 'nf_conntrack_proto_gre|nf_nat_proto_gre'אם המודולים חסרים, טענו אותם עם sudo modprobe nf_conntrack_proto_gre nf_nat_proto_gre והפכו את הטעינה לקבועה, כי אתחול ששוכח את העוזר מחזיר מנהרה עובדת לשגיאה 619. כלל ההעברה צריך לאפשר את פרוטוקול 47 רק לעבר כתובת השרת, לא לכל ה-LAN. ההגדרה של RFC 2637 מפרידה בין נתיב הבקרה לנתיב הנתונים, ולכן שום מסך העברת פורט אחד אינו מתאר את PPTP במלואו.
תיבת מעבר או כלל פרוטוקול מפורש
תיבת מעבר שרק פותחת את חומת האש קרובה יותר לנכון מ-ALG שמשכתב מזהי קריאה. חצי חומת האש צפוי, שכן פרוטוקול 47 או מתקבל או נזרק, והמונים אומרים איזה. חצי השכתוב הוא המקום שבו יצרנים נבדלים, כי מזהי הקריאה של PPTP הם לכל מנהרה ו-NAT שעורך אותם חייב לעקוב אחר כל קריאה שהוא נוגע בה. כשקוח אחד מתחבר ושניים לא, ה-ALG הוא החשוד הראשון.
כלל NAT יעד עבור 1723 נושא גם בעיית בעלות. אם כלל ישן עדיין שולח 1723 למארח שהפסיק להריץ את השרת, מנות נוחתות על פורט סגור ושירות ה-PPTP של הראוטר עצמו מפסיק לענות, מה שנקרא ככשל חומת אש אבל הוא בעצם יעד מיושן. קראו את הכלל ואת היעד שלו לפני שמוסיפים כלל שני. בראוטרים שמסיימים PPTP בעצמם, כלל ה-WAN מתחרה בשירות המובנה, ולכן בחרו בעלים אחד ל-1723 ולפרוטוקול 47.
שני לקוחות מאחורי אותו NAT הם המקרה שמפריד העברה פשוטה מהעברה חכמה. העברת פרוטוקול 47 בלי לשכתב את מזהי הקריאה מתנהגת בדרך כלל טוב יותר מעוזר שמנסה לתקן אותם.
מדדו את המנהרה לפני שאתם מאשימים את הראוטר
PPTP מקטין את המטען השימושי, וההקטנה הזו היא אריתמטיקה, לא מסתורין. כל מנת מנהרה נושאת כותרת IP חיצונית, כותרת GRE משופרת, כותרת PPP ועם הצפנה כותרת MPPE. כשהנתיב אינו יכול לשאת את המסגרת הנוצרת, מנות קטנות עוברות, ההתחברות מושלמת, וההפעלה נעצרת בפעם הראשונה שהעברת קובץ או לחיצת יד של TLS שולחת מנה בגודל מלא.
חשבו את המספר במקום לנחש אותו. GRE משופר עולה 8 בתים, PPP עולה 4, MPPE עולה 4, והכותרת IP החיצונית עולה 20, ולכן המנהרה אוכלת 36 בתים לפני כל מטען. ב-WAN מסוג PPPoE שמסתיים ב-1492, ה-MTU הגדול ביותר של PPP שנכנס הוא 1492 פחות 36, כלומר 1456. הגדירו את mtu ואת mru לערך הזה באפשרויות PPP ובדקו שוב עם פינג ללא פיצול.
ping -M do -s 1464 198.51.100.7
grep -E '^(mtu|mru)' /etc/ppp/options.pptpdהפינג מודד את הנתיב, לא את המנהרה: 1464 בתים של מטען ועוד 28 בתים של כותרות IP ו-ICMP ממלאים בדיוק מסגרת של 1492 בתים. אם הפינג הזה נכשל, הנמיכו את המספר עד שיעבור והחסירו 36 מהתוצאה. MTU של מנהרה שהוגדר מעל מגבלת הנתיב מייצר את הקפיאה בלי שורת יומן אחת שמזכירה גודל.
PPTP, L2TP/IPsec או OpenVPN על אותו ראוטר
אותו ראוטר יכול לשאת כל אחת משלוש המנהרות הנפוצות, וההבדל הוא מה הוא חייב לבטא. PPTP צריך שני כללים בשתי שכבות שונות. L2TP מעל IPsec צריך UDP 500 ו-4500 להחלפת המפתחות ואם NAT-T לא נושא אותו, פרוטוקול 50 למטען. OpenVPN צריך פורט UDP אחד ובלי שום עוזר.
| Tunnel | What the router must allow | Practical note |
|---|---|---|
| PPTP | TCP 1723 and IP protocol 47 | Two transports, two rules |
| L2TP/IPsec | UDP 500, UDP 4500, protocol 50 without NAT-T | ESP has no port either |
| OpenVPN | UDP 1194 or a chosen TCP port | Single rule, no helper |
עמודת L2TP אינה ידידותית יותר מ-GRE באופן אוטומטי. ESP הוא פרוטוקול IP 50 וגם לו אין פורט, ולכן ראוטר שמתקשה עם פרוטוקול 47 עלול להתקשות עם פרוטוקול 50 מאותה סיבה. NAT-T קיים כדי לעטוף את ESP בתוך UDP 4500, וכששני הקצוות תומכים בו כלל הפרוטוקול 50 נעשה מיותר. זו תכונה של הקצוות, לא של תיבת ה-PPTP בראוטר. אשרו איזו אנקפסולציה הלקוח באמת ניהל משא ומתן לפני שכותבים כללים לשניהם.
OpenVPN הוא האפשרות עם הכי מעט חלקים נעים בצד הראוטר. פורט UDP אחד, העברה אחת, בלי עוזר מעקב חיבורים ובלי שכתוב מזהי קריאה. העסקה היא לקוח שצריך להתקין במקום מחייג מובנה, ולעיתים קרובות זו הסיבה היחידה ש-PPTP נשאר בשיחה.
מה לתקן ומה להחליף
תיקון ההעברה וה-MTU נותן לכם מנהרה שעובדת, לא כזו שכדאי לשמור. אימות MSCHAPv2 של PPTP ניתן לתקיפה כבר שנים, ומנהרה עובדת מעבירה פרטי התחברות שאפשר לשחזר מחוץ לרשת. אם המכשיר המרוחק יכול להריץ L2TP/IPsec או OpenVPN, התייחסו לתיקון כאמצעי זמני עם תאריך.
ההחלטה מצטמצמת למה שהקצה המרוחק תומך בו ולכמה זמן ההסדר צריך להחזיק. מכשיר ישן שמדבר רק PPTP מקבל את התיקון; כל מה שאפשר להתקין עליו לקוח עובר הגירה.
לפני סגירת הפנייה, אשרו שהלקוח שורד העברה גדולה ולא רק התחברות, ושהראוטר עדיין מחזיק בכלל הפרוטוקול 47 שלו לאחר אתחול. מנהרה שעוברת העתקת קובץ אחת ומתה לאחר עדכון הקושחה הבא מעולם לא הושלמה.