L2TP בלי IPsec בלינוקס: xl2tpd, pppd ו-NAT

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

אם אתם ממשיכים, רשמו את האזהרה הזו בהערת התכנון והשאירו אותה שם. מה שלפניכם הוא הנתיב התפעולי שאני משתמש בו במארחים ממשפחת Debian ו-RHEL: איזה קובץ אחראי למה, ה-MTU שמונע את התקיעה הקלאסית, וכללי ההעברה שהופכים את המנהרה לשווה.

שלושה קבצים מחלקים את העבודה

xl2tpd מסיים את חיבור הבקרה ומעביר כל הפעלה לדמון PPP, ולכן התצורה מפוזרת בין שתי תוכנות שלעולם לא קוראות את הקבצים זו של זו. המאזין יושב בקובץ /etc/xl2tpd/xl2tpd.conf, בתוך סעיף [lns default] שממנה את מאגר הכתובות עם ip range, את צד השרת עם local ip, ואת המסירה ל-PPP עם pppoptfile. הפעילו require authentication = yes, השאירו את length bit ואת flow bit פעילים, ובחרו מאגר ששום דבר אחר במארח עוד לא משתמש בו.

מדיניות PPP שייכת לקובץ שאותו אפשרות מזכירה, בדרך כלל /etc/ppp/options.xl2tpd: auth, דחיות עבור pap, chap ו-mschap, require-mschap-v2, MTU ו-MRU של 1460, וכתובת DNS שהלקוח יכול להגיע אליה לאחר שהקישור עולה. פרטי ההזדהות הם שוב קובץ שלישי, /etc/ppp/chap-secrets, שבו השדה השני חייב להתאים לשם סעיף LNS והשדה הרביעי יכול לנעוץ כתובת מסוימת מהמאגר.

למה המנהרה מתחברת ואז נתקעת

פריים Ethernet של 1500 בייט לא נכנס לנתיב שכבר מוציא בייטים על הכותרות שלו עצמו. כותרת IPv4 החיצונית עולה 20, UDP עולה 8, וכותרת L2TP כ-12, מה שמשאיר 1460 ל-PPP ולמטען שלו. דווקא הצהרת המספר הקטן הזה ב-PPP היא שמונעת מפקודות גדולות להתפצל או להיזרק בשקט אי שם באמצע.

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

פורט אחד נושא שתי שיחות

UDP 1701 יושב מתחת לשתי החצאים של הפרוטוקול, והעובדה האחת הזו שוברת יותר כללי חומת אש מכל חלק אחר בהתקנה. תחילה מגיעים בקשת פתיחת חיבור בקרה והתשובה שלה; בקשת ההפעלה והאישור שאחריהם לא מבססים יותר מאשר זוג המזהים. אחר כך PPP משתלט: בקרת קישור, אחר כך אימות, אחר כך פרוטוקול בקרת IP כדי להסכים על כתובות. לכל שלב יש אוצר מילים משלו ביומן, ואף אחד מהם לא מכריז על עצמו ככשל L2TP.

קריאת לכידה בדיוק בסדר הזה אומרת לכם איזה שלב נכשל, וכשל אימות PPP לא יתוקן על ידי עריכת xl2tpd. הפורט המשותף מסביר כשל נפוץ נוסף: כלל שמתיר רק את הפקטות הראשונות של זרימה נותן להפעלה להתבסס ואז חוסם את ההעברה. התירו 1701 לכל השיחה, בשני הכיוונים.

להפוך את המנהרה לשימושית: העברה ו-NAT

הפעלה כשלעצמה מגיעה רק לשרת. גישת הלקוחות לאינטרנט צריכה העברה, כלל NAT עבור המאגר בקישור העולה, ו-DNS שהלקוח יכול ממש לשאול לאחר שהקישור עולה. המאגר גם חייב להישאר מחוץ לטווח ה-LAN, אחרת תשובות המיועדות ללקוחות נמסרות מקומית במקום להידחף חזרה למנהרה.

בשרת, הפעילו העברה עם sysctl -w net.ipv4.ip_forward=1, תרגמו את המאגר עם iptables -t nat -A POSTROUTING -s 10.44.0.0/24 -o eth0 -j MASQUERADE, ואז קבלו תעבורת מנהרה יוצאת עם כלל FORWARD עבור -i ppp0 -o eth0 ותעבורת חזור עם כלל המראה ועוד -m state --state RELATED,ESTABLISHED. הפכו את הכללים לעמידים בין אתחולים, כי שרת שחוזר בלעדיהם נראה בדיוק כמו תצורת L2TP שבורה.

הגעה ל-LAN של השרת עצמו היא משימה אחרת: הוסיפו נתיב חזור עבור המאגר בנתב ה-LAN, או proxy ARP בשרת. הסתרת לקוחות מאחורי NAT כשמשהו בתוך ה-LAN חייב לפנות אליהם ישירות רק מתזמנת הפעלת ניפוי באגים שנייה להמשך.

מה המערך החשוף לא עושה, ואיך לאמת

אף חלק מהמערך הזה לא מצפין את פריימי PPP, ושום דבר בו לא מאמת את הקצה המרוחק כשרת שבחרתם באמת. MS-CHAPv2 אמנם מגן על החלפת פרטי ההזדהות מפני מאזין שרק מתבונן, אבל תוקף שממוקם בנתיב עדיין יכול להפריע להפעלה. לקוח Windows המובנה מציע L2TP רק בשילוב עם IPsec, אז חשבו על Linux, קושחת נתבים ולקוחות צד שלישי כעמיתים שלכם. התייחסו לתצורה החשופה כשלב אבחון, לעולם לא כמקום לעצור בו.

אמתו בסדר קבוע: הריצו xl2tpd -D בחזית, עקבו ביומן אחר שלב PPP, קראו את הכתובת שהוקצתה מתוך ip addr בשני הקצוות, ואז לכדו UDP 1701 כדי לאשר שהנתונים זורמים לאחר שההפעלה עולה. אם כל הארבעה תואמים והתעבורה עדיין נכשלת, התקלה בניתוב, ב-NAT או ב-MTU ולא ב-L2TP עצמו.